[Genma Saotome]

So if I understand correctly, the advantage of .dds files is it lets you skip the step of making an .ace file but it might come at a cost of greater use of disk space and vram. Is that correct? Anything else (e.g., visually sharper)?

Is there anything in OR that uses the sophisticated features of .dds, stuff like bump maps?

[Weter]

If I don't check "use *.dds prior to *.ace" at Options, some textures at Scenic Route won't be loaded-i.e. Will be substituted by solid gray texture.

[scottb613]

Genma Saotome, on 30 November 2021 - 01:45 PM, said:

So if I understand correctly, the advantage of .dds files is it lets you skip the step of making an .ace file but it might come at a cost of greater use of disk space and vram. Is that correct? Anything else (e.g., visually sharper)?

Is there anything in OR that uses the sophisticated features of .dds, stuff like bump maps?

Hi Dave,

DDS lets you create your files directly in your paint program.
DDS opens the door to more tools than proprietary ACE files.
NVidia made their video cards to handle DDS files - so I think there may be some efficiencies gained over ACE.

I don't have all the sizes in front of me but I just converted an entire route to 2048 DDS Terrtex patches - we're talking thousands.

Previously - I typically used 1024 24bit Terrtex ACE patches and I never took the time to compress them so they came in at just over 4MB with MipMaps.

Now - with the 2048 Terrex DDS compressed with DXT1 - I'm at 2.66MB with MipMaps.

So - while I realize there is some loss with compression - doubling the texture size is giving me better performance while using less resources and looking better.

I believe the uncompressed 2048 24bit DDS with MipMaps is 12MB.

I am using MORE disk space - because I keep the uncompressed ACE files for TSRE so I can edit at will - - - while ORTS runs with the compressed DDS files giving me great performance.

Sadly - no Bump Maps or PBR textures - limit of ORTS - using both in P3D and what a complete game changer. They completely change a model.

Regards,
Scott

[steved]

Scott,

What did you end up having to do to get the .ddss to show up?

[scottb613]

steved, on 30 November 2021 - 05:25 PM, said:

Scott,

What did you end up having to do to get the .ddss to show up?

Hi Randy,

What I found is that if I take a DDS and apply it to a tile - it will display the DDS and the DDS name is written to the tile.

If I then paint that tile and save that modified output it reverts to ACE - writes the ACE to the tile - and on subsequent visits it will display the ACE.

If you select a tile - TSRE will tell you the assigned texture in the left hand panel.

So I'm leaving every tile assigned an ACE - just like always - for TSRE for editing - then using the NVidia command line DDS Tool to script the massive amount of ACE to DDS conversions. ORTS then uses the DDS as I have the "Prefer DDS Option" selected.

Regards,
Scott

[steved]

That's weird because if I edit a .dds terrtex in TSRE it saves as a .dds.
You were having problems with TSRE not showing .dds textures. Still?

[scottb613]

Hi Randy,

Hah - you got some witchy voodoo stuff going on there buddy - I've never seen TSRE create a DDS. I've exhausted all my attempts.
:thumbup3:

Yep - if a place a full DDS texture and don't edit it in TSRE - TSRE will display the DDS.

Regards,
Scott

[steved]

Yeah, I tried it again and got the same result,

 dds.JPG (40.82K)
Number of downloads: 2

That .dds is from a TSRE save.
If there are benefits to converting them all to .dds I may do it but right now TSRE and ORMG handle the mix just fine.

Randy

[Genma Saotome]

BTW, if you do not like the obscure names TSRE gives to tiles it has edited you can use James Ross' SIMIS editor to edit the names in the .t file to something more meaningful. Everything is in clear text and the .ace file (and/or or .dds) listing starts about 10 lines from the top. All you need to do is note the original and new name so you can rename the actual tertex file too.

[ErickC]

I will attempt to clarify some points about ACE, BMP and DDS.

None of these are really image formats insofar as the image data are actually concerned. They are container formats. The image data might be 32-bit, DXT1, DXT3, DXT5, et cetera. Which container format is used depends on what the game can read, but a DXT3 extended bitmap in MSFS is really not that different than a DXT3 DDS file in MSFS (aside from the origin). ACE could probably handle lots of image formats, but the tools limit export to what MSTS used, as anything else was simply impractical. Open Rails, however, isn't bound by the limitations of the tools used to export in ACE format because it can also read DDS format. DDS is a "standard" format just like BMP, meaning a variety of off-the-shelf paint programs can export in the DDS container format. This has the side benefit of being able to export images in pretty much any format you like.

This is, in fact, the primary advantage of DDS format. Some developers will claim performance benefits, but the only performance benefit to DDS format is purely hypothetical, and it comes from the fact that DDS can have the origin set to the top left, which means you could hypothetically get a small performance benefit on loading large numbers of textures as the GPU doesn't have to flip the image like it would with a bottom left origin (UVW mapping has a top left origin). But nobody's actually demonstrated a tangible difference in an actual game to my knowledge. I think this is a "loud pipes save lives" thing - the people saying it know it's not the reason they have loud pipes (they just like the noise), but it provides a convenient and plausible argument that obfuscates the actual motivations because very few people like to admit the real reasons that they like doing things. The reasons developers really use DDS are:

1. You can export the image data in any format you like directly from your image editor without using clunky conversion tools - time is money
2. You can make payware content without paying licensing fees to use community-based image export tools

The latter is of utmost importance because the image tools that come with MSTS cannot export high-definition textures in every format, meaning large textures require the use of AceIt or TGATool. So it's probably best to not think in terms of ACE or DDS, but rather in terms of what the data actually is and what tools can export in what format. With that background, now we can talk about image data. MSTS created this horrific misunderstanding of image data for a couple of reasons:

1. It used goofy names that obfuscate the actual data being written (and the tools used to export textures are guilty of perpetuating this confusion)
2. It used a variety of bit depths but only ever displayed textures with alpha data in 16-bit (which is why textures in MSTS always look like garbage)

So most developers in the MSTS, and by extension, OR world think of images in these formats: NO ALPHA, ALPHA, TRANS, DXT1. The last one is the only honest name in the bunch. The bit depth in the colour data isn't even the same across the first three! "NO ALPHA" is a plain 24-bit bitmap. "ALPHA" is a 32-bit image. But "TRANS" is a 16-bit 5551 image. MSTS rendered the colour data for all of these images differently, with plain 24-bit images rendered correctly and 32-bit images reduced to 16-bit in the colour data (but retaining the bit depth of the alpha data). Open Rails, however, reads the data as it is written. And with the DDS container format, we gain the ability to use any uncompressed format, and any DXT format. So I can now cover the pros and cons of the formats we commonly use in OR:

24-bit: This is the standard image format we all know and love. 8 bits of colour data per channel, millions of colours.

Pros: Good bit depth.
Cons: No alpha data. Large file size.

32-bit: This is 24 bits of colour data and 8 bits of greyscale alpha data.

Pros: Good bit depth, gradient alpha allows for partial transparency and anti-aliased alpha cutouts.
Cons: Huge file size!

16-bit 5551: 5 bits of colour data for each channel, 1 bit of alpha data (black and white).

Pros: Reasonable bit depth. Reasonable file size.
Cons: Limited colour data means textures need to be dithered or there will be noticeable banding. 1-bit alpha is only really good for perfectly square cutouts as it will look jagged otherwise.

DXT1: I don't remember the texhnical details, but each 4 x 4 pixel area is reduced to a limited colour palette (4 colours for 16 pixels). 1-bit alpha channel is available but not required.

Pros: Offers a much better apparent bit depth than 16-bit, greatly reduced file size compared to 24-bit.
Cons: Each 4 x 4 pixel area is reduced to 4 colours, so artifacts may occur. 1-bit alpha is still poorly-suited to most applications.

DXT3: Like DXT1, but allows for a limited amount of alpha gradient with a 4-bit alpha channel.

Pros: Better apparent bit depth than 16-bit, gradient alpha is better suited to most applications than 1-bit.
Cons: Larger file size than DXT1. 4-bits of alpha data is still limiting when dealing with subtle or complex gradients in the alpha channel.

DXT5: Colour data is the same as DXT1 and DXT3, however, the alpha data now uses a similar compression algorithm to the colour data, allowing for a greater apparent alpha channel bit depth.

Pros: Much better alpha gradient than DXT3, much smaller file size than 32-bit.
Cons: Larger file size than DXT1 or DXT3, will have artifacts when compared to a "pure" 32-bit image.

The main takeaway is this: what format you choose depends on the image data! If your image has two or three colours in it and no alpha data, there's absolutely no reason to be using 32-bit. You would be wasting disk space because you don't need the extra colour depth or the alpha channel. In fact, you should probably be using 16-bit or DXT1 without alpha! If your image has a fine gradient alpha and lots of colours in it, then your best bet is going to be 32-bit if your goal is image quality, or DXT5 if your goal is a compromise between quality and file size. If your image requires lots of colour data, more alpha data than pure black and white, but the alpha gradient is not particularly fine, then DXT3 will do.

Whether you export in ACE or DDS also depends on the application. If you're making payware content, it would be wise to stay away from the ACE format unless you are willing to pay licensing fees to use AceIt and TGATool, or you're using formats that MakeAce can handle. If you want to use DXT3 or DXT5, then you must use DDS because none of the MSTS tools export in those formats.

A similar discussion can be had about audio formats - if your sound file has no data in it above 5,000 Hz, there's no reason to use a sample rate greater than 11,025 Hz. You're literally just wasting disk space.

[Weter]

Erick, Thank you for such analysis!
Things became much clearer for me now.
BTW, in my system, *.ace initially mentioned as an archive file type.
As you said, that's kind of container, is it actually the same archive, used to contain graphic data?

Now I know, why TgaTool applies DXT compression in a strange way to semi-transparent files.

[ErickC]

Weter, on 05 December 2021 - 10:56 AM, said:

BTW, in my system, *.ace initially mentioned as an archive file type.
As you said, that's kind of container, is it actually the same archive, used to contain graphic data?

Not that I know of - that's probably a case of two different formats having the same extension. It's not a type of archive, it's a container format for image data, much like MPEG or AVI are container formats for video data (although compressed archives do fit under the umbrella term of "container format" - see this page).

[SVRy_Steve]

If you are confused by the grid layout of the patches in a tile, this may help, or not!

 tile patch grid chart.jpg (104.76K)
Number of downloads: 2

[Weter]

Two more questions:
- what is ZLib?
- as it was reported, that TSRE accepts *.jpg files as a texture and then saves textures as *ace, are payware converters further needed?

And one more:
Erick, may I translate your lecture and place the result on the other resource?

[ErickC]

Weter, on 05 December 2021 - 01:34 PM, said:

Erick, may I translate your lecture and place the result on the other resource?

Go ahead. :)