Rolling Stock skinning ideas

[Cash on Wheels]

This gets me thinking what if (hoppers) there was a way (Hoppers!) for the game to call multiple models at random for the same cargo. Like If a train above had 8 loads of weapons, it could call all of those models below even the default pop top artillery guns.!

[Gumboots]

Can't be done. The file calls are hard-coded, so you're stuck with whatever you define as your cargo model for that era. You could mix those up a bit though, by modelling several missiles combined with a few guns if you wanted to. Short version is you're stuck with one cargo model per era per cargo, but you can make it look like anything. I've already tried something similar with hoppers, by giving different load meshes and load skins to individual cars in double and triple sets, but obviously those will repeat if you have a string of cars with the same cargo.

[Akarin]

Makes me wish you could change rolling stock skins in-game like with locomotives.

Or better yet a feature that allows you to create custom paint schemes for locomotives and rolling stock during company creation that incorporated company logos. Though I could see that being problematic for modders adding new locomotives and custom skins.

[Gumboots]

You can do that sort of thing manually if you want to. Say you have a company logo you like using all the time. If you want that on some cargo cars, all you'd have to do is grab the DDS skins, open them in Photoshop or GIMP or whatever, add the logo you want to use, then save them and drop them in UserExtraContent as loose files. It wouldn't take that long to do them, as long as you didn't want umpteen choices of logo.

Which reminds me, I hate a lot of the default logos and never use them. I had thought of making a new DDS, to get rid of the ones I hate and substitute ones I like. You can add custom logos separately, but that's just more crud to sort through when you're looking for one. I'd rather just have logos I like.

Just took a look at the default image. I only ever use 11 out of 36, which is why I'm always trying to avoid 25 cruddy ones. What I should do is add 25 good ones. Easy to do, and more fun for me.

[Akarin]

You can do that sort of thing manually if you want to. Say you have a company logo you like using all the time. If you want that on some cargo cars, all you'd have to do is grab the DDS skins, open them in Photoshop or GIMP or whatever, add the logo you want to use, then save them and drop them in UserExtraContent as loose files. It wouldn't take that long to do them, as long as you didn't want umpteen choices of logo.

Which reminds me, I hate a lot of the default logos and never use them. I had thought of making a new DDS, to get rid of the ones I hate and substitute ones I like. You can add custom logos separately, but that's just more crud to sort through when you're looking for one. I'd rather just have logos I like.

Just took a look at the default image. I only ever use 11 out of 36, which is why I'm always trying to avoid 25 cruddy ones. What I should do is add 25 good ones. Easy to do, and more fun for me.

I have a bunch of custom logos, but the thing I like about the default ones is that the AI only uses them or at least mostly only uses them. At least from what I've seen. It's good because then you don't see Jacksonville & Tampa using a logo that says New York Central for example. Even though I dislike having to use the editor as part of the gameplay, I think I've reached the point where I would rather just open the editor and manually rename and relogo all the AI companies during a game. That way I can at least get interesting competitor names with unique logos.

[Gumboots]

I figured out something about RT3 lighting. It was the (flat and horizontal) tank tops on the new A era tanker model that gave it away.

In real life, you'd always have the tank tops lit by ambient light during the day, regardless of the sun's position, since they are an exposed, flat horizontal surface. They'd never appear to be dark no matter which angle you were viewing them from, because the light bouncing around inside the atmosphere would provide some illumination for your point of view even if a direct line from the sun would result in any direct rays bouncing off away from you.

RT3 doesn't do this. They've simplified the lighting, so that only the direct rays from the sun's position count. This means that if, for example, you are looking at an item from a point to the east of it, and the game's sun is somewhere to the east of the item as well (IOW, it's sometime in the morning) then the game will assume that no light from that item will reach your eye. It will assume that all light hitting the item will reflect away from you, and consequently the item will be shown as if it was in deep shadow even if it is a flat horizontal surface and it's 11 am on a sunny day!

As I said, it was the tank tops on this model that gave it away. They are a separate flat surface, and on initial testing were showing as ridiculously dark compared to the rest of the model. I figured it out by changing camera position. There's a sudden switch in apparent brightness as soon as the camera position changes to the point where direct specular reflection would send rays to the camera.

As far as I can tell at the moment: the game seems to be using some sort of generalised faking of ambient light for overall scenery, and to be assuming that all other lighting is based on diffuse reflection with an assumed (low) gloss level for all surfaces. This is powerful enough to override the ambient lighting when it comes to shading of surfaces, giving the daft results. The running boards on the Pennsy H3 are another example. I won't go into detail here (anyone can check it live for themselves) but basically they exhibit the same effect.

To put it plainly: flat shading is borked. This is frankly a nuisance for skinning, to put it mildly, because a lot of the time you will have flat surfaces. However, at least now I know what is going on and will be able to compensate to some degree. The obvious workaround is to make flat surfaces relatively lighter than other surfaces, where this is possible without borking something else. Where it is not possible without borking something else then, once again, it will have to be accepted that RT3 has bugz. Many, many bugz. Creepy crawlies everywhere.

Curved surfaces are not as bad, because they will usually be reflecting some light to the camera from some point on their surface, but OTOH what the game says they will be reflecting to the camera will not be anywhere near realistic a lot of the time.

[Gumboots]

I've been working on E era pax cars, but for a quick break I had a play around with an idea for the earlier eras of Weapons. I'f I'm going to do missiles for the F and G eras, I figure might as well do something fun for the earlier eras too. A Jagdpanther feels good for the E era.

This isn't a tank, but a tank hunter. Something a bit different, and lower poly than a tank. Complete with flatcar I can keep it under 400 tris, as long as I don't go bonkers with detailing.

I'm thinking I'll do the Renualt FT for the D era, as that was the first modern tank and was widely used between WW1 and WW2. The Jagdpanther would make mincemeat of an FT though, so seems like a good successor.

[Akarin]

I've been working on E era pax cars, but for a quick break I had a play around with an idea for the earlier eras of Weapons. I'f I'm going to do missiles for the F and G eras, I figure might as well do something fun for the earlier eras too. A Jagdpanther feels good for the E era.

Jagdpanther_roughed_out.jpg

This isn't a tank, but a tank hunter. Something a bit different, and lower poly than a tank. Complete with flatcar I can keep it under 400 tris, as long as I don't go bonkers with detailing.

I'm thinking I'll do the Renualt FT for the D era, as that was the first modern tank and was widely used between WW1 and WW2. The Jagdpanther would make mincemeat of an FT though, so seems like a good successor.

I like the idea of the Renualt FT for the D era. But I'm definitely thinking an M47 Patton would be a better fit for the E era. The Patton is usually the generic tank that first comes to mind when someone thinks of a tank. Not to mention it served in WWII in both the US and German armies .

[Gumboots]

No problem. You can make it yourself and be happy.

I like the Jagdpanther for the E era. It's not just a tank. It's something different. It was in service in France until the 1960's, which fits with the E era on the new scale, and it's representative on a type of weapon which is peculiarly of the era. The casemate-style tank destroyer was developed during WW2, but not built much afterwards, and these days is pretty much regarded as obsolete. The Stridsvagn 103 is probably the last of that general style, albeit an MBT rather than a tank hunter.

Anyway, the M47 wasn't produced until the mid-1950's, which seems a bit late.

[bombardiere]

May I ask from where you got the texture for Jadgpanther?

Renault is a very good choice as almost all armies which used early tanks had that or locally built copies. US, USSR, Italy, France of course and even us Finns had Renaults.

StuG III would perhaps been more "anonymous" rather than this last effort of a fallen nazi army. I still see Shermans on well wagons in my eyes, but that is for later time.

[Gumboots]

I found the texture online. Can't remember where. I won't use it for the finished thing, since that would be nicking someone else's art, and also since it doesn't cover the thing properly from all angles anyway as it was never made as a skin. I'll whip something up, without Nazi insignia. The current texture is just to get a feel for it.

I thought about a StuG III, but I like the Jagdpanther better. Also thought about Shermans (an obvious choice) but same answer. The Yanks have their Nikes for the F era.

[Akarin]

Anyway, the M47 wasn't produced until the mid-1950's, which seems a bit late.

I take it you've never seen Patton or Battle of the Bulge.

[Gumboots]

I take it you forgot that movies are sometimes a bit loose with details.

https://en.wikipedia.org/wiki/M47_Patton

Produced 1951–1953

In service 1952–early 1960s (USA)

The M46 Patton was first produced in 1949.

The M26 Pershing might be what you're thinking of, but even that arrived too late for the Battle of the Bulge. I think the heaviest US tank there was the Sherman.

[Akarin]

I take it you forgot that movies are sometimes a bit loose with details.

https://en.wikipedia.org/wiki/M47_Patton

Produced 1951–1953

In service 1952–early 1960s (USA)

The M46 Patton was first produced in 1949.

The M26 Pershing might be what you're thinking of, but even that arrived too late for the Battle of the Bulge. I think the heaviest US tank there was the Sherman.

I think you missed the joke. The Patton was used as a stand-in for Tigers in the Battle of the Bulge and in Patton, the Patton, along with the Walker Bulldog, was used to represent both American and German tanks. Hence why the Patton "served" on both sides during the war. Though I admit I was wrong, it was actually the M48 Patton that was in the Patton move and the M47 in the Battle of the Bulge. I always forget they're two different tanks.

[Gumboots]

Ah, yes I did miss it. I think I may have seen BotB once but it was a long time ago.

[Gumboots]

Ok, have re-thought things a bit. I'm trying to get the flatcars done as well as the rest of the express cars, since flatcars are the biggest PITA and the thing I was putting off.

It's mostly coming along ok now. I'm trying to not get obsessive and just do things to a decent (as good as PopTop) standard for now. Going nuts can be done later, when anyone gets the time and energy for it.

Since the Jagdpanther wasn't popular, I've decided to stay with an artillery theme all the way through until missiles rock up. The missiles are now sorted for skinning and LOD's, so game-ready. The artillery shouldn't take that long.

D era (1915-1939) still needs a bit of work, but are modelled on the British BL 6-inch Gun Mk XIX. This unit is about right for the period, as these guns entered service in 1916 and were widely used right through until early WW2.

E era (1940-1964) is pretty much sorted and is modelled on the 155 mm Gun M1 (nicknamed "Long Tom") set up for transport with its M1 carriage. Again, this was a widely used unit with a long service life, introduced in 1940 but saw active use until the 1990's. It also looks kinda beastie, and two of them just fit on a 62 foot flatcar with a reasonable poly count.

This should stop people grumbling about Jagdpanthers.

[Gumboots]

Just figured something out last night. It should have been obvious years ago, but anyway...

I was running a quick test on the new cars and noticed that the window glow at night was much brighter than on the (already-tested) F era pax cars. Turns out that the brightness of night glow is controlled by the shade of grey on the alpha channel.

The counter-intuitive part is that a darker grey makes for a brighter glow, and a lighter grey makes for a duller glow. So, pure black or pure white on the alpha channel mean no night glow at all. A very dark grey (#111111 hex code, or RGB 17 17 17) will give a very bright glow, while a very pale grey (#EEEEEE hex code, or RGB 238 238 238) will give a very dull glow.

Examples shown below. The F era pax car windows have a paler grey on the alpha channel (#CECECE Hex, RGB 206 206 206), so glow less than the windows on the G era troop cars (#9A9A9A hex, RGB 154 154 154).

This is handy, now that I've figured it out, because it obviously means the night glow for any component can be adjusted by tweaking the shade of grey used on the alpha channel. If you want it very bright, say for a headlight lens or similar, use something that is almost but not quite black. If you want it to barely glow at all, use something that is almost but not quite white.

[Gumboots]

Did a bit more testing on this glow thing. Made a reference PSD, with shades of grey going in steps of ten on the RGB scale.

Then I used this to set alpha channel grey for the window strips each side of the troop cars. They start at #F0F0F0 (RGB 240 240 240) and go down to #646464 (RGB 100 100 100). For the small windows, in the doors on each end of the car, I used #0A0A0A (RGB 10 10 10) just to test the darkest shade that wasn't actually black. The results are shown in the next shot. The idea of using low RGB values (dark grey alpha) for things like headlight lenses is obviously going to work well.

For windows it all works much as expected, with amount of glow selectable by varying alpha RGB values, except for the windows on the ends of the cars. They display with full transparency and no glow, so obviously there must be a tolerance at least 10 RGB units off black before the glow kicks in. At the other end of the scale, the dullest window at 240 on the RGB scale is 15 units off pure white, and that has glow. Based on this, I assume the tolerance off pure black or pure white is somewhere between 10 and 15 units, but once you are outside that range it all works on an even scale.

The other thing is that once the glow ramps up enough it drowns out any of the details on the texture. So the window shading on the texture is just visible until the alpha channel gets to RGB 190 or 180, but once RGB values drop below 180 all you can see at night is an even glow.

I'm going to play around with it a bit more, because one of the problems I've always had with skinning is that trying to use variable shading on a window's alpha channel (ie: not just the one shade of grey) has always turned to crap once it's compressed to DDS. You can see the effect in night shot of the E era dining car, back in this post. However, I think if I mess around with shades that are fairly close to each other, and in the pattern I want, it might be possible to get a standard window shading (easy to copy/paste anywhere) that is variable without turning to crap.

[Gumboots]

Hey I did something off the wall again. Bet nobody would ever have expected that.

Anyway, the old PopTop Pennsy Pacific that was always rough as guts. I had a more or less revamped version sitting in Blender, remeshed but still using the PopTop skin. For some reason I opened that file, while looking through some Blender stuff, and decided to get it running.

It's now running. Looks like this:

Which ain't perfect, but is a lot better than the original. At the moment it just needs tweaking for a few minor skinning details. Once those are sorted I'll zip it up and post it. I'm not going to do anything with stats on this. It'll just be a drop-in quick and dirty bugfix thingy. Anyone who wants custom stats can mess with those themselves. I'll probably do some eventually, but not now.

Update: The new file is up. You can get it here: Pacific/Penn 462 not so basic bug fixes.

[Gumboots]

I've been testing a few things lately, so went back to the alpha channel glow test I did back here.

I ran a basic test to see what values of alpha RT3 was capable of dealing with. It turns out that the limiting factor is the nVidia DDS add-on for Photoshop, as far as I can tell. That appears to set a limit of roughly 16 values for alpha channel colours. I say roughly because the results indicate that it's trying to set things to a maximum of 16, but close checking of the result shows some tiny variation with each grey stripe. It can be RGB 102 102 102, or it can be RGB 103 103 103, at east according to the Photoshop colour picker (which may not be perfect itself).

This explains why it's impossible to get windows glowing at night with a smooth gradient across them: any gradient will be converted into a set of shades of grey, where each shade is far enough apart from the next one to make it all look as rough as guts. The obvious conclusion here is that all night glows should be done with one shade of grey within each window (or within any other discrete chunk of pixels). You can have different windows with different amounts of glow, but you can't mix different amounts within one window if you want it to look good. I've attached screenshots of the alpha channel before and after exporting to DDS.

Original_gradient_alpha.jpg (2.16 KiB) Viewed 6907 times

Alpha_after_DDS_export.jpg (3.54 KiB) Viewed 6907 times

The shades in the exported alpha channel are:

Code: Select all

RGB 255 255 255 (hex code #FFFFFF, pure white).
RGB 239 239 239 (hex code #EEEEEE).
RGB 222 222 222 (hex code #DEDEDE).
RGB 206 206 206 (hex code #CDCDCD).
RGB 188 188 188 (hex code #BCBCBC).
RGB 172 172 172 (hex code #ACACAC).
RGB 154 154 154 (hex code #9A9A9A).
RGB 137 137 137 (hex code #898989).
RGB 120 120 120 (hex code #787878).
RGB 102 102 102 (hex code #666666).
RGB 85 85 85 (hex code #555555).
RGB 66 66 66 (hex code #424242).
RGB 47 47 47 (hex code #2F2F2F).
RGB 28 28 28 (hex code #1C1C1C).
RGB 9 9 9 (hex code #090909).
RGB 0 0 0 (pure black).

Edit: Aha! I should RTFM more often. It just occurred to me to run a search on "DXT3 alpha" and see what turned up.
Found this at the top of the search results: https://www.fsdeveloper.com/wiki/index. ... _explained

The key point is this:

DXT3

Because the alpha information is stored in 4 bit, the smallest step in the alpha value that can be stored is 16. This means that very smooth transitions in the alpha channel can not be stored in the DXT3 format.

Which is exactly what my testing showed me yesterday.
So now I know.

---

Ran some more tests, and have got it thoroughly sussed now. It goes like this:

The RT3 devs coded the game to accept 16 levels of alpha. Two of these are obviously pure black (RGB 0 0 0, Hex #000000) and pure white (RGB 255 255 255, Hex #FFFFFF). Theoretically, there are another fourteen levels available for various shades of grey.

The natural division of the scale is 17 units, which might sound odd if you are used to thinking in powers of 2. It took me a while to realise that if leaving out the starting point you have 255 steps, and 255 is 17x15. So if you're coding for 16 levels in total, the natural increment is 17 on the RGB scale, and that fits comfortably with DXT3's minimum allowed step of 16 units.

When working in an image editor it's easier to use hex instead of RGB to set your shades of grey. The natural increments come in at #000000, #111111, #222222, #333333, #444444, #555555, #666666, #777777, #888888, #999999, #AAAAAA, #BBBBBB, #CCCCCC, #DDDDDD, #EEEEEE and finally pure white at #FFFFFF. These are quicker and easier to type than the corresponding RGB values. They're also quicker and easier to type than any other hex values, since you're just hitting the same key six times, so using these hex codes makes sense.

These would, in theory, give you 16 shades of alpha. However, due to the vagaries of nVidia DDS export, using those hex codes in your PSD alpha channel will give a slightly different result after exporting. The upshot of it is that only 14 levels are usable. It's probably possible to find hex codes that would export in a way to open up the last two RT3 glow levels, but frankly I don't think it's worth the bother. The available levels are more than adequate anyway.

The RT3 scale is set so that hex values from 010101 (RGB 1 1 1) to 101010 (RGB 16 16 16 ) have no glow at all. They will display at night as purely transparent, the same as pure black. This is why the end window of the car tested back here had no glow. The value of #0A0A0A is below #111111, so is assigned to the first no-glow increment.



Much the same applies to hex values of #EFEFEF (RGB 239 239 239) or higher. They work like pure white, and have full opacity and no glow.

This is where the nVidia gremlins come in. If you use #111111 alpha in an attempt to get the highest level of glow, it will be exported as #090909. DXT3 alpha shouldn't allow this, since it's a step of only 9 units from pure black instead of the theoretical limit of 16 units, but it seems that limit doesn't apply to steps away from pure black.

Anyway, #090909 is down in the first no-glow increment, so displays as purely transparent. If you use #EEEEEE alpha in an attempt to get the lowest level of glow, that will be exported as #EFEFEF, which is just into the last no-glow increment, so you'll get full opacity and no glow.

If you use any of the other easy hex codes they will be exported with slightly different values, but they'll still use up the remaining twelve alpha slots perfectly. You'll still have those twelve levels of glow to choose from, and don't have to worry about the actual exported values. The last two levels you can't access are so dim it's hardly there at all, and so bright it'll burn your eyeballs out, so they're not really worth having anyway.

Short version, for people who don't care about the theory and just want to use this stuff: Stick to #FFFFFF if you want opaque pixels, and #000000 if you want transparent pixels. Use anything from #222222 to #DDDDDD if you want varying levels of glow, with #222222 being the one you need welding goggles for, and #DDDDDD being the one that needs new batteries in the torch.