DDS Texture discussion

[New Horizon]

Are they not expanded into the same thing once in virtual memory, thus making realtime handling of them the same? Anyone know for sure?

 

DDS is not expanded, it's a format that is recognized by the video card and handled natively. Which is another very good reason to use them. As I mentioned above RLE compressed TGA's are not recognized, and are expanded at load time.

[SneaksieDave]

DDS textures aren't decompressed though, they're supported by the video card and are read 'as is'.

No shit? Well that would make all the difference then, awesome.

[New Horizon]

No shit? Well that would make all the difference then, awesome.

 

Yup! That's why I've been very keen on using them...sure, you lose a bit of quality...and there are a few cards that won't like them, but overall you're winning on both ends. Then there are the mip maps. With a 1024 x 1024 TGA, that texture is going to be the same size...from any distance, with DDS...depending on how far away you are from it...it will scale from 1024 x 1024 all the way down to 1 x 1, since dds files store all the varying sizes in the file. So, that 1.3 megs of a dds file is not really the 1024 image...it's all the smaller versions of it too. DDS gives you BANG for your BUCK.

[Domarius]

So we may see no game performance change at all, and I wouldn't be suprised if loading slowed down. Remember how much longer it took to load a TDS map with everything packed as opposed to after extracting everything?

All I remember is, on my system, level load times were affected greatly -

 

Loading time for a map in vanilla TDS ~8 seconds.

Loading time for a map with all of John P's high-res textures installed - ~40 seconds.

 

No offence to John, but I ditched the textures in favour of the loading time...

[OrbWeaver]

No shit? Well that would make all the difference then, awesome.

 

Indeed -- further more, the TGA textures have to be compressed to DDS and mipmaps generated at load time (if you have these options enabled), which mean loading a TGA can be considerably slower than loading the equivalent DDS. That is why Doom 3 has the precompressed DDS folder in the first place.

[SneaksieDave]

So where are we on this? This seems to have dried up. Anyone test the textures in this discussion and find they do still have a problem? So far it seemed to work with my GF6 series, but as we know, the GF4 series didn't. Is this too big a move to risk, or is there a change coming?

[New Horizon]

So where are we on this? This seems to have dried up. Anyone test the textures in this discussion and find they do still have a problem? So far it seemed to work with my GF6 series, but as we know, the GF4 series didn't. Is this too big a move to risk, or is there a change coming?

 

I think I'll be taking over textures for now. I'm going to start doing some serious tests on this. I'm looking into all the appropriate doomconfig settings that could cause issues as well. When using dds, we should also have image_ignorehighquality set to 1. This ensures that only dds textures are used.

 

I'll update this thread with results shortly.

[SneaksieDave]

Any updates on this?

 

Also, has it been determined definitively whether DarkRadiant can/can't use DDS, or simply chooses to use available TGAs first? I just discovered that the brick_005 texture was yet again using the (wrong) inverted normalmap again by default, because while DoomEd showed the inverted version, DarkRadiant showed the true version. Reason? DR ignored the DDS.

[New Horizon]

Any updates on this?

 

Also, has it been determined definitively whether DarkRadiant can/can't use DDS, or simply chooses to use available TGAs first? I just discovered that the brick_005 texture was yet again using the (wrong) inverted normalmap again by default, because while DoomEd showed the inverted version, DarkRadiant showed the true version. Reason? DR ignored the DDS.

 

I'm going to run tests with DR and Dark Mod before I make any moves. If all checks out, I'll replace the textures with DDS folder by folder. I'll have to finish up some ads for work and then reformat before I start on it. Give me another week.

[SneaksieDave]

Okay, then either I'll wait on any further submissions (if I have any by that time), or I'll just put them up assuming no change, and when the change comes... it'll all change.

 

Just wondered if maybe Orb or greebo had an idea of the support or lack thereof to save us the trouble.

[greebo]

DarkRadiant can load DDS (but not the RxGB ones, they seem to be proprietary), and mimics the same behaviour as Doom3 does: dds/-Folders are searched first, "real" folders have priority over PK4-folders, texture extensions (.tga/.dds) in the material file are ignored.

[SneaksieDave]

Hm. We had/have RxGB then I guess? I remember this mentioned, but don't know if that was planned, some, or all. Either DR was doing the search in the opposite direction, or it couldn't read the file at all, so it went to the TGA. Something to consider in the possible switch. I didn't know this was happening for as long as this, because my old vid card couldn't use DDS anyway, so even DoomEd ignored the inverted normalmap (while everyone else had the inverted one presented as the correct one).

[OrbWeaver]

It used to be that DarkRadiant would only look for the TGA and display a blank image if it was not found, I then fixed it so it would fall back to DDS in this case. I am not entirely sure that it will load the DDS before the TGA however, I think this will depend on which image loader module it encounters first.

 

RXGB is not supported currently, although I am not sure what happens when it finds the DDS but cannot load it.

[greebo]

Now that DarkRadiant can read RxGB textures, may I suggest that we move on and compress the repository using the DDS format?

 

The question remains what should happen with the "source" TGAs, should we move them into a separate repository? The hi-res repository is for PSD files and TGAs that are larger than 1024x1024 only, right?

[New Horizon]

The question remains what should happen with the "source" TGAs, should we move them into a separate repository? The hi-res repository is for PSD files and TGAs that are larger than 1024x1024 only, right?

 

Yes and no. That used to be the case when we were using TGA only, but now that we're going to switch to DDS...the physical dimensions are not a concern.

 

Hi-res repository is for all TGA's regardless of size. DDS textures can and should be the same physical dimensions as the TGA. We don't want to be downsizing a texture to 512 or 256 and then compressing it with dds as it will look horrid.

 

Mainly the hi-res repository is for all uncompressed files, the main mod is for compressed.

 

I'll update the texture guidelines to further clarify.

[greebo]

No hurry, we won't start with that until we've merged back the texture reorg branch into the trunk, so we still have a bit of time left. But the sooner we know what we want to do the better.

[Springheel]

After the texture reorg is done, I think we should do the following:

 

1. Cull uneeded textures (bad textures, duplicated normalmaps, flat speculars, etc)

 

2. Convert to .dds (btw, I read something about 'high' graphics setting using dds for everything but the normalmap, which is still .tga...does that mean we'd be restricted to 'medium' settings??)

 

3. Start adding textures to the mostly-empty folders (metal, carpet, etc).

[angua]

I could see a normal map ingame where only the dds version and no tga version was present. I have the following settings:

 

seta image_usePrecompressedTextures "1"

seta image_useNormalCompression "2"

seta image_useAllFormats "1"

seta image_useCompression "1"

[New Horizon]

After the texture reorg is done, I think we should do the following:

 

1. Cull uneeded textures (bad textures, duplicated normalmaps, flat speculars, etc)

 

2. Convert to .dds (btw, I read something about 'high' graphics setting using dds for everything but the normalmap, which is still .tga...does that mean we'd be restricted to 'medium' settings??)

 

3. Start adding textures to the mostly-empty folders (metal, carpet, etc).

 

With iD's special compression, used for normal maps, we'll be using normals for everything. I believe that we can actually change the default settings for low, medium, high and ultra, so that high would still use DDS. It's just a matter of the config settings.

[Dram]

With iD's special compression, used for normal maps, we'll be using normals for everything. I believe that we can actually change the default settings for low, medium, high and ultra, so that high would still use DDS. It's just a matter of the config settings.

 

We can just make our own settings. The low, medium, high, ultra settings only set a few cvars, so this would not be sifficult. For one thing, we want to be able to specify how much video ram we have, as apparently D3 detects this incorrectly, especially for the newer cards, which means you'd be using the HDD pagefile, which is much slower. There are other settings, I wrote a lot of them in the "tweaking tdm" thread a while ago.

[greebo]

I will start looking into the DDS texture conversion this evening (i.e. now), if no one objects.

[greebo]

Ok, I need someone to confirm or deny this for me, before I go insane:

 

I converted this diffusemap textures/darkmod/door/metal/large_warehouse_old_green01 into the DDS format and moved it into the corresponding dds/ folder, and removed the TGA. Works fine (I had to create a shader, as it was missing, but this is irrelevant here).

 

Now if I move that DDS texture file one folder deeper, let's say to textures/darkmod/door/metal/bars/large_warehouse_old_green01, Doom 3 won't load it anymore (says "Couldn't load image: blah").

 

This does not happen if I move a TGA file one folder deeper.

 

I can't believe (yet) that the Doom 3 dds lookup has such a major folder depth bug, so please can somebody run a similar test with this texture?

 

(In case you wonder why I checked this: I ran into problems while converting the darkmod/wood/ornate/ stuff into DDS, and Doom3 won't load any of them from the dds/ tree).

[greebo]

Um, did anybody read this?

[SneaksieDave]

Have any better luck with this yet? I'll try to check this out tonight; I'm running out in a few mins and am on my work machine at the moment.

 

Edit: nm, I see your post

[greebo]

I checked in the meantime if the string-length is the limiting factor, but it is not (I renamed the dds texture to l.dds), but it can't be found as soon as it is >= 5 levels deep in the dds/ structure.

 

The DDS itself is perfectly valid, because it works in the parent folder. I double-checked the shader definitions if I did get anything wrong, but no luck yet.

 

I also searched the SDK code for anything related to this, but the declaration manager is not included in the SDK.