New 3Dc demo

[Ruined]

Don't work on the FX5900 either, getting the same white dot zooming around, 53.03 drivers.

Must be some compatibility issues with the demo and Nvidia cards.

 

[gsgrunt]

It works on my 5700 Ultra 61.34

No shadows

 

[DemoCoder]

I thought there was surprising little artifacting on the DXT5 version, and it certainly looked much better than the alternative: a low-res uncompressed version. The difference in Humus's code? Two swizzles in 2 lines of code. So DXT5 should definately be supported.

What tool did you use do compress the DXT5 version Humus? I think the compressor could do a better job supressing or eliminating those few artifacts by dynamically adjusting weighs in each block to favor the dominant axis.

 

[jpaana]

Peculiar results from my 9800Pro/XT, cat 4.7 betas, no shadows:

base off/normal off 188fps
base on/normal off 210fps
base off/normal on 202fps
base on/normal on 204fps

 

[pocketmoon66]

Humus dude - I guess your using the DXT5 trick of copying one of the normal components (RGB) into the alpha channel and setting that channel to zero before compressing ?

i.e. the dxt5 normal map compression trick ?

http://www.imm.dtu.dk/visiondag/VD03/grafisk/WolfgangEngel.pdf

 

[Colourless]

I imagine he is actually using ATI's DXT5 Normal Compression trick where you only use A and G.

 

[pocketmoon66]

I imagine he is actually using ATI's DXT5 Normal Compression trick where you only use A and G.

And derive the third component in the shader ?

Hmm ... Looks like it's using three components from the texture (Alpha Blue Green) ?

 

[Humus]

I thought there was surprising little artifacting on the DXT5 version, and it certainly looked much better than the alternative: a low-res uncompressed version. The difference in Humus's code? Two swizzles in 2 lines of code. So DXT5 should definately be supported.

What tool did you use do compress the DXT5 version Humus? I think the compressor could do a better job supressing or eliminating those few artifacts by dynamically adjusting weighs in each block to favor the dominant axis.

Yes, DXT5 works fairly well in many scenarios. For random generic detail bumps you don't need very good precision, and if the bumpmap is very smooth it's going to work fine with DXT5 too. The visible artifacts is when there's a curvature, which with only four available colors will turn into a straight plane.

The good thing about 3Dc is also that it will fits right into the same shader as uncompressed normal maps, while DXT5 will have to use another shader or use #defines. If shaders are generated automatically in artist tools I guess that's not a problem, but if you have a wide range of hand-written shaders than that's going to be a pain in the ass to add and maintain.

I used the texconv.exe file from the DirectX SDK together with my 3DcGenerator tool.

 

[Humus]

Hmm ... Looks like it's using three components from the texture (Alpha Blue Green) ?

That's only because I assign to a three component vector. I only use blue and alpha, RGBA(0, 0, y, x). I chose that order because it fits well with the .wzyx swizzle, so that it can be put back into RGB(x, y, 0) for free.

 

[LeGreg]

The good thing about 3Dc is also that it will fits right into the same shader as uncompressed normal maps, while DXT5 will have to use another shader or use #defines.

In the case of 3dc, isn't the driver adding additional instructions thus generating an additional shader ?

 

[Humus]

No, 3Dc is just a texture format like any other. The third component is generated in the shader. That's code that I write myself, it's not generated by the driver. Normally you'll have to normalize your vector in the shader anyway, so using 3Dc is neither a gain or loss in terms of the number of shader instructions used.

 

[Reverend]

Slightly OT :

I wonder if B3D should run another competition whereby it's "Who can make a scene/demo with the most bumps?".

 

[Simon F]

Slightly OT :

I wonder if B3D should run another competition whereby it's "Who can make a scene/demo with the most bumps?".

Does this count? (DC bump map from eons ago)

 

[xGL]

I just get a black screen with a white dot moving around on my 6800.

sounds like an illegal optimisation.

This is very weird.

The demo works without any artifacts on XGI Volari Duo card - maybe the 6800 does not render as much as the Volari?

Seriously though, here's a picture on the Volari Duo:

 

[coredump]

Using Green may make more sense

Humus,

You may consider using the green channel in DXT5, given that the reference colours are stored 5/6/5. I'm not sure how much better one extra bit looks...

 

[Humus]

Well, that would take another instruction to put things in order, alternatively I'd have to flip the light and view vectors I pass from the vertex shader. The problem is not so much that the precision is low, but rather that there are only 4 possible colors.

 

[KimB]

It wouldn't require an extra instruction on nVidia hardware, would it?

 

[Mendel]

there are only 4 possible colors.

Forgive my ignorance but could someone please explain this issue a bit more clearly, for dummies like me? only 4 colors? What? why? In which case?

 

[mczak]

there are only 4 possible colors.

Forgive my ignorance but could someone please explain this issue a bit more clearly, for dummies like me? only 4 colors? What? why? In which case?

S3TC (DXT) operates on 4x4 pixel blocks. 2 reference colors are stored per block, and 2 more colors are derived from those 2 reference colors. Each pixel in the 4x4 block then is basically stored as an index into this 4-color palette. Thus no more than 4 colors per 4x4 pixel block.
(that's only for for the RGB part. Alpha (in DXT5) is similar, but there are 2 reference alpha values and 6 derived values, so a 8-color palette is used. Much lower compression ratio than the RGB part though, only 1:2.)

 

[Ostsol]

http://udn.epicgames.com/Two/TextureComparison

Take a look at the "DXTC Nightmare" for some real emphasis on the colour limitation (like Epic says, though, it is a truly unfair scenario).