Normal Maps Again

oXYnary

Im trying to see if I can find and justification to give to our programmer about incorporating 3Dc or DXT5_NM for tangent maps since I found out the engine we use can only do tangents - period. . I found nvidia's showing Ids document about the different normal map options.

http://developer.nvidia.com/object/real-time-normal-map-dxt-compression.html

He wasn't convinced. His idea, is we can always make the textures higher res to make up for any compression artifacts. Which he is correct, but I'm trying to think of optimization (and not having to create high detailed diffuse maps to match which would take even more of my time [yea I know I could do the diffuse in a lower rez, but depending, some high frequency normal map detail would look wack with a lower frequency diffuse]).

Does anyone know of some pictures of a model that clearly show the difference between regular dts5, dts5_nm, uncompressed, and 3Dc that they can link to pictures of? Or is it really not that noticeable?

This will be mostly on non characters at this point, though later on this may change.


::::
(Oh and since I have this space, so I dont have to start a new thread for this doofus q. What is the default key in max to get out of sub-object mode)

CrazyButcher

you should give this thread a better topic name (add 3dc/compression whatever)

http://ati.amd.com/developer/compressonator.html dont have it installed, but maybe it has a modelviewer built-in

other than that the nvidia/id article does show the difference well, dont you think? At least its more objective to compare tangentmaps themselves, other than comparing models which can look better/worse depending on model itself.

I am not sure whether its good to just "upsample". If you use larger textures, you at least ruin the size advantage again. I also doubt the artefacts will go away, cause you frequently wont have the highest-mipmap active either, and the "downscaled + compressed" versions, will show artefacts again.

While the NM/3DC do use a few more shader instructions it completely depends on your target hardware. Adding those few instructions could be "over" the limit for old cards. For the majority of cards today it wont be an issue so.

Eric Chadwick

You have Max. Ben Cloward supports DXT5_nm compressed vs. TGA non-compressed, so you can compare them with your own models.
http://www.bencloward.com/shaders_NormalMapSpecular.shtml

3Dc (aka BC5 in DX10) is really really close to uncompressed in quality, you would be hard-pressed to see the difference.

oXYnary

The programmer wants models in a game environment showing the compression amount or not. I mean, I know these are better methods with less artifacts. In order to convince him to add support for these methods, I need to show some website with pictures of comparison models in game with the different texture compression.

I cant show him any models of my own given the engine now doesn't even support these. On top of that, even if I used Bens shaders for the max viewpoint and took screenies, I can see him making an argument that that does not reflect what the engine will show (which from my experience in max, he is correct)

Edit: We are trying to support dx9 (not just 9c and 10). Given this, are you saying I should not even bother to convince him Crazy?

Eric Chadwick

Your programmer is being obtuse. FX shaders in Max use exactly the same rendering technique as any game that renders via DirectX. 3Dc and DXT5_nm can be supported easily in regular old dx9, afaik.

CrazyButcher

In the low-end ps2_0 profile you have 64 ALU instructions, 3dc/NM take 2 more (if you renormalize already, 4 more if you don't). 4 instructions is not a lot, however it could exceed those 64 if shaders are at limits already. This case is unlikely, and by the sound of it your programmer has some unknown other reason being so much against your incentive...

the article shows clearly dx5nm and 3dc superior (with 3dc basically almost loss less).

and I can support Erics statement that using max viewport is sufficient. You might not easily have the final shading look (shadows, bloom...) but those are independent anyway.

It's also very little work to "implement" this, basically a preprocessor #define after the normalmap fetch could contain the code for the behavior and then could easily be turned on/off for all shaders and changed for dx5nm/3dc. I doubt copy pasting that macro into all normalmap fetches of the engine would take a very long time.

the main bulk work would be if there is no DDS loading in the engine, ie he would need to change the texture upload and swizzle data and such... And he would need to mark which textures are normalmaps and which not. Here lies probably the main issue... the other stuff imo would be fast on the code side.