Re-skinning for beginners (that's me)

[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 9137 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 9137 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 9137 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 9137 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.

[Gumboots]

I'll have to test this stuff more extensively when I get time. Had some more thoughts about the whole axle/offset thing.

I was wondering why the default models that use extra wheel layers didn't have lower levels of detail specified, since the game devs seem to have done that where possible. One possible glitch is the shift between instances. As I found when testing skins, the model can be using the A and B skins at the same time, even when the camera is quite close to the train. This would also apply to the B and C skins a bit further out, and so on. This could give problems wth dropping layers from the wheels, since changing the layer offsets will change the rotation speed. If one or more wheels on the same side are using the A skin and others are using the B skin, the drivetrain on that side may appear broken to some degree. Since the shift from A to B happens quite close in, when things are quite noticeable, this could be a problem.*

The most likely solution would be to specify 5 instances (which seems to be standard for body files, etc) and not start dropping layers until the third instance. That would hopefully delay any problems until they would not be noticeable (ie: camera zoomed out far enough). If they are still noticeable at the changeover from second to third instance, dropping layers could be delayed until the fourth. The game engine wont care if the first three instances are identical. It'll just render the code it's given. As long as the last instance has minimal detail (one layer only with no axles or whatever) then most trains in the game should be running at that level most of the time.

It also occurrred to me that the idea of faking quartering by using a different combination of offsets on the left and right sides could work without using axles or whatever to generate the difference in offsets. All that would be required would be to use a different X axis value for the rotation centres on each side. Even if all wheel/axle/whatever layers are mirror imaged on both sides, changing the X axis value for the rotation centres will still stagger the left and right side drivetrains.

IOW, usually it'd be (for example) +3 for the left side and -3 for the right side, which synchronises the two sides. If +3.5 was used for the left side and -4.5 was used for the right, the two sides would be out of synch and would look staggered most of the time. The difference between the two sides would be constantly varying from 0 to 180 degrees, depending on the distance travelled. If carried to excess, the difference in rotation speed would look stupid. If it was fairly subtle it could work quite well.


*This instance changeover thing would only be a problem for drivetrain wheels (if it's a problem at all). Other wheels like truck bogies would be fine since they aren't required to be synched to anything else. Provisional plan for those is to use four layers for the first and second instances (just so thing still look cool when using both first and second instance at close camera range) then drop the middle two layers for the third instance, then drop the innermost layer (the one that does the flange) for the fourth instance, leaving only the outermost layer to give the appearance of the wheel. It should work, AFAICT.

Also, to make the coding easier, I've figured out that the order of the points and faces should be outer layer first, followed by inner ("flange") face, then the two middle layers. Doing it this way simplifies coding the instances, since the last ones can be dropped without requiring any change to point numbering in the ones that are being kept.

[Gumboots]

Just tried a quick test of this fake quartering idea. It works quite well.

The rotation centres had been set at 00 00 34 40 and 00 00 34 C0 (+/- 2.8125 units), so I switched the ones on the left side to 00 00 04 40. This was done for the drivewheel, the three coupled wheels, the piston, the connecting rod and the coupling bar on that side. Doing them all equally is necessary to keep that side properly sorted.

The result is that the train choofs along with the wheels more or less quartered most of the time. The difference in rotation speed isn't really noticeable when you're just watching it, and there are no drawbacks that I can think of. So, it's a viable option if anyone wants it.

[nedfumpkin]

Not sure if you got an answer to this or not, but the tga files packed with the game are mostly 1024x1024. The skinning tools versions are 512x512. I've unpacked all the skins and only use the large ones.

Also, not sure if you know this or not, but it is possible to fix backward lettering on locomotives by making an adjustment to the skin coordinates in some file so that they are reversed on the backward side from what they are. Someone figured out how to do it, It's something I was going to explore in my retirement, But it may be worth considering if you run into the problem.

[Gumboots]

Yes I knew the former, except that they're DDS, not TGA. I made a list of the ones with 1024 skins for my own reference.

Default PopTop steam locomotives with 1024 x 1024 A skins.
=======================================

Early releases:

Adler
American
Atlantic
Baldwin
Big Boy
Challenger
Class 01
Class 500
Duke
Fairlie
Firefly
H10282
Mallard
Norris
Northern484
Orca
Penn 462
Planet
Red Devil
Stirling

-------------------------------
CtC Expansion:

242A1
Class QJ

All other default steam locomotives have 512 x 512 A skins, which give a big reduction in quality compared to 1024 x 1024.

You can't fix the backwards lettering by swapping coordinates all the time. It's a good idea, and it might work sometimes, but would only work if the side that had the lettering was completely symmetric (right down to rivet lines, etc) front to back. Otherwise it would throw the gfx off when you flipped it. The relevant file would be the body file.

There are other ways you can tackle it if you don't mind defining a few extra vertices and faces.

[Gumboots]

So for some weird reason (no idea why) I'm thinking of doing a bit more loco modelling again. I haven't actually played the game itself for about a year, but have this unaccountable hankering to play with loco modelling anyway. Not sure how far I'll get, but since I've been thinking about it I did have a few new thoughts. One is about bogies and drivewheels. These are usually coded in pairs, with separate ones for left and right sides. However, it occurred to me that there is probably no real necessity for this.

Back when I was playing around with drivetrain coding I discovered that I could make one side rate at a slightly different speed to the other side by offsetting gfx layers. This was initially done to try out the idea of having axles on the A and B skins, but can also be used to fake quartering of the drivetrain. However, if fake quartering isn't wanted the layer offsetting principle could be used for another purpose, namely to improve the game's gfx engine performance by reducing the amount of code it has to process.

If left and right bogies (and drivewheels) can be made as one continuous unit, with the gfx layers offset to each side to handle the visuals, then this would halve the number of drivewheel and bogie files required. This means fewer components for the gfx engine to process, so should improve performance to some extent. Whether it would be noticeable in practice is currently unknown, but it may help to give a slight edge for scenarios that heavily load the game engine with massive numbers of trains, etc.

The same principle should also be applicable to other drivetrain components like pistons, conrods, etc. There may be no real need to have pairs of left and rights side files for all of these.

[Gumboots]

I had an idea for testing. There has been some speculation in the past about how high locomotive models can go on poly count without impacting game performance. I'm currently wondering about this myself, for obvious reasons. The easy way to test it is to get a high poly model and run a couple of hundred of them in a game. I can take the AoS IV Blue Streak map, use cash cheats to build a big network fast, then run the game for however many years it needs to get the feel of performance. The .gms could even be zipped and attached here if anyone wants to test the same game on different computers. This is all easy enough to arrange, but it means making a high poly loco model quickly and with little effort.

After looking through my stash of RT3 files, it seems like the best way of doing this would be to use the default H10 Mikado as a base. This is one of the highest poly default locos, which is what's wanted for this test. It has the tender and loco calling the same skin image, which means that with a bit of file renaming I can have the tender running as an extra "truck" on the loco in a similar way to how WP&P did his double cargo car mod. This in turn means that the H10's tender slot can be taken by another H10 and tender, again with the second tender being called as an extra truck on the second loco (which, in game terms, is the first loco's tender).

There would also need to be some tweaking of length points and truck attachment points, but that's not a big deal. The coding for all of this stuff is easy enough to do, and there would be no reskinning required, so the whole shebang is fairly a quick and low stress job. The result would be an H10 double header unit with a vertex count of 2,230 and a poly count of 1,696. If high poly models are going to have a big impact on game performance, this one should make it obvious.

This also opens up the possibility of using the resulting H10 double header as a custom locomotive in its own right, but whether or not that is worth doing will depend on how good it looks when running live. The geometry problems on corners and changes in grade may make it not worth using for anything other than testing. Only way to find out is to try it.

[sbaros]

I'd heard of it but never looked at it. I just checked Corel's website. It's surprisingly cheap.

I am also largely a captive of Corel, since it is the only appropriate TGA-processing utility that I own a legitimate DVD of, and also quite satisfied using it for rapid transit project proposals at my workplace since 1997. Under Linux, I had attempted years ago to use GIMP for similar jobs, but one feature I never managed to locate was the flood-filling of an area with a specific bitmap texture. If anyone has a cheap and user-friendlier alternative to propose, I'd be interested to know.
My first attempt with hauled rolling stock here is to repaint Holger's Wehrmacht coaches for my developing Balkan invasion scenario "Räder müssen rollen für den Sieg". Especially those shiny roofs looked unforgivingly inviting for RAF pilots! However I have not managed to locate any authentic colour photos and I am only marginally satisfied with the result. Maybe anyone with better historic records about the subject could advise creating a more acceptable result? Certainly there must have been different camouflage approaches by the various Feldeisenbahnkommandos, but I still feel that my present job needs substantial improvement.
I am not releasing the bitmaps yet, in case some better proposals arise to make the coaches really worth uploading.

[Gumboots]

The white roof would have rapidly turned charcoal grey in use. This was common for any carriage roof in the steam era. My guess is that they didn't bother camouflaging trains. The standard livery would be reasonable camouflage anyway and the exhaust from the locomotive would be visible for miles. In the case of the Balkans campaign, I think the troop movements by rail would have mostly been done before actual hostilities started. Also, I'm not sure there were any RAF pilots near the Balkans, and the Yugoslav air force was wiped out pretty quickly, so air attacks on trains may not have been considered an issue.