[Buttercup]

A shot in the dark here, but is the following helpful?

Here is some additional information on the transparency of shapes that deals (from: http://dickyjim.com/letmein2c.html) with looking through transparencies on shape files. Site is no longer available but can still be found on WayBackMachine.



SAFE SHAPES AND ADVANCED SHAPES

What is the difference?
With the advanced shapes you can see objects through the cab windows from one side of the loco to the other. Unfortunately this causes some systems to crash MSTS hence the “Safe” shapes.
The difference between the two files is just two numbers which can easily be edited with WordPad.

Safe Shape:-

sub_object_header ( 00000400 -1 -1 000001d2 000001c4

Advanced Shape:-

sub_object_header ( 00000500 -1 0 000001d2 000001c4

[Genma Saotome]

I used ConvImx to convert all of my opaque .bmp source files into .dds/DXT1. I noticed that the vast majority of equivalent .ace files (also w/ DXT1) were smaller... many were originally .tga, some .bmp. I've not yet processed any w/ alpha layers.

Because DXT1 works the same on both .ace and .dds (it's lossy) there is no difference between the two as far as resulting color is concerned.

AFAIK where .dds should do better is with 8-bit alpha textures because you can use a compression type that is less lossy than what we could do w/ .ace files (especially the 8-bit transparency textures). I dunno anything about problems w/ the transparencies that were mentioned above.

.dds also has a provision for using bump maps (not yet implemented in OR). Bump map data rides along with the image, just like mipmap data goes along, and if the displaying software knows what to do with it the result should be a more interesting appearance. The classic example I've seen is a flat orange texture with a bump map that was applied to a sphere... the resulting display of fruit includes the tiny dimples you see in an orange rind.

I had thought .dds would help Open Rails performance as I had been led to believe it moves to the .gpu w/o the extra processing that .ace files require but I've not seen any measurable difference in speed, only that the larger .dds files used up more VRAM.

[scottb613]

Hi James,

A picture is worth a thousand words - so - just so we're all on the same page - this is the issue I'm referring to...





Regards,
Scott

[gpz]

 Genma Saotome, on 02 March 2014 - 05:42 PM, said:

I used ConvImx to convert all of my opaque .bmp source files into .dds/DXT1. I noticed that the vast majority of equivalent .ace files (also w/ DXT1) were smaller...

I had thought .dds would help Open Rails performance as I had been led to believe it moves to the .gpu w/o the extra processing that .ace files require but I've not seen any measurable difference in speed, only that the larger .dds files used up more VRAM.

ACE files are further compressed by zip internally, that's why they are smaller. Before loading them into VRAM they are uncompressed, and become the same size as DDS DXT1 equivalents. So they will not use less VRAM, but will need some extra pre-processing CPU time, which could lead to stuttering if many of them has to be loaded at the same time.

The same is true for mipmaps: If you don't store mipmaps with ACE-s, then they will consume less disk space, but will need the CPU to generate mipmaps for them at loading time, which can also lead to stuttering. (Mipmaps aren't generated for DDS textures, so if one doesn't store them in file, they will be completely missing currently.)

[gpz]

 Shay 5, on 02 March 2014 - 02:23 PM, said:

The texture names in the S. file probably still have the ACE. file extension, which will fail to recognize files with the DDS. extension.

When you switch on the experimental DDS option, OpenRails will try to find Boiler-1.dds and Boiler-2.dds, and use them in preference of ACE-s.

[gpz]

 Buttercup, on 02 March 2014 - 04:25 PM, said:

SAFE SHAPES AND ADVANCED SHAPES
What is the difference?
With the advanced shapes you can see objects through the cab windows from one side of the loco to the other. Unfortunately this causes some systems to crash MSTS hence the “Safe” shapes.
The difference between the two files is just two numbers which can easily be edited with WordPad.

I don't think OpenRails uses this data for anything. Alpha sorting and representing is done always the same way.

[Shay 5]

So ORTS does the sorting. That's nice to know.

[Buttercup]

 scottb613, on 02 March 2014 - 06:16 PM, said:

Hi James,

A picture is worth a thousand words - so - just so we're all on the same page - this is the issue I'm referring to...


Alpha.jpg


Regards,
Scott

Another shot in the dark.

Maple Leaf Tracks developed a special ace file for signal lights to allow them to be seen at greater distances. One of the side effects was to produce the effect shown when you viewed the signal close up in MSTS. SigView™: www.mapleleaftracks.com/free.html

[Genma Saotome]

 gpz, on 03 March 2014 - 12:14 AM, said:

ACE files are further compressed by zip internally, that's why they are smaller. Before loading them into VRAM they are uncompressed, and become the same size as DDS DXT1 equivalents. So they will not use less VRAM, but will need some extra pre-processing CPU time, which could lead to stuttering if many of them has to be loaded at the same time.

Well that's interesting. How then should I understand the data in a before and after pair of screenshots that shows memory in use 35-40mb higher after dropping ~90 .dds files into \textures, all other things being equal? Might it be the place where the memory use was measured is before .ace de-compression... or is something else going on?