[dforrest]

scottb613, on 28 February 2014 - 04:20 AM, said:

Hi Jeff,

One of the other advantages of using DDS is that we can leverage tools built by the much larger MSFS community... Attached is a program we commonly use on the other side of the fence... It's a little stand alone program called "ConvImX"... No install necessary - just run the executable... It converts between all "sim" file formats I'm aware of - BMP - TGA - DXT1 - DXT3 - DXT5 - and - DDS... It can create mipmaps and process entire directory structures in a few clicks... Works great - used it for years..

See Attached: ConVimX

convimx.zip

Regards,
Scott

I must be missing simething but I cannot see how to "process entire directory structures in a few clicks" using "ConVimX".

--------------
David

[markus_GE]

Knowing of ConvImX, all we´d need to do bulk conversions of all folders in the TrainSimulator folder would be a similar utility, that could make bulk conversions from ACE to some other format readable for ConVimX...

Nevertheless, this already is great news! :wub:

Cheers, Markus

[A Tejesember]

markus_GE, on 28 February 2014 - 08:04 AM, said:

Knowing of ConvImX, all we´d need to do bulk conversions of all folders in the TrainSimulator folder would be a similar utility, that could make bulk conversions from ACE to some other format readable for ConVimX...

RouteRiter can convert folders of ACE to TGA. I don't know ConvImX, so I used RouteRiter's feature to make a list of the different types of ACE (no alpha, 1bit, 8bit), wrote a script to sort the files into different folders accordingly, then convert them into DDS with NVIDIA's Texture Tools. Works, but still messy a bit. :sign_thanks:

[Genma Saotome]

WRT ConvImx, I've got all my own artwork in either .bmp or .tga format and being able to do a mass conversion into .dds would be a real timesaver for me.

One thing I've noticed tho is many of my .ace files, in DXT1 compression, are actually smaller than the same image in .dds with DXT1. IIRC a 512x512 .dds +DXT1 checks in at ~175k bytes and a quick check of my \textures directory turns up lots and lots smaller .ace files that I know are 512x512.

So is .dds really a panacea for anything wrong with ordinary opaque .ace files? They're both DXT1 so both are lossy....

[gpz]

Do both have mipmaps? (They should have, unless the image is a 2D cabview image.) That can make some difference. Additionally, ACE files can be in zipped form internally, while DDS-s can't. Though I'm not sure if this is also true for DXT1 ACE-s...

I think one shouldn't convert DXT1 ACE-s to DDS-s, because there is no benefit from doing this. Also, if he does it the way that uncompressing the DXT1 texture to a full uncompressed image first, then recompressing it again to a DXT1 DDS, then the image will loose quality.

[scottb613]

Hi Folks,

I tried the DDS option last night and it didn't seem to work for me... I copied a DDS texture to one of my rail cars folders - same name as the ACE... I enabled the "DDS" option on the experimental tab... When I checked in OR - the cars were untextured... I didn't spend a great deal of time on this but am I missing something obvious ???

One question - will DDS textures with Alpha - stop blanking out stuff like smoke and forest regions that appear behind them ??? If so - this would fix the painful problem with the semaphore textures used on many routes...

Regards,
Scott

[gpz]

scottb613, on 01 March 2014 - 07:44 AM, said:

One question - will DDS textures with Alpha - stop blanking out stuff like smoke and forest regions that appear behind them ??? If so - this would fix the painful problem with the semaphore textures used on many routes...

DDS textures work the same way as ACE-s. Is there such a problem? I have never heard about this...

[scottb613]

Hi Peter,

The problem has been with MSTS since it's inception... I'm no expert but I think we previously used DXT1 as compression on ACE's and that by it's very nature DXT1 doesn't do a good job of displaying items that appear behind it through a transparent alpha channel... It will display some but not all... In MSTS/OR - for whatever reason - it affected forest regions and the smoke textures... The most noticeable place this problem typically occurs is on the signaling textures - either lights or semaphores... When you view through this texture it blanks out any smoke that appears behind it... I know from my experience with MSFS - DXT3 behaves a title differently - with a different set of issues... Now with DDS - we can use DXT5 compression - at least that's how I got the DDS to work in OR last night... I was just wondering g if that changes the visibility issues at all for us with regards to seeing smoke and forest regions through an alpha'd texture...

Regards,
Scott

[James Ross]

scottb613, on 02 March 2014 - 10:48 AM, said:

The problem has been with MSTS since it's inception... I'm no expert but I think we previously used DXT1 as compression on ACE's and that by it's very nature DXT1 doesn't do a good job of displaying items that appear behind it through a transparent alpha channel...

I do not believe there is any link between the format and this issue you seem to have. The format controls the quality of the alpha channel but has nothing to do with what you can or can't see through it.

[Shay 5]

I have a hunch it's in the S. file. The texture names in the S. file probably still have the ACE. file extension, which will fail to recognize files with the DDS. extension. Here's a excerpt from my Boiler shape file which I uncompressed and viewed in ConText. Notice the extensions are Ace.