DXT5-NM Red and Blue Contradictions.
polycounter lvl 18
I thought from this Nvidia writeup, a engine creator could use the OUTPUT red and Blue channel to contain more vector information that the OUTPUT green channel missed. I am not having any confusions about the swizzle of red and blue in the original file to green and alpha in the output dds.
As in like the blue or red "looks" at a different tighter (like 128-256) value to capture more data in that range. Then combines it with the output green channel to give a slightly better bit depth than otherwise.
http://developer.download.nvidia.com/whitepapers/2008/real-time-normal-map-dxt-compression.pdf
Even our own polycount page seemingly makes a brief mention of this though with a bit of contradiction in its phrasing. It claims you can use a texture in the otherwise blank channels to reduce artifacts, but then claims artifacts will be greater than if these channels were blank..
http://wiki.polycount.com/NormalMap/
**(That link to the Nvidia Developer forum thread no longer works. Anyone know the exact thread in question??)
Since the Nvidia plugin for photoshop is still putting a version of the green channel in the red and blue. I assume its thinking the engine the dds is being put in will be using this latter method of using red or blue to give more data for green? If not, then where in its options do I turn off it making copies in those channels if its reduced quality?
As in like the blue or red "looks" at a different tighter (like 128-256) value to capture more data in that range. Then combines it with the output green channel to give a slightly better bit depth than otherwise.
Instead of storing a bias and scale, one of the spare channels can also be used to store a rotation of the normal vectors
http://developer.download.nvidia.com/whitepapers/2008/real-time-normal-map-dxt-compression.pdf
Even our own polycount page seemingly makes a brief mention of this though with a bit of contradiction in its phrasing. It claims you can use a texture in the otherwise blank channels to reduce artifacts, but then claims artifacts will be greater than if these channels were blank..
There are some options in the NVIDIA DXT compressor that help reduce the artifacts if you want to add texture to the Red or Blue channels. The artifacts will be greater than if you keep Red and Blue empty, but it might be a tradeoff worth making. Some notes about this on the NVIDIA Developer Forums**.
http://wiki.polycount.com/NormalMap/
**(That link to the Nvidia Developer forum thread no longer works. Anyone know the exact thread in question??)
Since the Nvidia plugin for photoshop is still putting a version of the green channel in the red and blue. I assume its thinking the engine the dds is being put in will be using this latter method of using red or blue to give more data for green? If not, then where in its options do I turn off it making copies in those channels if its reduced quality?
Replies
There's not trickery about storing data 'across' different channels to get a higher bit-depth or anything though, not to my knowledge. One of these should end up looking very "green" because the red and blue channels are empty (black).
I am specifically talking about the red and blue channels in the dxt5-nm itself. The writing I have found seems to imply you can use at least one of these channels to compliment the green channel of the output to give a better range than it would otherwise from the lower bitdepth. But a game engine has to take advantage of this to work.. Again, if I'm reading the Nvidia article right.
I will go and edit original to make more apparent.
(Sprunghunt, yes, thats my plan personally, but I need to find out about this specific inquiry for a dxt5nm implementation.)
Doug Rogers explained the DXT compression thing to me when he was working on the NVIDIA plugin for Photoshop.
The way I understand it, DXT compares all three RGB channels for each 4x4 block of pixels, in order to compress them down to a smaller range of colors. The compressor makes a vector through all three, and computes the offsets needed to store each. All three channels have to use the same offsets for each 16-pixel chunk.
So if the values in R and B are different from G, then it has to expand its range to encompass them all, which means each channel gets lets precision in the end.
Think of the RGB channels as levels in a 3d chess board, and trying to draw a line connecting each. Colors can only be stored within a certain radius around that line. At least that's how I visualize it.
If R and B contain blank values, then G can be compressed more accurately.
If you wanted to add back in the data that was tossed out when compressing G, adding this back into R and/or B would then change the compression vector, which would then change G again. If you don't recompress, you still would have to fit the extra G data into the compression range allowed for that 4x4 block.
Definitely beyond my knowledge, and I probably have some things wrong here. Maybe do-able, you would need a graphics programmer.
No contradiction in the wiki there, I think. Maybe reading too much into it? To re-phrase it... you can use R and B channels for other texture data like a specular map, and you can use some options in the NVIDIA DDS exporter that will try to move that compression vector around, but it still will have to compress those pixels. It just does the compression a little differently.
The content in the R and B channels don't fix compression errors. Actually they make it worse. Nvidia's option just tries to reduce the errors. Doesn't do that great a job, as it's a problem inherent in how DXT compression works.
Link is dead, sorry. Nvidia redid their forums so the old stuff is gone.
I have to ask though. If leaving R and B blank produces better results... Why is the nvidia photoshop dxt5-nm making copies of whats in green in each of those channels by default? Is there an option I'm not seeing in it to disable?
Or at least that's my artist brain's understanding of it. I'm not a programmer. :poly124: