Re-skinning for beginners (that's me)

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