DXT issue NOT fixed in GF4 Series ?

Should NVIDIA have fixed this properly ?


  • Total voters
    162
Metabytes FXT1 compressor in WickedGL is faster, looks better, and fixes a variety of problems that are in the 3dfx one.
 
It would be very interesting to see a comparison between GF4's TC, S3's own implementation, FXT1 and VQ. Maybe even a little Beyond3D article? ;)
 
easyride said:
It would be very interesting to see a comparison between GF4's TC, S3's own implementation, FXT1 and VQ. Maybe even a little Beyond3D article? ;)

Uh, GF4's TC is the same as S3's, but nvidia's implementation is poorer. There's no real reason to rehash this again.

Until nvidia decides to improve the decoding in their hardware, GeForce users will have to deal with inferior compressed texture quality.
 
Dave B(TotalVR) said:
Well pardon me for suggesting VQ texture compression should replace S3TC 8)
Dare I say PVR-TC?


Does anyone have the original data for the textures in question?
 
The original data can be easily obtained from Quake3 since the data files are just zipped.

I believe the file in question is inteldimclouds.jpg

- Andy.
 
Thanks, but I was more interested in the Jedi Knight examples.
(I've looked at quake textures (especially the sky textures) before.)
 
Whoa, didn't really read this thread... I'll ask Daniel Vogel as well as do some invstigation myself with a GF4 Ti4600.
 
OpenGL guy said:
Uh, GF4's TC is the same as S3's, but nvidia's implementation is poorer. There's no real reason to rehash this again.

Until nvidia decides to improve the decoding in their hardware, GeForce users will have to deal with inferior compressed texture quality.

I know, I'd just like to see pics of all 4 implementations. Maybe a small app with a single texture. Compress it with S3TC, FXT1 and VQ, and compare output from GF4, Savage4, Voodoo5 and Neon 250.

I guess it's too much work.
 
I think when it comes to texture compression everybody has looked at the Quake3 sky textures in the past... ;)

Anyway - the same principle holds true for Jedi Knight 2 as for Quake3 - all the texture data is easily available in the game's .pk3 files. The only difficult part is identifying which textures we're interested in for comparison purposes.
 
Okay, here's Daniel's reply :
Convert a small grayscale texture to DXT1 and render it magnified. The dithering is quite obvious and the miscoloration blobs are big which is an indication of dithering in texture space (aka before magnification).

-- Daniel, Epic Games Inc.
Someone try this and report.
 
andypski said:
I think when it comes to texture compression everybody has looked at the Quake3 sky textures in the past... ;) .
I certainly know a lot of us have stared at the output :) but what I actually meant (when I wrote "looked") was that I've run various compression algorithms (eg S3TC, VQ (as in Dreamcast), and PVR-TC) on these textures.

Anyway - the same principle holds true for Jedi Knight 2 as for Quake3 - all the texture data is easily available in the game's .pk3 files. The only difficult part is identifying which textures we're interested in for comparison purposes.
OK. I might see if someone here has the data files.
 
I actually meant (when I wrote "looked") was that I've run various compression algorithms on them (eg S3TC, VQ (as in Dreamcast), and PVR-TC).

If PVR-TC isn't VQ what is it Simon?
 
Simon, would multistage VQ be possible for texture decompression or is decompression only allowed to have ~2 cycles of added latency?
 
Sorry, Wavey, my "DNA" prevents me from answering. I assume, however, that you've seen MBX in action, in which case I'm 90% certain you've at least seen the results.
 
MfA said:
Simon, would multistage VQ be possible for texture decompression or is decompression only allowed to have ~2 cycles of added latency?
In theory you could use multiple levels of VQ. After all, Dreamcast could chain VQ and Palettes (i.e. just a simpler form of VQ) together.

The thing is, the latency might not just be a matter of a couple of cycles. If you have to do double indirection fetching stuff from memory it could be 10s of cycles. Working around that is a pain (eg dedicated lookup storage and/or big FIFOs)
 
Well with multistage VQ I mean residual VQ, VQ terminology is wonderfully inconsistent, which tends to have quite small real codebooks ... so loading them should not be any more trouble than with the DC-VQ. Of course they have much larger effective codebook sizes, which you would think would allow them to be more general (ie. shared between textures and/or able to deal with larger vectors).
 
Simon F said:
I certainly know a lot of us have stared at the output :) but what I actually meant (when I wrote "looked") was that I've run various compression algorithms (eg S3TC, VQ (as in Dreamcast), and PVR-TC) on these textures.

I know that's what you meant - I've spent rather a long time looking at this texture, no doubt for similar reasons. I was just being facetious. :LOL:

Anyway, the Q3 sky is not really a very good case for VQ (or indeed DXTC). I'll assume that PVR-TC is more advanced. ;)

From a quick look, many of the JK2 textures should compress well with DXTC. When I have some time I'll see if I can identify some representative bad cases.

- Andy.
 
MfA said:
Well with multistage VQ I mean residual VQ, VQ terminology is wonderfully inconsistent, which tends to have quite small real codebooks ... so loading them should not be any more trouble than with the DC-VQ. Of course they have much larger effective codebook sizes, which you would think would allow them to be more general (ie. shared between textures and/or able to deal with larger vectors).
Sorry Marco, I understand what you meant now. FWIW I tried some experiments averaging 2x2 pixel groups, storing that 'base' colour per block, and then VQ compressing the delta (with fewer code book entries). It certainly helped with "low rate of change gradients", but I seem to remember I still ran out of VQ codes pretty rapidly. I might go back and try it again some time.
 
OT:

Sharkfood or Prime,

how did you get screen shots from Jedi? I did not see any key bound to the screenshots not sure if I had to hit the screen copy, then cut and paste.
 
I saw this topic discussed in another forum, I'm running a Ti-4600 with the 28.32 drivers and I can't seem to get the texture compression errors to manifest themselves.
The sky in Q3A looks the same whether TC is on or off.
Also in Unreal Tournament, I might be mistaken but I seem to recall seeing lots of banding in the skyboxes when I had my GF3 but I don't see any now.
Here's a few screenshots:

http://webpages.charter.net/madman11/TC-Off.jpg
http://webpages.charter.net/madman11/TC-On.jpg
http://webpages.charter.net/madman11/UT-S3TC1.jpg
http://webpages.charter.net/madman11/UT-S3TC2.jpg

LLB
 
Back
Top