Irishrailguy wrote:This whole DDS method is a bit odd to me, I'm told that using DDS as an intermediate format will produce better results, but I don't see any difference between my old .ace texture and the new .DDS one
It depends what internal format you save the DDS with and that's part of the problem here. In my years (decades?) of doing 3D CGI models commercially I've learned a lot about textures, and DDS is about the most obscure, effed-up texture format in existence. You'd expect as much given that Microsoft created it, but this is messed up even by their usually-low standards. So put on your geek-goggles and read on.
DDS supports many different internal formats. The most common one is DXT1. The problem with that format is that it only uses 16 bits per pixel, meaning you're going to get terrible colour compression artifacts on anything that has a gradient in the colour.
To maintain the colour depth of your original texture, you need to save to DDS with the XRGB or ARGB formats, which use 24 or 32 bits per pixel. Those can be RGB, 888, ARGB_8888 or XRGB_8888.
So what does "16bpp" or "32bpp" mean? The easiest way to think of it is to split the number into 3. But 16 doesn't evenly divide by 3 so for a 16bpp image, you've got 5 bits of red, 6 of green and 5 of blue. (5+6+5=16). 5 bits means you have 2^5 possible values for the brightness of each component. So for the red and blue components there are 2^5 shades available, or 32 shades of red. Green has 64 shades available (2^6)
For a 24bpp image, each component can have 8 bits of each of red, green and blue. Meaning 2^8 shades, meaning 256.
For an image with an alpha channel, it adds one extra 8-bit channel for the alpha, making it a 32 bit image. 8 bits red + 8 bits blue + 8 bits green + 8 bits alpha = 32 bits.
More confusing still, most DDS plugins actually use the WRONG naming convention for DXT1, DXT3 and DXT5 formats, claiming they're 4 bits per pixel (implying 1 bit per component). They're not - they have 5 or 6 bits per component, meaning 16 bits per pixel. But conversely, the same plugins use the CORRECT naming convention for ARGB, RGB and XRGB formats - correctly calling them 24 bits per pixel and 32 bits per pixel.
The DXT1 format is further muddied by the inclusion of the "1 bit alpha" possibility. 1 bit means 2^1 shades - ie black or white. But you can't have a 17-bit image. 5-6-5-1 doesn't exist so DXT1 format "robs" a bit from the green channel, meaning you have 5-5-5-1 bits. Or 32 shades of red, 32 shades of green, 32 shades of blue and 2 shades for the alpha channel.
So how does this affect us in Train Simulator? Honestly I' wasn't really sure and that's why I asked the original question. It's not that I'm unfamiliar with DDS - it's that the use of it in the game seems like a really odd choice. It's like RSC threw out a hundred land mines and said "there you go - have fun!". The RSC tools look at the filename and if they see "_nm" on the end of the filename, it tells their texture compiler NOT to compress that particular image, meaning to keep it in 888 format - full colour resolution. Without that, all the game textures seem to get compressed to 565 format by default. I noticed this right on day 1 when I started building the NS trains because the slight colour gradient I was getting in my yellow trains with my dirt map on, was disappearing when in the game.
So if you save a DXT1 image (565) but give it the "_nm" filename, you're not gaining anything because you've already lost all the colour information when you saved the 565 DDS format.
Further confusing the issue for Train Simulator specifically is that some of the commercial tools for writing DDS files work, and some don't.
THIS is where I came unglued and why I posted this topic originally. For example if you use the AMD Compressonator tool to batch-convert textures from a command prompt or batch file, the ones with alpha channels (8888) work perfectly in the game, but those without alpha channels (888) don't.
But if you save the same textures, in the same format, using the Nvidia photoshop plugins, then
both types of texture work in the game. Comparing the DDS files in photoshop shows no difference so I'm guessing something is being set in the DDS header through the AMD tools that RSC's converter doesn't like.
I discovered through empirical testing that if you save ALL the textures in full ARGB (8888) format, and simply make the alpha channel fully white for any texture where you don't really have transparency, then all the tools work all the time and the game ignores the extra alpha channel in the shaders that don't call for it. The downside is that doing this increases the amount of texture memory used in the game unnecessarily.
Compare all that nauseating complication in the previous 5 paragraphs to the .ACE format which was 8888 and just worked, and you have to ask why they bothered to adopt DDS in the first place.
So : the conclusion I came to (about the same time as Derek posted his blog entry) was this: if you use Photoshop, and the Nvidia plugins, save in the two formats Derek shows in his post, and the RSC tools work correctly from that point forwards. Save in any other format and it becomes a ..
This pic is from Derek's blog post showing those two save formats:
This pic shows the issue with 16 bit compression. The left side shows the original texture, the right shows it after it's been into DXT1 format. In commercial systems we call this "tint banding" or "mock banding". This is what happens in Train Simulator if you don't use the "_nm" filename convention, or compress to DXT1 565 format.
