Doom3 -- High and Ultra settings -- compression

[KimB]

In the case of Doom3 the only uncompressed option is with the same detail as the best compressed option, so you can't make the comparison between quality given the same footprint. Uncompressed textures always take more memory here, and therefore always decrease performance. So Doom3 may not be representative for other games.

In my experience, this is the case with the vast majority of games that support texture compression, so I think this is very representative of most games.

 

[KimB]

I think it unfortunate that higher detail on some surfaces was not offered, because I found some surfaces lacking in detail, and I wonder if it was content creation limitations or a specific decision to meet performance goals.

More likely it's because the artwork was generated for these surfaces some time ago, when it was not expected Doom 3 would take as long to ship.

 

[Mark0]

Not a huge gain, but clearly worth the ten lines of code needed if you got a lot of data.

How about trying PNG also, instead of a general purpose compressor like ZIP / RAR? It seems the most efficent & handy way to store a bitmap losslessy.
I found strange, for example, seeing that Doom 3 textures are stored on disk in TGA format; isn't that a waste of disk space (not that it cost much today, but...)?

Thanks,
Bye!

 

[KimB]

Sorry for the OT but is this an actual word?!

Yep, it was even word of the day a while back.

Hrm, I think it's the old spelling of past tense for the word split, generally no longer used.

 

[Scali]

In my experience, this is the case with the vast majority of games that support texture compression, so I think this is very representative of most games.

I have seen games where texture compression could be enabled or disabled manually, and was independent from the texture quality (size) setting. Doom3 doesn't have this option as far as I know.
Doom3 is the least representative game I've seen in years anyway.

 

[KimB]

Huh? Doom 3 does offer compression independent of texture resolution. That's the difference between Ultra and High Quality settings....

 

[Scali]

Huh? Doom 3 does offer compression independent of texture resolution. That's the difference between Ultra and High Quality settings....

No it doesn't. The only way to disable compression is to choose Ultra settings, as far as I know. And the Ultra settings have only one texture resolution. Hence you cannot choose compression independent of resolution.
Independent would be if you had a setting "Compression: on/off" and another setting "Texture resolution: low/medium/high" or something.
See how these settings do not DEPEND on eachother?

 

[KimB]

Well, you can certainly manually change the settings independently in the config file, but I had thought that the texture size settings for High Quality and Ultra were the same.

 

[Richard]

There are cvars to control diffuse, specular and normalmap compression as well as a general cvar that IIRC overrides these three.

 

[Scali]

Ah, well why can't you control these settings in the menu itself then? Why do you have to use a console or some obscure ini file with all kinds of undocumented settings?
Why is Carmack still living in the 60s?

 

[AlNom]

Most Q3 engine games have loads of options in the options menu... perhaps id felt that they should simplify it and set that as an example. "Keep it simple."

or..What should they choose to put into an "advanced, advanced options" without cluttering the screen with 1000 variables while keeping the interest of the end-user (what the end user wants to see)?

 

[DarthFrog]

What should they choose to put into an "advanced, advanced options" without cluttering the screen with 1000 variables while keeping the interest of the end-user (what the end user wants to see)?

An option for controlling AF might be useful and it would be on the same level of 'abstraction' as the antialiasing selector. Serious Sam had a slider for controlling mip map LOD bias and such a thing might be useful as well, especially if there were a way of optionally 'snapping' the bias to the next integer value because of the performance impact. I think the ends of the slider were labelled 'blurrier' and 'sharper' or something like that.

 

[AlNom]

An option for controlling AF might be useful and it would be on the same level of 'abstraction' as the antialiasing selector.

I was actually puzzled why they included an option for AA and not also AF. :? It seemed careless.

 

[Richard]

Ah, well why can't you control these settings in the menu itself then? Why do you have to use a console or some obscure ini file with all kinds of undocumented settings?
Why is Carmack still living in the 60s?

Why did I know you'd complain about this? Anyway, IMHO, the reason why they were kept out of the menu is because most people don't have the faintest idea what is a diffuse, specular or normal map and whether compression is a good thing. The same reason why AF is automatically applied at High and Ultra quality setttings, and why by default you now need a 3 key combination to access the console: (novice) user friendliness.

Those of us that like to tweak our games to the hilt can take 10 mins to print "listcvar" and have fun toggling each and every one of them. This way, JC is offering options while at the same time not sacrificing the ease of use for the majority of people that will be playing the game and don't want to spend half an hour reading up on how best to configure the options panel.

 

[Richard]

An option for controlling AF might be useful and it would be on the same level of 'abstraction' as the antialiasing selector.

I was actually puzzled why they included an option for AA and not also AF. :? It seemed careless.

I had the same impression but it's now clear 8xAF (if enabled ingame) has very little performance impact, while AA has a lot more (when compared to other games) that they felt whoever has the card to run in High Quality wouldn't care about 3fps of enabling the (selective) (8xAF) while AA is a significant drop that really requires some thought into whether to enabled it or not. Anyway, I agree with Darthfrog that AF is at a similar abstraction level to AA that they could have included it in the Advanced settings (allowing some of us to go all the way to 16x even).

 

[Genghis Presley]

I wrote quick test app that simply splitted the colors and indices. So all color data first in the file, and the index data in the end of the file. Results:

512x512 DXT1

Normal file: 131,200 bytes
Rar compressed: 95,878 bytes (73%)
Zip compressed: 102,250 bytes (78%)

Splitted file: 131,200 bytes
Rar compressed: 89,737 bytes (68%)
Zip compressed: 92,512 bytes (71%)

Not a huge gain, but clearly worth the ten lines of code needed if you got a lot of data.

I hacked together a Compressonator plugin to get some preliminary results on a selection of DXT1 test images:

DDS Files: 100%
Compressed: 56.25%
Splitted then Compressed: 52.68%
Splitted, endpoints delta'd then Compressed 53.00%

For the compression I used zlib. I was surprised that delta'ing the endpoints was a step backward; further analysis on this is required. Delta'ing the indices was even worse.

GP.

 

[Scali]

For the compression I used zlib. I was surprised that delta'ing the endpoints was a step backward; further analysis on this is required. Delta'ing the indices was even worse.

The endpoints are supposed to be the 'extreme' colours in the 4x4 block.
That probably has to do with it.
Did you delta between the two endpoints for each block, or did you store the delta for each block from its predecessor?
I think the second method may work better than the first one.

 

[Genghis Presley]

For the compression I used zlib. I was surprised that delta'ing the endpoints was a step backward; further analysis on this is required. Delta'ing the indices was even worse.

The endpoints are supposed to be the 'extreme' colours in the 4x4 block.
That probably has to do with it.
Did you delta between the two endpoints for each block, or did you store the delta for each block from its predecessor?
I think the second method may work better than the first one.

I'm currently storing the delta between the endpoints for successive blocks - I should really be delta'ing between each endpoint on successive blocks.

GP.

 

[Dio]

If going this far I'd suggest a few other things to try:
- tile the endpoint data a bit for better locality of reference. Even 2x2 blocks would probably help.
- store all the R's then all the G's then all the B's, as they probably correlate better than with each other.
- possibly store the first and second endpoints separately too.

 

[Humus]

splitted

Sorry for the OT but is this an actual word?!

I say Bah! to irregular inflections. I feeled it was goodest that I writed my post that way.