Re-skinning for beginners (that's me)

[Gumboots]

Ok, next bits. Another screenshot.

berkshire_hex_first_triangles.png (21.71 KiB) Viewed 12006 times

Referring to WP&P's page again, the first twelve bytes here refer to the vertex numbers, which are defined by the order they are listed in the last lot of bytes (last hex screenshot).

So, for Bogie 1 the first triangle is between vertices 2, 3 and 0. Vertex zero? Ok, that's what it says. For Bogie 2 the triangle runs the other way around, from 2 to 0, then to 3.

Next we have twelve bytes each for a normal vector off each vertex. If anyone needs to know what a "normal vector" is: http://en.wikipedia.org/wiki/Normal_%28geometry%29

These vectors are in IEEE 754 Martian Obscure Format again, so we have to run them through the converter.

Values (in basic hex) are BF000000, 00000000 and 000000 for all three normal vectors for Bogie 1. This means -1 sideways, and zero vertically, and zero longitudinally. This makes sense, because the face of this particular triangle is parallel to the track, and plumb to the track. So, the normal will be directly sideways, meaning it really only has an x value, with y and z values being 0.

For Bogie 2 it works out as you'd expect. Hex value for x axis is 3f800000, which when converted equals +1, so it's opposite to the vector for Bogie 1 because the wheel is facing the other way.

Next we get into the coordinates that map to the .tga skin image. These are also in IEEE 754 syntax, so the first one for Bogie 1 is 3BC154CA in basic hex, which converts to 0.0059. That gives vertex position from the left side of the .tga, as a proportion of the total image width. Image width is 512 in this case, so 512 x 0.0059 is 3. That means this vertex is 3 pixels from the left edge of the .tga, so the bogie graphic starts 3 pixels from the left edge of the .tga. This is correct (I checked it in PS) so we're good to go.

The next set of btyes is 3F7EBEE0, whcih is 0.9951 when converted. This is the distance from the top of the .tga. 0.9951 x 512 = 509.5, so this would be the bottom left corner of the triangle when you're looking at the .tga, and it would be 2.5 pixels up from the bottom. This is not exactly the same as the positioning from the left edge, but is close enough.

I have noticed things like this in a few places. Tha values coded into the .3dp file can be slightly out from what they really should be. I put this down to a combination of two things. First is that some numbers do not translate exactly from IEEE 754 format to standard decimal. Sometimes there will be a little bit of rounding error. Second thing is that the guys who coded the game would not have been manually editing the hex files. They would have been using a 3D gfx app that also probably had margins of error on the vertices. They got it good enough for it to work, but when manually editing files someone could, if they wanted to, get it a bit better in some places. This wouldn't help gameplay at all, but the extra consistency would make the code easier to follow in places.

Anyway, the first point of the first triangle is nailed down. For Bogie 1, the second point of that triangle is at 3DAFEC57 for x and 3F7EBEE0 for y. The y value is the same as for the first point, which tells me the line between these two points will be the bottom of the bogie, 2.5 pixels up from the edge of the .tga.

The x value converts to 0.0859. 0.0859 x 512 = 44.0, so that means the right edge of the bogie is 44 pixels in from the edge of the .tga, giving a bogie diameter (on the image) of 41 pixels. I checked this in Photoshop too, and it's correct.

The third and last point for this triangle is at 3DAFEC57 for x (we already know what this means) and at 3F6A3D71 for y. That equates to 0.915, and 0.915 x 512 = 468.5, which confirms the diameter of 41 pixels.

The last four bytes are all zeros, and indicate the "main direction" of the face. WP&P isnt sure what that means, and neither am I, but the fact that the zeros mean "-x" would indicate that the main direction is left.

Anyway, that how triangles are done. There are three more triangles in each bogie, and I can't be bothered doing them all at the moment. The principles are clear now anyway.

[Gumboots]

Just made another shot that shows all four blocks of bytes, for all four triangular faces, for Bogie 1.

I've changed the offset base (that's row and column numbering) from the default hexadecimal to the ordinary, everyday decimal we all know and love. Should have thought of that before, because it'll reduce the load on the brain slightly. Anyway, the first row of bytes in this shot is the same as the first row in the previous shot. It's row #132 in ordinary language, which is 84 in hexadecimal (since 8 x 16 = 128, and 4 x 1 = 4, and add those and you get 132).

Once you get into the triangles they run until the end of the file, at 76 bytes each face. If display is set to 12 columns (which is the least inconvenient, all things considered) then each face will be 6 1/3 rows. The only way to get it to be a full number of rows for each face would be to use 19, 38 or 76 columns, which would be inconvenient in other ways (IMHO). Still, anyone can do that if they want to.

berkshire_hex_face_byte_blocks.png (24.51 KiB) Viewed 11997 times

Couple of thoughts here. First is that since the faces run until the end of the file, if trying to find the bit you want in a long and complex file you can always try your luck with the last face and work backwards. That may be easier, or may not, depending.

Second is that since it's known how many bytes each vertex or face takes, you can easily predict where the next one will start and finish, even in a very long file. I like this.

Third is that not all parts of the skin have to be mapped to the .tga at the same scale. This could be handy in some cases. Since the code only maps the faces on the .tga as a proportion of total image size, different parts of the skin can have graphics made at different scales. If there is enough room left on the image, this might provide a way of giving more detailed graphics for some elements. A good case would be the very large driving wheels on some early locomotives. Due to be narrow wheel spokes, and due to the alpha channel for the image being all or nothing (that's "binary transparency" if you want to get techy), the spokes can look a bit choppy sometimes. By increasing the scale of the wheel you'd increase the resolution, meaning it would look less pixellated in the game. Since the game will resize it to match the same units as all other parts, it will still look the right size even though its graphics resolution is different.

Fourth thought is that, as far as I can tell at the moment, there is no limit to the total number of vertices and faces in any .3dp file. As long as the game will still run smoothly, it would be possible to make better quality graphics if anyone wanted to bother. All that's needed is to increase the number of faces to a suitable level.

Fifth thought is that this better gfx stuff may also apply to the .tga images. I haven't tested it yet, but since some default locos use a 512 x 512 image while others use a 1024 x 1024, it is possible that there is no upper limit hard coded into the game. It may be possible to use 2048 x 2048 .tga's for A skins and get away with it. Personally, I'm inclined to think this would be overkill, but I see no reason to use 512 x 512 for any custom work, and would be inclined to standardise A skins at 1024 x 1024.

[Gumboots]

I just had an idea, and I think it's a good one. I opened the ******L_Body.3dp file for half a dozen of the user-created locos (just because I already had these unpacked). As I suspected, the number of vertices and faces in each file is similar. It seems to be in the 7-800 range for faces, and around 100 higher for vertices. This makes sense, since most steam loco bodies are built from similar components, while the wheels and trucks are handled by separate .3dp files.

So, the idea goes like this. The reason modifying loco bodies is such a nightmare is because you're flying blind when it comes to which vertices are which, and there are so many of them. If all points were catalogued and labelled, with line numbers for reference, then modifying the file would be a lot easier. Doing this for all loco bodies would drive anyone insane, but if all loco bodies are built from basically the same components, it should be possible to get away with only mapping one of them.

This could have extra vertices and faces added, just so there are sufficient available for any reasonable use. These wouldn't have to be used, and they could just call clear sections of the .tga by default, and they could have a standard, easily recognised set of coordinates in the hex. So, they'd be available and easy to find if you needed them, but otherwise could be ignored.

If this is done, we'd end up with a generic, fully catalogued loco body that could be used for any custom work at all. Since it's known that one "unit" equals ten inches, any steam locomotive could be modelled to scale, and you'd know which points to move and how far to move them.

Admittedly, doing the intial mapping and documenting is going to be a fairly tedious task, but the benefits are clear and obvious. It's worth seriously considering.

[Gumboots]

I've figured out something else. It seems as if the ******_LengthPoint.3dp files define attachment points between different cars/engines/tenders.

berkshire_hex_LengthPoint.png (44.49 KiB) Viewed 11958 times

First line is the standard file header. Second line starts with number of instances, as before, but there's a twist. Number of instances in this case does not mean the same thing as in body files.

In body files, it denotes the number of independent sets of sets of coordinates, that have progressively lower vertex and face counts as the camera zooms out. In other words, it provides simpler wireframes to match the simpler images.

In the LengthPoint files, it denotes the number of length points for the car/tender/loco so the game knows where to attach other cars to it. This is always going to be two (one front and one back). This applies even to locomotives, even though in practice nothing will be attached to the front of them.

The rear length point is listed first. Dunno why. Just is. The screenshot should make things obvious. "00 00 00 00" "DD 24 E7 41" "00 00 00 80" are the x,y and z coordinates for the first length point, which converts to 0, 28.893, 0 in decimal. Positive y coordinates are to the rear of centre, so this is the rear length point.

Note the last one in the hex should really be "00 00 00 00" instead of "00 00 00 80". This is one of those tiny errors in the coding that I mentioned before. Can be corrected, but doesn't really matter if it isn't.

Anyway, this is how you get the locomotive cab roof hanging over the front of the tender, as it often does. I haven't confirmed this by editing vertices in files and testing the results in the game, but it seems clear that if the back of the locomotive cab roof extends past the "length point" coordinate, the roof will hang over the tender.

This is good to know, because I want to do something else with it. Seems to me that this is going to be handy for Garratts. Just call the rear drive unit/hopper combo the "tender", and set it so it extends past its front "length point". That way I can get its leading wheels sitting underneath the cab, in front of the pivot point between central unit and rear unit. The length point on the central smokebox/boiler/firebox/cab unit can be set forward of the end of the cab floor, so the pivot between central unit and rear unit should work out right for a Garratt.

It sounds good so far, and I think it will work. If my thinks are right, that'll be really good.

----------------------------

Just had an idea related to this. Since locomotives have both a front and rear "length point" defined (I've checked, and they do) then it may be possible to have two tenders per locomotive: one front and one rear. Since connecting rod, trucks, etc can be added just by naming them ***1, ***2, etc maybe the same will work with tenders. Dunno yet. Might be worth a try.

Also, since tenders have two length points defined, what happens if you only define one length point? If there was only the back one defined, would that force the tender to attach itself to the front of the loco?

Just idle thoughts about possible ways to do double-headed steamers and Garratts. I'm not sure yet what the game engine will handle without freaking out.

[Gumboots]

I figured out something that extends PJay's notes about .lco files. The old file had this listed.

LCO file spec (91 bytes)
=========================
00 : 4 : D507 0000 : 2005
04 : 30 : String : loco short name / unique id
34 : 4 : float : top speed
38 : 4 : float : ?1
42 : 4 : float : ?2
46 : 4 : float : ?3 (all = 0.5, except E60CP=0.0)
50 : 1 : byte : ?4 (diesel+electric+fairly+shay=255, others=?)
51 : 4 : int : acceleration
55 : 4 : int : passenger appeal
59 : 4 : int : reliability
63 : 4 : float : cost
67 : 4 : int : fuel type
71 : 4 : float : fuel economy
75 : 4 : float : annual maintenance
79 : 1 : byte : US availabillity
80 : 1 : byte : EU availabillity
81 : 1 : byte : WORLD availabillity
82 : 1 : byte : padding : 00 or CD
83 : 4 : int :?5
87 : 4 : int :?6
91

It has been known for some time that ?1 and ?2 are "free weight" and "pulling power". Today I did some hunting through files.

The Fairlie and Shay are the only two steam lcomotives that do not have tenders. Obviously, diesels and electrics don't have tenders either. This means that ?4 must have something to do with tenders, and the byte value FF (hexadecimal) or 255 (decimal) must mean that the locomotive in question has no tender. It cannot mean anything else.

However, after listing all the values for the other steam locomotives I still have no idea what values of ?4 other than 255 mean. I only listed the default PopTop locomotives, since all the user-created ones inherit the value of this byte from whatever default .lco file they are based on. Values are as follows.

Adler - 2
American - 5
Altantic - 7
Big Boy - 9
Camelback - 11
Challenger - 14
Consolidation - 16
Duke - 18
Eight Wheeler - 20
Firefly - 24
Mallard - 27
H-10 - 30
Kriegslok - 30
Norris - 32
Planet -34
Red Devil - 37
S3 - 39
Stirling - 47
Northern - 49
Beuth - 50
Class 500 - 53
Class 01 - 63
Crampton - 78
Pacific - 81
Baldwin - 121
Orca - 122
242A1 - 125
Class A1 - 128
Class P8 - 130
Class QJ - 133
U1 - 135

Now I've thought about this, and still can't figure out what it's supposed to mean. Since it has to be related to the tender it may have something to do with a correction for fuel consumption, but I can't see any real correlation at the moment. It is possible that it is something they were thinking of using during development, but is just a leftover that doesn't do anything in the final version.

That seems to be the case with the unknown bytes before it (?3) since that is the same for every locomotive except one (the E60CP) and there's no obvious reason why that locomotive is any different to the other electrics. At the moment, those variables are still a mystery.

However I have solved two other mysteries.

83 : 4 : int :?5
87 : 4 : int :?6

I was wondering how the locomotive sounds were defined, since they must be defined somewhere. So, I extracted the files from Sound/RT3SoundTrains.PK4, and did some comparisons with the game running and the .lco files opened in a hex editor. It works like this:

locomotive sound
----------------
0 - rt3_chug_steam_01
1 - rt3_chug_steam_02
2 - rt3_chug_steam_03
3 - rt3_chug_steam_04
4 - rt3_chug_electric_01
5 - rt3_chug_electric_02
6 - rt3_chug_diesel_01
7 - rt3_chug_diesel_02
8 - rt3_chug_diesel_03

whistle sound
-------------
0 - rt3_whistle_small_steam_01
1 - rt3_whistle_small_steam_02
2 - rt3_whistle_big_steam_01
3 - rt3_whistle_big_steam_02
4 - rt3_whistle_diesel_01
5 - rt3_whistle_diesel_02
6 - rt3_whistle_diesel_03
7 - rt3_whistle_diesel_04
8 - rt3_whistle_electric_01
9 - rt3_whistle_electric_02

Example locomotive values are:

Duke - 00 00 00 00 00 00 00 00
Firefly - 01 00 00 00 01 00 00 00
Challenger - 02 00 00 00 02 00 00 00
U1 - 03 00 00 00 03 00 00 00
Shinkansen - 05 00 00 00 09 00 00 00
DD080-X - 08 00 00 00 05 00 00 00

So, if you want to make a Duke sound like a Shinkansen, just change the last bytes in the .lco file to suit your preference.

I've attached an updated copy of the Pjay file.

[Gumboots]

Got something else figured out. I think WPandP had a minor point wrong in his Rolling Stock skinning ideas thread.

Update on Cuts of Cars:

I've done all that I can think of, but it appears that there is some sort of hard limit to how much a truck can flex or rotate, when tracking around a curve. The wheels aren't really attached to the rails, as they would be in real life; rather, the wheels are attached to the truck, which is attached to the body, and the body attaches to the track at its center point.

Having looked into file structure, the bit I underlined doesn't make sense. There is an additional file called *****L_TrackPoint.3dp (for locos) or *****T_TrackPoint.3dp (for tenders) or CaboA_TrackPoint.3dp (for caboose A skin) with similar files for cargo cars. It seems that these are what really define the attachment points to the tracks.

Having done a couple of quick checks of the coordinates from these files, I found that with an Atlantic the points correspond to where the two pairs of drivers hit the rails, and with a tender they correspond to roughly halfway along each tender truck. This makes perfect sense, which is always nice.

This is also potentially useful for things like Garratts and multiple-segment car mods. If the actual track attachment points can be defined to any forward or rear position, there is a lot more scope for getting better geometry around curved track.

For example, if the track points for a Garratt central unit are placed to coincide with the centres of the chassis pivots, then on a tight curve the body should appear to hang inside the track slightly, just as it should. There will still have to be some small amount of fudging (to balance chassis pivots with centres of driving wheelbases, which are slightly different) but it should be fine in the game after a bit of tweaking.

Similarly, it should be possible to use this to help the geometry of multiple segment cars. By placing the track points roughly halfway along each segment of a two segment car, the length points that the game thinks it has for a single car should be less of a problem around curves. That would still need some fudging too, to deal with truck attachment points to the body, etc, but it's better than nothing.

[Gumboots]

Right, more goodies.

I am assuming that anyone who wants to attempt this will be using this app for viewing the file: 3D Object Converter. Note that it's no good for saving/exporting RRT3 .3dp files. It's only good for viewing them. Nonetheless, it is very good for that, and enables you to see changes far faster than if you had to load the edited file into the game and run it.

Attached is a screenshot which shows the last definitions of points (ie: just before the triangles definitions for graphics start) from the H10/Berkshire L_Body.3dp file.

z_coordinate_example.png (108.85 KiB) Viewed 9178 times

The next shot shows where they map to the image. You can see the narrow triangle about halfway down on the left edge. All 6 are identical, so are stacked on the same region of the image.




Anyway, I found a handy trick while mapping the Body.3dp. When mapping body files, you need all the handy tricks you can get.

The left four columns in the hex are for the z (vertical) coordinates. As you can see, each triangle has the same value for two points on its base, and a different (higher) value for the tip. The trick is to use the z coordinate to help ease of mapping.

The way the hex is written (using IEEE754 format) the value 60 E5 0A 3F, at the start of the third row, translates to 0.543 units above the track (roughly 5 1/2 inches to scale). If you change the hex value to 60 E5 0A BF, that alters it to -0.543. This means that whenever you see a z value that has 3F in the fourth column, by simply changing the 3 to a B that point will be flipped to mirror beneath track height. Using this trick, it's quick and easy to alter a number of related points to mirrored under the baseline, so you can easily see which points do which bits of the body.

There's a similar trick with z coordinates that have 40 or 41 in the fourth column. They can be flipped to negative by changing the fourth column to C0 or C1. So, to mirror the upper tips of these triangles beneath the track, all that's required is to change the z value to E2 E9 D9 C0. These tricks will work on any points on the body. The important thing to remember is to change a 3 to a B and a 4 to a C. I found this was the best way of getting quick visualisation of what the points do.

CAVEAT: Since the hex editor writes straight to the file, it wont undo edits after the file is saved. To get around this, I worked with two copies of the file opened. This allowed me to keep a visual reference of the original code, just for safety.

[Gumboots]

Next bit: triangles for graphics.

This works the same way for complicated loco body files as it does for simple bogie files. Carrying on from the first shot in the previous post, you can see code for the first two triangles here, with the first one highlighted.

first_triangle_definitions.png (18.61 KiB) Viewed 9177 times

This calls Points 3, 2 and 5. Where are they and what do they do? It turns out that the first 8 points in the case of this loco (no guarantees for any other loco) define the rear face of the firebox. The firebox/boiler/smokebox combo is modelled as a nonagon in cross section, but with the centre/bottom vertex missing. Those faces would be hidden by the chassis, etc, so the devs left them out to save code.

By checking what the hex means when translated into English, I know that these points (not all points) run from lower left and clockwise, when looking at the loco from the rear. They are mostly hidden by the cab, so I've shunted the last one out sideways so it's visible.

first_body_points.png (103.92 KiB) Viewed 9177 times

As the screenshot says, the first point is numbered as zero in the code, so Point #2 is actually the third block of twelve in the highlighted section. The eighth point, that has the extra highlighting in red, is called 07 00 00 00 in the triangles stuff.

By checking the unwrapped coordinates overlaid on the graphic, you can see this first triangle. The rear end of the firebox is at upper left of the image, about a third of the way in. Points 3, 2 and 5 are actually the fourth, third and sixth going clockwise from lower left, so this first triangle defined in the code is the one at the left top of the firebox end, wth its bottom horizontal and its long diagonal face sloping down to the right.




PS: Personally, I'm only interested in modelling steam locos. These also happen to be the most complex ones. Serves me right.

Anyway, even the most complex ones can be deciphered. I nailed down the function of every point on the H10/Berkshire body mesh in one long day. Many of the diesel and electric locos have only one half to one third of the number of points in a steam loco. If someone wants to play with diesel or electric loco models, and assuming they are not using one of the rare exceptions that is as complex as a steam loco, then I think it is fair to say that they could not only nail down the function of every point on the mesh in one day, but also sort a guide to where every triangle maps to the DDS/TGA image.

In other words, if you're a diesel or electric fan don't be scared of this stuff. You should be able to get yourself a complete guide to a loco, including screenshots and notes, with one hard day of work. Once you have that, you will be able to mainpulate it in any way that you like.

Since I'm stupid enough to only want steam locos, it's probably more like three days for a complete, idiot-proof guide to one loco (assuming that people will refrain from building better idiots).

If someone does make such a guide, it'd be nice to post it for everyone else. I'll be sorting one out for the H10/Berkshire.

[Gumboots]

Hmm. Maybe I wont, or at least not in a hurry.

After going through the H10/Berkshire file I have most of the points nailed down for function. However, when I got to the end I noticed my tally was slightly off. Instead of the 827 points the file claims it had, I had totalled up 822. So, five point discrepancy. Awesome.

There is currently good news and bad news. The good news is that the five point discrepancy appears to be fairly early in the file. I simply missed recording five points somewhere. That means that a lot of the stuff I have recorded is accurate if I simply take the point numbering and add five to it. IOW, I have the vast majority of the points fully documented, and they can easily be found in both the points declarations and the triangle declarations.

The bad news is that there are a few which are really nasty to track down, and of course they are useful ones that people are likely to want to change. One such point is the right rear bottom corner of the cab. There are actually two points there, sitting on top of each other. One is grouped with the rest of the cab points and is mapped. The other is hiding somewhere in the hex. Where? Dunno yet.

What this means is that if you want to move the cab around it's easy....................................except for that one corner, which will mess you right up. At this stage I was fairly sure that traps like this had been built in on purpose. There just didn't appear to be any other explanation for the way some of the points and triangles are arranged.

OTOH, I had only tried the one file, so perhaps this was just an odd one. I figured it may be worth checking some of the other loco bodies. I looked around a bit, and the simplest steam loco bodies are the Mallard (371 points) and the Class A1 (392 points), followed by the Duke (492 points). Any of these would be a lot less work to map than the 827 points in the H10/Berkshire file. So I opened up the Class A1 file and starting juggling points around.

It turns out that even though it is a lot simpler than the H10 file, the Class A1 file still has points ordered all over the place. It would be possible to doucment it all, and it would be about half the work required to document the H10, but at the moment I really cannot be bothered. After putting in quite a bit of time over the last few days, I am now sure that building locos from scratch is going to be faster, easier, and infinitely more enjoyable than trying to reverse engineer the crud that PopTop inflicted on us.

Even if I do move something around it would still have the image mapping of the original, which means blurry gfx close up and smokeboxes that look like they are built out of bricks. I'm kinda over all that. It's not worth trying to fix it for the old locos, IMO. I'm going back to building a new Garratt.

If anyone wants to take a look at the stuff for the H10, just ask.

==================================

Anyway, regarding building new Garratts and making things easy to find in the code, I thought about the idea of set markers that I mentioned in the Australian steam locos thread.

What is wanted for set markers in the points declarations is something that gives an easily recognised/searchable block of code, but doesn't give daft coordinates since the game engine will have to map them in real time. Check the screenshot:

Set_markers_hex.png (16.98 KiB) Viewed 9128 times

The example file starts with the standard file header up to INST, then the declarations for number of points and triangles (just make those whatever works). After that is the proposed set marker, highlighted in blue. This is simply another point, with coordinates chosen to be very close to zero for x,y and z axes. IOW, it will sit in the middle of the loco at track height. This can be repeated as many times as necessary, since there is no prohibition on different points being at the same location in space. Each use of it will have to be tallied in the total count of points, but that's no problem.

The result will be a clear marker at the end of every group of points. All the boiler stuff can be grouped together, with END.SET.NEW. after it. The cab stuff (or whatever) can then follow, and would obviously have END.SET.NEW. at the end of it too. There probably wouldn't be more than ten marker points in any file. This should make finding bunches of stuff to juggle a lot easier, and should have no ill effects during gameplay.

After that, highlighted in grey and red, is an example for a marker to be used in the triangle mapping. The row highlighted in grey would just be the relevant point numbers, as usual for triangles. These wont be a problem. The first three rows of the stuff in red define the normal vectors for each point, and can just be set to pointing straight up for all points (which is what the 00 00 0080 3F at the end of each line means).

The next two rows define the mapping to the image, and for a 512x512 image mark out a triangle from top left (0,0) to top right (512,0) then right and one pixel down from the top (512,1). IOW, all that would be needed would be to leave a one pixel high transparent strip across the top of the image (or 2px in the case of a 1024x1024). Since the marker points will map to that area, you wont see anything in the game. The block of code should be easy to search for, since it's highly unlikely that any other part of the file apart from markers will use that exact sequence.

This means that is should be possible to find stuff without going bonkers.

[Gumboots]

Ok, so after all that grumbling I tried something else. Defeated I shall not be.

This time I started with a default PopTop H10 file extracted straight from the 3DPF pack, instead of playing with the existing Berkshire file. This seems to be a bit better, so maybe the Berkshire file was a bit messed with before, or I just knackered something myself. Whatever.

Anyway, by referring to my notes and playing around for a few hours, I managed to turn the H10 body .3dp into a pretty good facsimile of a Class A1 Berkshire. It's got the extended firebox and the hump in the boiler profile, and I changed the cab to match a proper A1 cab. All it really needs now is a new rear truck and bogies, which should be easy enough. No idea how it'll look in the game yet, but since it's calling most of the default mapping it should be pretty good. Minor tweaks to graphics are to be expected.

prototype_a1_1.png (66.01 KiB) Viewed 9116 times

prototype_a1_2.png (60.08 KiB) Viewed 9116 times

Oh and I had an idea about the infamous alpha night glow problem. It's so simple I'm kicking myself for not thinking of it before. The thing is that wth fairly simple modifications of a default loco, you can use the default alpha channel. All that's needed is to extract the DDS pack that comes with the game. That contains all the skins, in all the required sizes, with alpha channel included. They can be exported as .tga for working on them (recolouring, etc) and there should be hardly any need to touch the alpha channel. Will have to try it and see how it goes.

The other good thing about extracting the DDS pack and saving to .tga is that you get bigger skins of better quality. The .tga provided in the user skinning tools is only 512x512. The A skin DDS is 1024x1024 for most locos. That means four times the pixel count, which means much better graphics in the game.

[Gumboots]

This is coming along well now. I got into detailing a bit more, as the default H10 includes some bits that weren't ever on an A1 Berkshire. Come to think of it, I can't see them in any picture of a standard light or heavy Mikado either. Dunno where the game devs got them from.

Anyway, just as an exercise to try out some actual code manipulation, I moved the unwanted bits around and revamped their geometry, without creating any new points or breaking any of the existing triangles, to make them into things that should be on an A1. For instance, the extra long tank under the walkway on the left side was made out of the large step/platform that used to be there. This will mean rejigging the .tga image and the triangle mapping a bit in a couple of places, but nothing too drastic.

I still have a couple of bits left over, which I already have plans for, and I'm still going to tuck the feedwater pipes into the smokebox just above handrail height, since that was how they were arranged IRL. Two of the bits I still have to play with will be used to bevel off the vertical corners of the sandbox a bit, which will make it look a lot better. The other bits will be used to box up the safety valve above the firebox. After that it really will be finished as far as body work goes, then it'll be onto making a new rear truck.

prototype_a1_3.png (55.22 KiB) Viewed 8164 times

prototype_a1_4.png (53.04 KiB) Viewed 8164 times

LLW_A1-72dpi.JPG (83.51 KiB) Viewed 8172 times

[Gumboots]

It's done. Well, as far as the basic body coding goes anyway. I think this is about as far as it's reasonable to go. All points and triangles of the original are still used, and no new ones have been created. Without making a whole lot of new ones, there's not much more that can reasonably be done on a base of the default PopTop H10 geometry. Looks ok, IMO.

This file editing stuff is bad sometimes, and not so bad other times. If anyone else gets inspired to have a first go at it, I have some suggestions.

Document everything as much as you can, and keep the notes handy. Also, make sure you understand the geometry before you start randomly moving stuff around. If you don't, it's easy to get lost. Remembering your high school trig will help a lot. Speaking of which, make sure you have a good calculator sitting next to you too. Have a backup copy of the file, saved after each successful edit, and keep that handy too. Take things in small steps and check the result frequently. Take a break when it starts driving you crazy.

Having said all of that, it is rather satisfying when you work something out on paper, then watch it all snap into place in the 3dp viewer. So it's not all bad.

Next step will be the rear truck, then some basic in-game testing before doing the final gfx and whatever else it needs (it's sure to need something).

complete_a1_1.png (63.61 KiB) Viewed 8153 times

complete_a1_2.png (55.29 KiB) Viewed 8153 times

complete_a1_3.png (51.77 KiB) Viewed 8153 times

[Gumboots]

Further thoughts have been thought. It happens.

After looking at the default H10 in the game last night I realised I had made an error. I'd assumed that the three narrow triangles down low each side, roughly in the location of the drivers, were for components that were on the same line as the axle. Turns out they're for graphics for the brake blocks, and therefore sit between the drivers. That means I have the firebox/ashpan length slightly wrong and will need to move the front of those forward a bit. This also means moving the sand box and steam dome forward, and while I'm at it I might as well move the dome shut-off valve from the right side of the steam dome to the rear face, which is where it belongs on a Berkshire (I got lazy yesterday and just left it where PopTop had put it).

Fortunately, compared to what has gone before, these are very simple and straightforward changes, so shouldn't take long.

Other thoughts are:

I want a better hex editor. HxDen is basically ok, and the file compare function is very handy, but although you can bookmark lines of code it loses the bookmark whenever you save the file. Now, you might reckon that the whole point of having a bookmark function is so that the #$@!^ editor will @%$&@ keep track of your @%@%! location in the !%@$# file. All the @%@$! time. Apparently, the maker of HxDen thought this was not the point of bookmarks. I have no idea why.

Also, although HxDen claims to have "unlimited undo" this only applies until you save the file. At that point, all your history is lost and you can no longer undo edits by tracking back up the history. Quite frankly these two flaws are, IMO, idiotic in a code editor. I'm used to using code editors that track things the way they should. Unfortunately, the ones I'm used to wont handle hex editing, so I'll have to look around a bit.

IMO, what a hex editor needs are the following atrributes.

1/ Will bookmark lines or blocks of code, and keep the bookmarks permanently.
2/ If you close the app without closing the file first, when you reopen the app it will still have the file you had open before, bookmarks and all. Really, this is basic functionality for a code editor.
3/ Keeps the edit history even after saving a file, so you can easily reverse edits if they didn't work. Again, basic.
4/ To make things easier for decimally-minded humans, has the ability to number lines in decimal rather than in hexadecimal.
5/ Ability to set number of columns.
6/ Ability to compare two files side by side.
7/ If you could type in numbers in plain English and have them automatically converted to Indecipherable Martian that would be handy (not a deal breaker if it doesn't have it).
8/ Even more cool if it will do them back the other way, so you can open the file and immediately know what all the hex means in normal 3D coordinates. IOW, basically the ability to display a hex file in basic decimal. This is not essential, but would be very nice.

HxDen has 4/, 5/, and 6/, but lacks the others. I believe Tiny Hexer has 5/ and 7/ (haven't tried it yet) but lacks the rest. Will take a look at it and seee how it performs. Will also check around to see what else is available.


Next thought is: If attempting reverse engineering of any more PopTop models, use a CAD app. Transferring the coordinates you're working on to a basic 3D CAD app would make manipulating the geometry much easier, IMO. Once they are sorted, transferring the new numbers back to the hex should be all that is required.

It'd be a bit tedious to grab the numbers from the hex, convert them to standard decimal, then enter them into the CAD app as points/faces, etc. However, given that with this stuff you'll spend half your time trying to figure out what does what, an easily comprehensible format is what is needed for trying out changes. That means being able to use numbers that make sense to you, and being able to change them easily. This means CAD app.

For instance, if I'd done this earlier I would have already known about the exact location of the drivers relative to the firebox. I already had the drivers set up in a basic CAD file, from when I was checking out wheels when I first looked into .3dp files, so I should have built on that for the locations of other components. Will do that in future.

[Altoona+BeachCreek]

Gee mah, think I'll get a dictionary fer xMas so I can understand what the grown up said??
I'm glad there are people like you here who know what you're doing! Keep up the good work!

[Gumboots]

Well fortunately some smart cookies (Bomber, Ned, WPandP, and others) did a lot of the ground work a while back, so if you read what they wrote it will get you off to a good start.

This thread is sort of half stream of consciousness ranting. Like I said to Wolverine, I'm just noting stuff as I go, and if it's all written down then it can be cleaned up later, after which it might make sense to other people and therefore be useful.

Anyway, I've been looking at hex editors and have found one which has totally awesome bookmarking functionality. This means the whole hex file can be effectively documented, and easily searched.

For instance, it is possible to create different bookmark groups for a file, so you could have a group for each component of the loco body (like firebox, for example) that would have nice jump-to links for declarations for the points and the gfx triangles for that component. this would make things far less brain-frazzling. Only catch is that to get that functionality I'd have to get a paid version, but only the most basic paid version (which is quite cheap). If I get it, I'll probably find non-RRT3 uses for it too. Given how much aggrevation it'll save, I'm seriously considering forgoing a dozen beers and just getting it.

[Wolverine@MSU]

Given how much aggrevation it'll save, I'm seriously considering forgoing a dozen beers and just getting it.

I thought you were only 15 years old - if so are you allowed to drink beer? On the Hex Editor stage, I have used HxD, but have only limited experience and don't know if it has all the bells and whistles you need.

[Gumboots]

Well, if you mean "were only 15" as in past tense, you would be correct. At one stage, I was indeed 15. However, this was well over three decades ago, with the result that currently I am allowed to drink as much beer as I like.

HxD was the one I was using, and it's what got me looking for something better. I wanted something that was still being actively developed, was free or cheap, and was not short on desirable features. This stuff is enough work already without making it harder on myself. What is really needed for reverse engineering default files is, IMO, a really good bookmarking system. I've decided to go with Hex Editor Neo (Standard version). This is a good compromise (for me) between features and cost. At the moment I can pick it up for 20 bucks, and it has already saved me 20 bux worth of aggro.

What it allows is an unlimited number of permanent bookmarks, grouped or ungrouped. These can be bookmarked individual bytes or complete blocks of code. They can be given individual text descriptions and colour coding of your choice, can be shown or hidden with one click, and have a record of how many bytes they contain so you can easily cross-check for errors in your highlighting. Obviously, you can jump to any bookmark, or group, or toggle through them.

All that is now required map a file is to do the z-index trick of making the points heights negative (change 40 to C0, or 3F to BF, straight down one column) and checking in 3D Object Converter to see when you have a complete component. Then just highlight that entire block of code, make a new bookmark group that has a description and is colour coded differently to the previous group, and click "Selection to group". Voila! You now have a permanent record of what those points do, and you can easily see in the code exactly which bytes are relevant.

This is totally awesome, because it means mapping every point in a .3dp suddenly becomes a lot quicker and easier. I set up complete bookmarks for all points in the H10 2-8-2 L_Body.3dp and the A1 2-4-2 L_body.3dp in a few hours after dinner last night. Not only that, but when I go back to some section of a file I don't have to go cross-eyed finding the exact bytes I want. They all have a nice background and outline. It's a lot easier on the brain and eyes, compared to more basic editors.

Example_display.png (171.8 KiB) Viewed 8702 times

[Wolverine@MSU]

Well, if you mean "were only 15" as in past tense, you would be correct. At one stage, I was indeed 15. However, this was well over three decades ago, with the result that currently I am allowed to drink as much beer as I like.

Crikey!!! I guess I got you mixed up with someone else on the Forums........Drink away......and remember......."Fostahs - it's Australian for Beeah"

Keep up the good work.

[Gumboots]

Foster's isn't that good. Try Cooper's or Boag's.

Anyway I took the default rear truck for the H10 and edited it into a shape that should work for an A1 Berkshire. Resized and repositioned the existing rear wheels for the second truck, and made the extra two that were needed. The other tweaks (firebox sizing, etc) are done too, so it's basically ready for packing and in game testing. It will still need work on the gfx, but I can test the geometry now and get an idea of what else it will need. I may have to tweak length points, and attachment points for track and trucks. I'm pretty sure some of the normals for the skin triangles will need adjusting too, just to get the game engine to shade some of the modified surfaces nicely. However, the main structure is fine.

Also, after grumbing about the game's authors nobbling files to make them harder to reverse engineer, I've discovered that some of them are really clean. I took a quick look at several of them, and stopped playing with the ones that were all mixed up. The 242 A1 (the French 4-8-4 in Whyte notation) and the Atlantic are really nicely laid out though, and were a piece of cake to map. They break down really cleanly into all their separate components, so there's a lot of scope for doing things with them.

The other A1 (Yellow Flying Yorkshire Pudding 4-6-2) was interesting. It has a low vertex count but is a real mongrel to work with. I'd advise anyone to steer clear of attempting serious customising of that one. The way it's laid out is not user-friendly because everything is tied together and the points are in a weird order (or lack of it). Trying to move stuff around on that model is likely to drive anyone nuts.

Some of the others are just a horrendous mess (like the Northern 4-8-4) but I no longer think it was deliberate. It was probably just some dev winging it as they went and changing their mind all the time. Since they would have been using an app that made deleting and inserting vertices easy, it wouldn't have bothered them too much. Real nuisance for us though.

My 2c is mod the ones that are easy to work with and basically ignore the others. For something like the yellow 4-6-2 A1 it would be better to just build from scratch, unless you only wanted really basic tweaks.

[Altoona+BeachCreek]

On the A1 Pacific: Haven't you seen the skin for that one? It's a beautiful green livery complete with LNER tender and "Royal Coachmen" on the center axle streamlining. It's rather clean and crisp IMO. I definitely would never use the Yellow livery.