Re-skinning for beginners (that's me)

[Gumboots]

That's nice of them, and probably makes good business sense too. Photoshop really is easier to use than GIMP, IMHO, and CS2 would be perfectly adequate for a lot of people. Everyone here who's interested in skinning should grab that if they don't have PS already. It's always good to have another image editor in your kit. Sometimes one will do things another wont.

[Hawk]

I primarily use Paint Shop Pro X (10), but I use CS2 to create dds files.

[Gumboots]

I'd heard of it but never looked at it. I just checked Corel's website. It's surprisingly cheap. How versatile is it compared to PS?

[Hawk]

I find PSP easier to use than CS2, and I can do most anything i want with it. Alphas, masks, perspective correction, etc.
It could be because I'm used to it. I've been using PSP since V-7, plus I also got PSP 10 free in a Corel giveaway, right after they bought out Jasc.
Unfortunately, that version is no longer available.

Love those freebies.

[Gumboots]

Yeah being used to it would help a lot. I'm sort of used to PS now. Will probably stick with it just because of that.

[Hawk]

I don't blame you. Stick with what you know. It makes things easier.

[Gumboots]

More techy stuff. WP & P's .3dp editing notes have this about files for lights:

LIGHT

4 bytes: "LGHT" - bytes: 76 71 72 84
4 bytes: int: number of lights

If number of lights = 1
--------------
12 bytes: int: 00 00 ... 00 00
4 bytes: float: 0.0 <=> 1.0
3*4 bytes: float: 0.0 <=> 1.0
3*4 bytes: float: -... <=> +... (X, Y, Z)

If number of lights = 2
--------------
4 bytes: int: 0
4 bytes: float: 6 <=> 46
4 bytes: float: 15 <=> 65
4 bytes: float: 0.0 <=> 1.0 (of 2.0)
3*4 bytes: float: 0.0 <=> 1.0
3*4 bytes: float: -... <=> +... (X, Y, Z)
3*4 bytes: float: -... <=> +... (X, Y, Z)

[Editor's Note: I do not yet understand and have not attempted to mod the Lights of a model. The glowing of lit windows, such as on a passenger car at night, is done through the alpha channel of the skin file, not in the 3DP file.]

By cross checking coordinates against the headlight casing and lens of the Berkshire, I've managed to figure out most of it for things like headlights. Check the screenshot:

Berkshire_main_headlight.jpg (80.44 KiB) Viewed 8308 times

So yes, the gfx for the lens do use the alpha channel to get a night glow, but that effect is augmented by the first light in the .3dp file. This appears to have a roughly spherical beam. IOW, it's just a point light that glows in all directions equally (screenshot text is slightly wrong, but I'm too lazy to make another screenshot).

The other light, which is listed second in the .3dp file, is what gives you the main beam you'd expect from the headlight. So, on to the hex:

Berkshire_headlight_3dp.jpg (115.03 KiB) Viewed 8308 times

I've bookmarked and highlighted the various groups of bytes. The entire first row is just the file header. Number of instances is always going to be one (I think) for lights, so that's the next group highlighted in green.

The next 12 bytes, in yellow, give the origin point for the lights. Since the headlight is above the centreline of the track, the X coordinate is 0. That's what 00 00 00 80 for the first four bytes means in Dufous Martian. The next four bytes are the longitudinal distance from loco centre (slightly further forward than the headlight lens) and the height (42 A0 35 41, same as centre of lens in the body file).

After that you've just got four bytes telling you it's a light file. Then you have the number of lights, which we already know is 2.

After that there's 00 00 00 00, which is just padding. My suspicion is that this deals with the game code expecting points and triangles to be defined. Since the bytes for points are taken by the number of lights, the bytes for triangles are just set to 0, since there are no gfx faces called for lights.

After that there is a group of 24 bytes, highlighted in green. These are obviously something to do with the spherical light that does the general glow effect for the lens. I've labelled these "Glow light voodoo" because me is still a bit bamboozled by these critters. The values given don't make any sense to me in terms of coordinates or normals, so someone will have to figure that out later.

The second last group of 12 bytes, in yellow, does make a lot of sense. As you will see if you check, it's the same coordinates as the origin point of the lights. IOW, this is where your main headlight beam starts.

The final group of 12 (green) tells the game engine how far that headlight beam goes. It's still got 00 00 00 80 for sideways, which means it points straight forward. The longitudinal coordinate (8F 2A A1 C2) means it goes out to a distance roughly 42 feet in front of the origin at full scale. The vertical coordinate at the end of the beam's range (22 AE 36 41) is different to the origin by roughly 3/4" at full scale. IOW, this is just another default code rounding error or dev user error or something. They presumably should be the same values.

So there you go. Headlights mostly sorted. Should apply to a lot of other lights too.

[Gumboots]

Ok, the next bit: custom coding boilers, cylinders, etc from scratch. So far I've managed to sort of psyche myself out a bit on this one. It's not a job I've been looking forward to, since it involves writing a pile of hex from scratch. However, last night I started doing some serious thinking about it and realised it's not really all that bad.

The key will be to write the code so that it's modular. IOW, split things down into the simplest components, so that anyone who wants to modify it later doesn't have a huge, tangled pile of gizzards to deal with. If it's done that way, any components can be taken out and reused anywhere else with a minimum (by RT3 standards) of fuss. This is about writing maintainable and usable (for humans) code rather than just trying to write the most efficient code for the game engine. The game engine is very capable, and should handle the results as long as things don't get totally silly.

So, since cylinders (meaning round things in general) are used so much for modelling I reckon those are the place to start. There needs to be several examples of these, with different numbers of sides. Small items like (pipes) can get by with something like 6 sides. Boilers and smokeboxes need somwhere around 24 to look really good, as far as I can tell at the moment. Some exceptionally large items may even need a few more sides, but they wont be common. These all turn out to be fairly easy to code. Actually getting it all written down in the hex without typos will be the main part of the work. The mathematics/geometry side of it is fairly basic.

IMO, it makes sense to use polygons that give simple numbers for the angles between the sides. With computers and calculators we don't have to, but it's just easier to wrap my head around, and being able to keep quick mental checks of results helps prevent GIGO. This is good. It also means no typing of really strange fractions of degrees when working stuff out, which is another bonus.

IMO numbers of sides for cylinders which make sense, and angles between the sides, go like this:

6 sides: 60 degrees
9 sides: 40 degrees
12 sides: 30 degrees
18 sides: 20 degrees
24 sides: 15 degrees
30 sides: 12 degrees
36 sides: 10 degrees

That should be an adequate range, without getting really picky about it all. Next it's a matter of getting the actual coordinates and normals. This turns out to be easy too. Taking a boiler as an example, the stuff you need to know to start with is shown in the next pic. You need to know the radius, the distance from the centreline of the loco (0 in the case of a boiler) and the height above the ground. This height can be to any point, but I chose the middle of the thing.

Cylinder_coding_example.jpg (36.61 KiB) Viewed 8303 times

Once you have the H, W and R you're all set. Looking towards the rear of the loco from the front, taking 0 angle being at the top, A being the angle to the vertex, and going clockwise, Z just becomes H + R(cosA) and X just becomes W + R(sinA). The normal is just cosA for the Z axis and sinA for the X axis. This will apply to all cylinders that have the same orientation.

If a cylinder has a different orientation, like a funnel instead of a boiler, the numbers all stay the same anyway except that you'd be swapping Z values for Y values when it comes to the normals and heights (which would change to "lengths" if stood on end). It would be possible to whip up a script or whatever that has all the basics ready to go. Then you could just enter your radius (R), height (H) and width (W) and it would spit out the coordinates and normals for any point.

Once one example (like a 24 sided boiler) is coded in the hex then it becomes a fairly easy to use example for any other 24 sided cylinders.

Things get a bit trickier for more complex shapes like steam domes but again, once one example is worked out it should be usable in a lot of places, and it should be possible to have it scripted so it can be used to generate new values easily. Steam domes, etc really just require knowing the angles between the sides in all three dimensions, which isn't quite as bad as it sounds.

[Gumboots]

Just tried out the GIMP DDS plug-in to see if it would give results the game would digest without hiccups. It does.

I'll still mainly be using PS, but for those who prefer to use GIMP, for whatever reason, it looks like opening, editing and saving usable DDS images is no problem. Aparently the DDS plug-in for GIMP is now supported and stable.

Plug-in can be downloaded here: http://code.google.com/p/gimp-dds/downloads/list

Save any work with DXT3 compression selected and it should be fine.

Just for a quick test I saved the A skin for the black (default) version of my Berkshire and swapped that for the A skin of the green version. It runs in the game without any problems. It also demonstrates something about the game engine that I noticed while doing the H10-to-Berkshire graphics work.

The first close-up pic shows the black version's A skin, as you'd expect. The second pic shows the green B skin being rendered on the underside of the boiler. This appears to be because the game engine uses a combination of two things to decide when to switch skins. These two things are actual distance to the surface, which is obvious, and the angle of the surface to the camera, which is not so obvious.

A_skin_close.jpg (57.12 KiB) Viewed 8205 times

B_skin_underneath.jpg (56.25 KiB) Viewed 8205 times

Further examples follow. As you can see, the skin rendered for any part of the model varies depending on how it's viewed. It's not an all-or-nothing situation. The model can be using the A skin and the B skin at the same time, and presumably this sort of thing also applies for B and C and right down through the list.

B_skin_fade_in.jpg (61.93 KiB) Viewed 8205 times

B_skin_fade_in_3.jpg (56.63 KiB) Viewed 8205 times

B_skin_complete.jpg (47.42 KiB) Viewed 8205 times

Although I haven't tested it yet, it's also logical to assume that the same changeovers apply to the instances in the .3dp files. This would mean that even at quite close range, the model is potentially using the first (most detailed) mesh for some parts and the second (far less detailed) mesh for other parts, even those these other parts may still be quite close to the camera. That's obviously going to degrade the appearance of some parts of the model.

One solution that has occurred to me is that if using a file with multiple instances it may be beneficial (in terms of appearance) to make the second instance the same as the first, and then go down the list from there. This should (I think) mean that by the time the model transitions to a less detailed mesh it will be far enough away that it wont bother anyone.

[Gumboots]

Ok, got some more figured out about lights. Don't like the colour of your train's lights? Want to change them a bit? No problem. You can do.

Carrying on from my earlier post, I had a brainwave and figured that the unknown "glow light voodoo" I'd bookmarked must have something to do with colour, otherwise the game wouldn't know what colour the light was.

Since I knew that the gfx mapping used percentages of total image dimension to map the faces on the skin, it occurred to me that the lights files might be using percentages of 255 to call RGB colour codes for the lights. This turns out to be correct.

Picture that follows shows the headlight (upper file) and the small running lights up front (lower file) for the Berkshire or H10 (same files).

Headlight_and_running_light.png (37.71 KiB) Viewed 8137 times

I've now got all the code for double light files worked out. After all the basics (header, etc) comes four bytes highlighted in blue and labelled as "main beam distance" (hex values 9A 99 8D 41). This seems to be the distance the main headlight beam extends forward of the origin point. If this value is set to 0, the headlight beam disappears and only the much smaller spherical light (for lens glow) remains.

The next four bytes (highlighted in red and labelled "Outer beam flare angle") determine the angle of a secondary halo around the main headlight beam. Increasing the value widens the angle. Decreasing it to 0 leaves just the main headlight beam, which is fairly narrow.

The next four bytes (blue highlighting again) are for the glow radius for the spherical light. This is 0.65 in the case of the Berkshire/H10/J1 Hudson headlight (ie: 86% larger than the running lights).

After that comes the colour code. For the headlight the hex translates to 1, 0.976, 0.784 in decimal. Taken as percentages of 255 those give you an RGB value of 255, 249, 200, which can also be written as #FFF9C8 in the usual CSS format (for those who do a bit of web coding). This is a very pale yellow, almost white, which tallies with what you can see in the game for headlights.

Following that are the origin point for the headlight beam (same values as the origin point earlier in the file) and the point the beam aims at. This last one is further forward than the extent of the beam itself, and the value is probably not critical as long as it's a bit greater than the beam extent.

The files for single lights (most lights are singles) are now fully mapped too. The glow radius is defined using only the last four bytes in the glow radius group. In the case of single lights, the first eight bytes of that group are just padding. For the running light this glow radius turns out to be 0.35. I'm not sure what the units are, but it doesn't really matter since the size can be adjusted by eye if anyone wants to change it. The colour code for the running light is the same as for the headlight: RGB 255, 249, 200 or #FFF9C8.

Moving on to the backhead lights inside the cab (earlier notes here) the following pic shows the files for the (larger) firebox light and one of the small yellow lights at upper right of the backhead.

Firebox_and_small_yellow.png (35.08 KiB) Viewed 8153 times

The small yellow light has a glow radius of 0.25 and a colour code of 255, 234, 0 or #FFEA00. Not surprisingly, that turns out to be a bright yellow. The firebox light is larger (radius of 0.55) and has a colour code of RGB 255, 244, 116 or #FFF474, which is a fairly pale yellow. I'd been thinking the firebox light really could do with a bit more fire in it. Turns out to be easy. Might change it sometime.

Last pic shows the file for the small green light at upper left of the backhead. That turns out to have a glow radius of 0.2 and a colour code of RBG 0, 255, 56 or #00FF38. Funnily enough, that's green.

Small_green_light.png (18.22 KiB) Viewed 8153 times

So there you go. All light files fully mapped. Custom colours for any lights are easily available if you want them.

[Tomix]

How do you properly edit .lco and .car files? Every time I try to edit mine it gives me an error in-game, or the game just crashes.

[Gumboots]

Depends exactly what you want to do.

[Tomix]

I'm trying to rename the Black 5 into "Henry The Green Engine" and the A1 into "Gordon The Express Engine", with the Black 5 tender on the A1 instead of the corridor tender.

[Gumboots]

Umm. K. TBH I'm kinda new at this. Athough I've managed to figure out a lot of stuff, I sometimes can't quite remember how I did every bit of it.

I may miss something, but the basics are that you have to have the relevant assets for every new engine. If you just want to change the displayed name in the game, and nothing else, then here's a screenshot. First green highlighted group is what defines the displayed name.

Example_car_file_for_loco.png (26.36 KiB) Viewed 7755 times

The section that handles the in-game name has to be sixty bytes long (five lines at twelve columns). All groups in .car files have fixed lengths. If you change the number of bytes it'll mess things up.

The name has to be followed by a blank that has the hex code of 00. Anything after the blank is dropped from the display.

Don't use a standard spacebar blank after the name because that wont work. That has a hex code of 20 (you can see examples in the shot) and is used for punctuating the name, but you need the 00 after the name for it to work.

The rest of the 60 bytes is just filled up with padding that has a CD hex code, to make up the 60 bytes. You can see how it works in the pic.

000 : 4 : EA03 0000 : 1002
004 : 4 : int : car group
008 : 4 : int : car id (not always unique !!)
012 : 60 : in-game car name
072 : 60 : LCO file name
132 : 30 : 3DP file name
162 : 30 : DDS/TGA file name (sometimes same for loco/tender, sometimes different)
192 : 60 : IMB file name (CarSideView_1.imb or CarSideView_2.imb, CarSideView_3.imb for CtC trains)
252 : 4 : int : engine id (loco+tender, for each CarSideView a new count)
256 : 2 : ? : 0101
258 : 4 : int : start year
262 : 2 : ? : 0101
264 : 4 : int : stop year
268 : 4 : float : car-weight

[Gumboots]

Hey let me get this straight: are you trying to build new engines, or just trying to change the name and tender on an existing one? It's probably better to build new ones, because then you can change what you like without getting conflicts with the default ones.

[Gumboots]

Ok, drivewheels, pistons, connecting rods and coupling bars.

These are classic things to screw up when modifying locomotive models. A lot of third party locomotives have these broken to some extent. You don't need to screw them up, because it's not too difficult to get them right if you remember a few basic principles.

You can forget tricks like quartering the wheels, or like properly angling the crankpins for multi-cylinder locomotives. It would be nice if we could do this, but unfortunately the game is simply not coded to handle that sort of geometry. It will only handle one basic layout, and that is what we are stuck with.

The layout we are stuck with is easy to remember and fairly easy to implement. The only tricky bits about it are setting up the piston and connecting rod .3dp files to do the graphics correctly, because this involves a bit of basic trigonometry. It just does, so don't grumble about it because that wont change anything.

The first thing you need to know is that the points in the .3dp files where the connecting rod and coupling bar attach to the drivewheel must be vertically below the drivewheel's axle when you are looking at it from the side. In other words, the attachment points for connecting rod and coupling bar must have the same y axis value as the drivewheel axle, and must have a lower z axis value.

There are no exceptions to this rule. If you try to mess around with this geometry you will end up chasing your tail. If you use this positioning and things don't look right, then you need to work on your connecting rod and/or coupling bar gfx, because it will be those that are wrong.

Drivewheel_basics.png (38.81 KiB) Viewed 8543 times

The next thing you need to know is that regardless of how your graphics are set up, when looking at the locomotive from the side the piston will always travel on a straight line directly between the point defined in the piston file and the axle of the drivewheel. This means that your gfx for your cylinder and piston need to be set up so the central axis of the piston and cylinder bore are along this line. If they aren't, the piston will slice vertically across the cylinder to some extent during its stroke. You can see this happening on quite a few third party locomotives if you watch the piston in slow motion. How bad it will be depends on the difference in angle between this line and the axis of the cylinder and piston graphics.

Also, the initial position of the piston graphics needs to be such that it wll look right at top dead centre and bottom dead centre in the cylinder, bearing in mind that this initial positioning you are stuck with will usually put the piston roughly halfway through its stroke. I say usually and roughly because there can be exceptions.

The Beuth has cylinders that are steeply angled, but the drivewheel attachment point still has to be vertically below the drivewheel axle for things to work properly. This means the intial position of the Beuth's piston is not roughly halfway through its stroke, and the same will apply to any locomotive with similar cylinder positioning. To get it right you will need to use trigonometry.

Even if the cylinders are exactly in a horizontal line with the drivewheel axle, the piston will still not be exactly halfway through its stroke because of the angle of the connecting rod. It will actually be slightly more than halfway to bottom dead centre. Yup, trigonometry may be required if things are tight.

Again, there are no exceptions to this rule. If it looks wrong, your graphics are wrong. Work on those.

Piston_basics.png (39.73 KiB) Viewed 8543 times

The third thing you need to know is that the point defined in the connecting rod file determines where the connecting rod attaches to the drivewheel. As already mentioned, this must have the same y axis value as the drivewheel axle, and must have a lower z axis value than the drivewheel axle.

The graphics for the connecting rod have to be set up so that it runs between this point and the point defined in the piston file. If they aren't, it will look wrong. Again, don't try and mess around with this geometry or you will end up chasing your tail. Fix the connecting rod graphics, because they will be the problem.

ConnectingRod_basics.png (40.1 KiB) Viewed 8543 times

The last thing you need to know is that the coupling bar must attach to the drivewheel at the same y axis and z axis values as the connecting rod. The x axis value is usually offset (should be*) so that the coupling bar will be inside the connecting rod, but don't try and mess with the y and z values. Yes, you guessed it, you will end up chasing your tail again. If it looks wrong, fix the coupling bar graphics, because those will be the problem.

Don't worry about anything else the coupling bar might do. It always stays parallel to the track. As long as its attachment point to the drivewheel is set properly to start with it will be fine.

CouplingBar_basics.png (41.08 KiB) Viewed 8543 times

So there you go. RT3 drivetrain basics 101.

*ETA: Just found out something else. Actually the x value for the coupling bar and connecting rod shouldn't be offset. It turns out the game engine is a bit trickier than that.

What I've discovered since writing this post is that the defining points for connecting rod attachment to the drivewheel, and coupling bar attachment to the drivewheel, and the offset of the rotation centre for all wheels (drivewheel, coupled, bogies whatever) should all have the same X axis value. This sorts the drivetrain geometry perfectly. To get the connecting rod and coupling bar visually outside the wheels, the points for their graphics are offset relative to the attachment points.

If the attachment point of the coupling bar is set further out than the rotation centre of the drivewheel this will throw things out of whack. No matter how much you try to offset the coupling bar it will still look like it's stuffed through the drivewheels from some angles, even though the points that define its graphics are well outside the wheels. As soon as you put the attachment point at the same X axis value as the rotation centre of the drivewheel, suddenly the coupling bar graphics pop outside the wheels to the spot where you want them.

[Tomix]

I'm just using existing engines. I really don't have the patience to do all this hex editing.

[Gumboots]

Yeah what I meant was it's probably less hassle to use all the hex for an existing one but package it as your own TTE version so the game thinks it's a new engine. No conflicts that way.

[Tomix]

Yep, that was the plan.

[Gumboots]

Hey I just found out something amusing regarding drivetrain coding. I'm already planning on using four layers for wheels (like the default Planet and American 4-4-0). Since extra instances are easy to generate manually for wheels, I'm thinking that unlike the default models it'd be a good idea to provide extra instances (ie: lower level of detail) to drop the inner and middle layers when zoomed out.

That got me wondering about other details. I had an idea that just for fun it might be cool to code in faces for axles on the first instance of the drivewheel and bogie files, and drop them out for the other instances. This should mean no real performance hit but better looking trains. Obvious way to try the basic concept was to take an existing drivewheel and shunt one of the faces out to the other side of the train just to see what happened. This had some interesting effects.

What it does it put that drivewheel out of sync with the other wheels. The connecting rod and coupling bar still follow the drivewheel properly, but the rotation of all that stuff is not the same as the rotation of the other (driven) wheels on the same side. So, then I tried it with the same layer on the centreline, then slightly to the right side of the centreline, just to see if the odd effect on rotation was due to crossing over from one side of the train to the other.

It isn't. The rotation speed is still affected even if the layer that is shunted sideways is kept on the same side of the centreline. It seems that axles will work, as long as all wheels have them. The rotation will still be affected, but should be affected equally for all (although this has not been tested yet). So, if axles look cool close up we can probably have them without ill effects. They'd just be square in section since that'll look fine when they're spinning and it's easiest to code.

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

This stuff then got me thinking some more (I have a bad habit of doing that). Since the wildly offset layer affects the rotation of the wheel, this opens up the possibility of faking quartering, if anyone wants to. If the wheels on one side are matched to each other with regard to layer offsets but not matched to the wheels on the other side, the wheels on each side will rotate at slightly different speeds. So, if only the wheels on one side are given axles, and these axles extend across the centreline and out to the hubs of the wheels on the other side, then the whole drivetrain on each side should behave properly but the two sides will be out of synch. That should mean that they will give a pretty good imitation of a properly quartered drivetrain. They'll line up every so often, but most of the time will be staggered to some degree.

This would be cool if (when) I get around to doing Garratts. It was bugging me a bit the the front and rear drivetrains on the same side of a Garratt would have the crankpins in the same relative position, just because of how the game engine requires the base geometry to be set up. However, if the front drivetrain on the right side is given axles, and the rear drivetrain on the left side is given axles, this should mean the front and rear drivetrains on each side will be staggered most of the time. This would be kinda cool.