Re-skinning for beginners (that's me)

[Gumboots]

I thought I'd try a couple of easy re-skins, just to get into practice. I've been reading up on the pitfalls, and one thing that caught my eye is this:

I know what causes it, but it is a pain to rectify.

Basically, it is because of how the game uses the alpha channel, in the skins that paint the sides of the cars and locos. Normally, the alpha channel is used only for levels of transparency. But in RRT3, transparency is all or nothing; any portion of the image where the alpha channel value is between 0 and 100% is treated as if it is to be lighted at night, and fully opaque. The windows that glow on a passenger car are just regular windows that have been set to about a 70% "transparency" in the alpha channel.

I understand about the alpha channel, and am in the process of cleaning that up for a basic Northern 4-8-4 re-skin (tedious, but not difficult). Once I have the basics of producing simple skins sorted, I intend to re-alpha some of my favourite user-created locomotives so I can enjoy looking at them even at night. Of course, I'll make the cleaned up alpha masks available for anyone once I've finished.

The other factor is that the game uses multiple skins for each car, usually an "A", "B", "C", "D", "E", and sometimes more versions of the skin file. Each iteration of the skin is half as large as the first in each direction, so they step down from 1024x1024 to 512x512 to 256x256, etc. The game swaps out these versions of the skins based on how close you are zoomed in; you only see the A skin when you are right at trackside; most of the time you're seeing a C or D skin while zoomed out. So, to create a skin, you have to resize it and save it to all these versions.

The .TGA's provided by the game in the User Skinning folder are 512x512. There isn't any 1024x1024.

In the "Four Northerns" re-skin pack (which I took a look at first) the A image is 512x512, going all the way down to the E image at 32x32 (which frankly seems pretty pointless for detail).

Is it necessary to make a 1024x1024 image? Will it result in a noticeable difference in quality when zoomed in, or are the limits of RRT3's gfx going to make it look as rough as a 512x512 rough anyway?

I suppose the real question is what are the game default sizes? I haven't tried unpacking any of the default Popop loco files from inside the game itself. What sizes do they use for the different skins?

ETA: Oh yeah. Pictures. This is what I've been playing with.

[Altoona+BeachCreek]

Those look great! Far better than anything I could do. I really, really, really want to learn how to do this stuff, because I have so many ideas. It's just so complicated though. Tech things really isn't my area of expertise. Maybe I could get my friend Byron to help get some of my projects started once we move into that apartment when we graduate. His opinion on trains is guilded (he actually got a detention in 8th grade just for saying the word "trains," I kid you not,) but he's a great friend and has been wanting to play the game for a while now.

[Gumboots]

A basic one like the above examples isn't that hard to do. It was just a hue change on the main coloured stripe for the green one, and a hue change conbined with a slight overall darkening for the others. This means I didn't have to worry about "paint" covering up details like rivets and shading, because I was still using the detailed sections from the original file. Repainting an entire loco to a diffrent colour scheme would be a lot more work (thinking about it, know how to tackle it, don't want to do it right now).

Basic procedure goes like this. Figure out which bits you want to change the colour for. That means all the other bits are bits you don't want to change colour (brass, polished alloy, cast iron, etc). Set up a couple of layers in PS and crop chunks out to suit, so you end up with a layer that can be colour changed without affecting everything. Put a hue change adjustment layer on the one you want to change, and just play around with sliders until it looks good. The other layer sits on top and gives you unchanged metal, etc. I also aded a couple of text layers, just so the text could be adjusted independently of the rest.

The work is in the cropping and selection. Get that right (it's a bit fiddly, but not rocket science) and you're off and running. Once it's all set up, you will be able to churn out basic variants very quickly. I've got the alpha channel fully sorted for the profile shot and the tender A skin, and mostly sorted for the loco A skin. The other (smaller) ones should be faster to do, then I can run these live and see if I got it right. :)

If I got it right (fingers crossed) I'll zip the PSD's so anyone can play with them.

[Hawk]

Double post. Need more coffee.

You know you can delete your own posts.

[Gumboots]

Told ya I needed more coffee.

[Gumboots]

Bumping this.

K, I'm on a mission. I'm totally over reading all the helpful hints on 3d modelling that are strewn around this site, because without meaning to be rude they all seem to come down to one thing: "Get yerself a hex editor and find things by trial and error".

Eveyone knows there's lots of interesting stuff in them thar files, but nobody seems to know what is really in there or how to interpret it. Consequently, every time somebody wants to do something they have to walk into a dark room without a torch.

So, I'm going to start with bogies. Bogies are great, because they are probably the simplest elements in any .3dp file (they are just one or two squares). This means they are going to be the simplest to understand. They also contain all the information required to start understanding more complex files.

For instance, take the basic two wheels on the front truck of a Berkshire. These are called by two separate .3dp files, but the only difference between them is that the wheel is flipped from one side to the other. That means the only dfferences in the code will tell you how to do this.

Or take the driving wheels. The rear 6 of these all call the same area of the .tga image, but the pairs have different positioning along the loco. That means the only differences between the files will tell you how to reposition an element along the loco.

What about the first driver? It calls a different section of the image, that is over to the left of the others. You see where I'm going with this? We don't need to stumble around in the dark so much. There is a mapping system here. Once it can be understood for the simplest elements, it should be possible to extrapolate it to more complex elements.

Everyone wants to start with the most complex elements (entire locomotives) without understanding the simplest ones. No wonder it's been a nightmare. It's only basic three-dimensional geometry, guys. It's just that the format it is presented in is rather hard to digest. We need to make it digestible if we want to see any more customisation, because otherwise nobody will bother.

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

The most useful stuff I have seen so far is on WP&P's site (yes, I have read PJ's and Milo's notes too). http://wpandp.com/CarModHowTo.html

3DP FILE EDITING
Notes on the 3DP file structure compiled by PJay, as shared with Bombardiere (Kimmo Jaske) and WPandP (Michael Rountree), edited by Michael Rountree.

3DP files

4 bytes : "3DPF" = bytes: 51 68 80 70
4 bytes : 04 00 01 00
4 bytes : "3DMD" - bytes: 51 68 77 68
4 bytes : int: number of instances
3*4 bytes : float: center X, Y, Z

First twelve bytes are just the file header, and are not relevant to modelling. The next part is where it starts getting interesting: 4 bytes : int: number of instances.

Ok, that's great as far as it goes, but it suffers from a common problem, namely that it was written by somebody who knew what they meant, and therefore assumed that everyone else would know what they meant too.

Number of instances of what? Aardvarks? Ice cream? Watermelon sandwiches with pickles on top? Something else? And anyway, how does this relate to the price of eggs in China, and what use is it to anyone who wants to do some loco modelling?

Does anyone know the answer to this? It'd be handy to get it down in print for everyone.

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

Next we have this: 3*4 bytes : float: center X, Y, Z.

Simple enough, but why four bytes for each coordinate? Each byte can have a value between 0 and 255. What happens when the next byte comes into play? Presumably it just extends the value in the first byte, such that 00 00 00 FF would be 255 in decimal, while 00 00 01 FF would be 511 in decimal. Is this actually how it works? If yes, let's say so, so that anyone can understand it. If no, then how does it work?

Also, if this is how it works, then the maximum value would be FF FF FF FF, which would be something over 4 billion in decimal. That's an extremely high value for a coordinate system, and honestly I can't see any point in allowing values that high. Using three bytes should be more than enough, so why are there four? Does anyone know?

Also, these values have to be signed, so that they can have positive or negative values (for instance, right and left wheels will need this). Is that indicated by using either 0 or 1 on the highest level byte, such that 00 00 00 FF would be 255, and 10 00 00 FF would be -255? If yes, can we please have this clearly stated, so that beginners can actually understand how the system works? If no, how does it work?

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

Regarding hex editors, I think HxD is a better choice than the XVI32 that is recommended in the TM dev kit, simply because HxD allows unlimited undo (useful for any editing on any code file), and also allows comparing two different files side by side (a la WinMerge, and similar apps). The compare feature is going to be very useful for mapping how changes work. As far as I can tell, XVI32 doesn't offer either of these features.

[Gumboots]

Ok, progress so far. The "int: number of instances" stuff. It turns out that bogies are nice here too, because they cannot be simplified any further when the camera zooms out. That means there is only one instance declared. That, in turn, tells me something about how the values of the bytes are declared. For instances, 01 00 00 00 means "one". Lovely, yes? How much less confusing could it be?

berkshire_hex_basics.png (29.64 KiB) Viewed 12047 times

Then we get to the float centre, which defines where the centre of the bogie will be on the finished model. That will be the same on both bogies, for everything except sideways. Sideways is gonna be dfferent, coz we have a left bogie and a right bogie. For some odd reason (everything in RRT3 is for odd reasons) the sideways axis in RRT3 is the x axis. The frontwards and backwards axis is the y axis. Usually, in a lot of apps, it would be the other way around, but that's whats we gots for RRT3.

Z axis is up and down, which is normal. I'm sure RRT3 would have made it weirder, but with only three directions to go in they were sorta stuck with leaving this one normal. You get that.

So, the next twelve bytes give us the x, y and z coordinates.

berkshire_hex_bogie_centres.png (28.83 KiB) Viewed 12047 times

Obviously, most of this is the same in both files. The only thing that is different is that "00 00 3E C0" in the first file becomes "00 00 3E 40" in the second file. Ok, so somehow this tells us that the first bogie is sideways out to the left of the loco (by an amount equal to half the track width, presumably) and the second bogie is sideways out to the right of the loco. Cool.

Exactly how does it tell us this? No idea, mate. Still working on that bit. Anyone else know?
All joking aside, this is important to know. It will be tied into how the files indicate negative coordinates, and people will need to know this to understand the structure.

The frontwards to backwards location of both bogie axles is given by "ED 1E 5F C1", and the up and down biz is done by "09 0A 4D 40", which is (in some weird language) the distance above the track.

[Gumboots]

Ok, another bit. The "4 bytes : "INST" = bytes: 73 78 83 84" stuff. This will just be some generic indicator thingy we don't have to worry about. One thing I noticed that WP&P did on his page was to convert the byte values to decimal, which is probably going to be confusing for any beginners who are looking at the hex code.

In hexadecimal, "73 78 83 84" is not written that way. It is written as "49 4E 53 54". You can see this in the next screenshot.

berkshire_hex_gibberish.png (27.91 KiB) Viewed 12047 times

This is also why WP&P's page mentions weird numbers for the earlier file header stuff. Just something to be aware of, but not a problem if people are aware of it.

Ok, so according to his guide, the next thing we should see are four bytes for the number of points (or vertices, as they are usually called), followed by four bytes for the number of faces. Check the next picture for these.

berkshire_hex_vertices_faces.png (27.35 KiB) Viewed 12047 times

This is handy, because I now know how these values are declared. You see, there are 8 vertices and 4 faces in the bogies. You can see these in the next pic, which shows the wireframe for the bogies.

berkshire_bogie_wireframe.png (3.95 KiB) Viewed 12047 times

The way this works is that the game just calls a square out of the .tga image, and the bits that aren't bogie are just transparent. The reason for having two squares that are offset is to give it the flanged wheel appearance. The bigger square does the flange, and the smaller does the centre. Each square is divided into two triangles, because 3d gfx apps just do it that way, so there are four "faces".

So, we know that the bytes "08 00 00 00" are telling us "Hey people, we got eight vertices in this sucker" and the following bytes "04 00 00 00" are saying "Oh yeah and there are four faces". Cool. That bit I can understand. For once they are using numbers that make sense. It wont last though. They're bound to go back to being weird.

Still, at least we know something, which is better than knowing nothing.

That's the end of the easy stuff for now. I need to think about the next bits.

[Gumboots]

Ok, before going any further I had an idea. I already know that 04 00 00 00 means four faces, or four vertices, depending on where it comes in the file. What I wanted to know now was how the numbers are represented when they get too large for one byte to handle. That means opening a file with a lot of vertices and faces. The obvious example is BerkshireL_Body.3dp.

Turns out that file has 827 vertices and 727 faces. The way they are represented in the hex is like this:

berkshire_hex_numerical_syntax.png (22.21 KiB) Viewed 12042 times

Now at this point you might be thinking "How the @%#$ does this mean 827 vertices and 727 faces?" They've gone and used a rather odd (putting it politely) way of representing the numbers. Not only is it in hexadecimal, but it's in sorta backwards mutant hexadecimal. It works like this:

In basic hex, 827 would be written as 33B, and 727 would be written as 2D7. That's because the first column repesents multiples of 16 squared, the second column represents multiples of 16, and the last column is anything from zero to 15. So, 3 x 16 x 16 = 768, and 3 x 6 = 48, and B is 11 in hex (really), so 768 + 48 + 11 = 827.

Knowing that, it becomes obvious how the RRT3 .3dp syntax works. Instead of writing "00 00 03 3B" and "00 00 02 D7", which is what I would have expected, they've turned it around just to mess with our heads. So, they write it as "3B 03 00 00" and as "D7 02 00 00".

Ok, it's mean and nasty, but at least we know now, so the sneaky mongrels can't trick us any more.

That also tells me something about the sideways coordinates for left and right bogies, back here:



"00 00 3E C0" in the first file becomes "00 00 3E 40" in the second. That probably uses a different syntax for the point positioning. Why? Because if it didn't, the numbers given would be insanely large. Way up in the millions. Really. That would be a crazy way of specifying positioning for something as small as a locomotive model, so they have probably chosen a different way of writing the numbers. How? No idea at the moment.

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

ETA: Just thought of something. On the second line of BerkshireL_Body.3dp the bytes start like this: "05 00 00 00". Recall that these bytes give the number of "instances" for the body. Thinking about it, that tells me that the game will expect to see A, B, C, D and E skins for the body, and sure enough that's what the files say.

Presumably, the reducing numbers of vertices and faces for the wireframes for these skins are coded into the .3dp file for the body, one after the other. I haven't got that far yet, but if so it would explain why such files get so complex.

[Gumboots]

Aha! All it needed was to look up IEE754 single precision floating point format.

Say what? Umm, well, it's how they tried to confuse us even more. Them bogie axle positions. They use single precision floating point format, which means they're in some weird mutant variety of binary, but are still written in hex in the .3dp file, so to get them to make sense you have to run them through a hex to gibberish converter thingy.

I found one here: IEEE 754 Converter

So, taking those bogie axle bytes out of the file there's "00 00 3E C0" and "ED 1E 5F C1" and "09 0A 4D 40" for Bogie 1 x,y and z positioning. Then there's "00 00 3E 40" and "ED 1E 5F C1" and "09 0A 4D 40" for Bogie Two the Second.

Ok, so since those are in RRT3's special weirdness hex syntax we have to convert them to basic hex. That means Bogie 1 x coordinate is C03E0000, and if you run that through the converter thingy you get............

...you're gonna totally love this.............

-3. Yup, good old basic everyday version minus 3. Now, you might reckon they could have just said "Hey guys, it's minus three" but no, that would have been too easy. People might actually understand that, which would be no fun at all.

What about Bogie Two the Second and his band of merry men? His x coordinate is 403E0000 in basic hex, and after running that through the converter thingy we get 3. Yup, 3. Just 3.

WP&P's page, way down the bottom, tells me that positive x values are on the left side of the train, and negative x values are on the right side of the train. That means that the file BerkshireL_Bogie1.3dp, since it has a negative x value for the bogie centre, must be for the right bogie. BerkshireL_Bogie2.3dp, since it has a positive x value for the bogie centre, must be for the left bogie.

So, the centre of the left bogie is 3 units to the left of the middle, and the centre of the right bogie is three units to the right of the middle. Well why the @&#! didn't the silly @&#^%!s just say so?

What about up and down and back to front positions? Y coordinate (front to back, or back to front, or whatever) is "ED 1E 5F C1" in RRT3doublespeak, which is C15F1EED in basic hex. Run that through the converter and we get -14. The Gospel According to WP&P (hallelujah) tells me that negative y values are forward of centre, so that bogie axle is 14 units forward of the middle of the loco.

As for upanddownness, z coordinate is "09 0A 4D 40" in RRT3, which is 404D0A09 in hex, which comes down to 3.2. So, axle is 3.2 units above the track.

Finally, this is starting to make sense. That is, of course, if you define "starting to make sense" sort of like "well if you convert octopuses into Swahili, then take the square root of the product of a hippopotamus and an aardvark's cousin, and multiply that by the inverse square law of electromagnetic radiation and stuff, then throw in some fudge factor just for fun, it all makes perfect sense".

[Wolverine@MSU]

I nominate Gumboots for "Sleuth of the Year" award. I look forward to your future posts as you work to unravel the "logic" in the rest of the 3dp files. Once you finish that project, perhaps you could turn your enthusiasm toward identifying where heightmap info is stored in the .gmp files. I've always thought it would be useful to have utilities like PJay's BMP2GMP / GMP2BMP duet to inject/extract heightmap info from a map.

[Gumboots]

It's not so much enthusiasm as annoyance. I just got fed up with looking at the silly things and not understanding them.

I'm just posting stuff as I figure it out, without much in the way of polish. I don't think we'll ever be able to get this down to a total no-brainer, but if we kick it around enough we should be able to end up with some fairly good basic documentation, which will hopefully make things easier for anyone who is game enough to tackle a bit of customisation.

[Wolverine@MSU]

It's not so much enthusiasm as annoyance. I just got fed up with looking at the silly things and not understanding them.

Good for you Gumboots! Too many people in this world just throw up their hands when they don't understand something and don't try, or care, to understand them.

States of Matter.jpg (37.88 KiB) Viewed 10830 times

[Gumboots]

Ok, next bit. Into the bytes that define the eight vertices for each bogie.

The first shot shows the first four points. It turns out that these are for the bogie tyre. After running the hex through the IEEE 754 converter, I got values that made sense here too.

berkshire_hex_bogie_tyres.png (25.81 KiB) Viewed 10817 times

Recall that the end point of each axle was 3 units from the centre of the tracks, and 3.2 units above the top of the tracks. That implies that the tyre diameter should be 6.4 units. It is.

The bytes "00 00 48 C0" and "00 00 48 40" describe four vertices on each bogie, that are 3.125 units to the left and right of centre. These form the outside faces of the tyres, and the wheel centres inside the tyres.

The bytes "F9 2F 89 C1" and "E7 DD 2B C1" locate the vertices 17.148 units and 10.742 units in front of the centre of the loco. These define the forward and rear extremities of the tyres for each bogie.

The bytes "11 07 CD 40" and "ED 0D BE 39" locate the vertices 6.407 units and 0.000 units above the top of the tracks. That gives us our 6.4 unit tyre diameter, which matches our axle height of 3.2 units.

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

Next we have the flanges. Screenshot here:

berkshire_hex_bogie_flanges.png (25.37 KiB) Viewed 10817 times

The bytes "00 00 34 C0" and "00 00 34 40" describe vertices that are 2.813 units to the left and right of centre. These form the faces of the flanges.

The bytes "B2 7E 8A C1" and "76 40 29 C1" locate the vertices 17.312 units and 10.578 units in front of the centre of the loco. These define the forward and rear extremities of the flanges.

The bytes "F2 41 D2 40" and "22 FD 26 BE" locate the vertices 6.571 units above, and -0.163 units below, the top of the tracks. That gives us a 6.735 unit flange diameter, which makes sense too.

Will take a break before I get into the triangle definitions. Got some other things I need to do.

[Gumboots]

Before getting too serious with the definitions of triangles, image mapping, normals, etc, I took a bit of a breather and mapped out the positions of all the wheels. This was done according the the basic x,y,z coordinates just like for Bogie 1 and Bogie 2. I then put the coordinates into a handy app I have, just to see if it was all looking like it should.

Fortunately, it does look like it should, which is nice.

Attached is a screenshot of a perspective view from front right, looking back, with the wheels named the way they are named in the .3dp files.

Berkshire_wheel_arrangement.png (72.9 KiB) Viewed 10800 times

Now at this point some clever person is going to say "Hang on, that can't be a Berkshire. It's a Mikado!". I know that. Lirio knew that too:

It's not even a real 2-8-4, if you look closely it still has a single rear axle, just covered up. All i see when looking at it is just a reskinned Mikado with its rear wheels obscured so we can all pretend it has four instead of two.

Which is right, as you can see from the screenshot. Now if someone wanted to add the extra wheels, I reckon we have enough information to know how to do it now. However, to really be a Berkshire it would need the body stretched to have the larger firebox. Otherwise, the rear wheels will be too far back, the body will be too short, and it wont look right. That's possible, but more work. Personally I'm not quite ready to try that yet.

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

By the way, I think I figured out what the unit size is supposed to be in RRT3. Outside faces of wheels/tyres are 6.25 units apart (3.125 from centre, each side). WP&P mentions this on his page, and tries to equate it to standard gauge. However, he seems to have forgotten that gauge is measured to the inside faces of the rail tops. The outside faces of the wheels are, of course, roughly flush with the outside faces of the rail tops.

Standard rail stock of around 50kg/metre or so (that's around 110 lb to you Yanks) has a top face close to 3 inches wide. If you add the width of the rails (6 inches total) to the standard gauge (56 1/2 inches) you get 62 1/2 inches. This is 6.25 units in RRT3's language, so it looks like they intended one unit to be exactly ten inches.

This is a handy scale to work with. It's even handy in metric, because ten inches is as near as makes no difference to 250 mm. It's actually 254 mm, but nobody would notice the slight discrepancy on RRT3 locos and rolling stock. So, we can call "one unit" either ten inches or one quarter of a metre, whichever you like to work in.

[Gumboots]

Ok, next bits. Another screenshot.

berkshire_hex_first_triangles.png (21.71 KiB) Viewed 11487 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 11478 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 11439 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.