Testing Chris' new, compressed normalmaps (part 2)

[chris]

It?€™s well and fine that you go to all this work to make these great normalmaps and all. But we as community never get our collective hands on any of your work. You always tease us but never give us anything. You seem to be more interested in keeping these advances to yourself or your tight knit group of Developers.

I just implemented compressed normal maps last night! This is *very* early testing of a new feature.

Anyhow, I think Fridger's normal map tools will be ready for release RSN

--Chris

[chris]

Using 'nms' from the nmtools package , I generated a high-quality 16k normalmap of Earth from the srtm-ramp2 16bit elevation data.

Next with GIMP, I decomposed the 16k normalmap into R,G,B grayscale layers and subsequently composed a new 16k map, with R->G, G->Alpha, and B, R->black finally. Saved as a PNG file (compression 9) it's ~49.5 MB. The uncompressed PNG is, however 537.7 MB in size!

Next I used my well-proven 'texconvert' tool that I coded long ago, using the DeVIL lib to compress the modified file as a DXT5 which goes quite fast. The NVDXT tools will not work with big size files as you all know. And they are very slow. One needs however really big size to critically evaluate the resulting quality.

The final DXT5 file is 178.9 MB. So relative to the uncompressed PNG, I got a 3.0:1 compression with my DXT5 enconding (why not 4:1?). Due to Mipmaps?

Anyway the result looks quite good and there seem no obvious bugs in Chris' new CVS code of tonight. I'll get back when I have compared it carefully with the corresponding lossless 16k PNG normalmap.



If I wasn't so busy with finishing my CelestialMatters tutorial (at last), I'd quickly code a little additional module ('remapcolors') to be piped after nms or nmstiles from our nmtools package. Then my tiles from my 64k normalmap could be automatically converted to the new compressed DXT5...

That image looks good! Thanks for taking the time to test this new feature. If I have some extra time this weekend, I'll write a remapcolors utility.

I should mention that it took only about half an hour to write and test the normal map compression feature. Celestia's GLSL shader generator makes things like this very simple.

--Chris

[t00fri]

[t00fri]

Chris,

I noticed that Doug's latest nvdxt tools have a special -dxt5nm compression mode that is presumably the same as described in the NV white paper which I now have read carefully. I.e. the red channel becomes alpha and the green one is placed identically into the RGB channels ("luminance").

So it's like what you did, except there does not seem to be the R<->G flip which you incorporated in addition (because of accuracy arguments)? Moreover, the 2 un-needed channels are not zero'ed out.

So I compressed the first 4 VT levels with -dxt5nm and examined the result. It looks very much like what I tried
yesterday by hand. Unfortunately, Doug did not add a single word of description of -dxt5nm...


++++++++++++
Can you tell me (for testing) where I can switch off your extra R<->G map in the code? Saves me some browsing.
++++++++++++

Bye Fridger

[chris]

++++++++++++
Can you tell me (for testing) where I can switch off your extra R<->G map in the code? Saves me some browsing.
++++++++++++

Bye Fridger

It's a single character change . . . Change this part of the function buildFragmentShader() in shadermanager.cpp:

Code: Select all

            if (props.texUsage & ShaderProperties::CompressedNormalTexture)
            {
                source += "vec3 n;\n";
                source += "n.xy = texture2D(normTex, " + normTexCoord + ".st).ga * 2.0 - vec2(1.0, 1.0);\n";
                source += "n.z = sqrt(1.0 - n.x * n.x - n.y * n.y);\n";               
            }


Change the .ga (green/alpha) to .ra (red/alpha):

Code: Select all

            if (props.texUsage & ShaderProperties::CompressedNormalTexture)
            {
                source += "vec3 n;\n";
                source += "n.xy = texture2D(normTex, " + normTexCoord + ".st).ra * 2.0 - vec2(1.0, 1.0);\n";
                source += "n.z = sqrt(1.0 - n.x * n.x - n.y * n.y);\n";               
            }


--Chris

[t00fri]

Thanks, Chris,

that was helpful. By undoing your r<->g flip in shadermanager, I could test BOTH a full, -dxt5nm compressed 4k normalmap versus the identically compressed 1k x 1k normalmap tiles of the first 4 VT levels.

Here is what I find:

a) The full 4k normalmap, declared in solarsys.ssc by
NormalMap "nms4k.dds"

works equally well as my 16k compressed nm of
yesterday (including the r<->g flip). That's fine and
makes the latest nvdxt tools quite useful. However, they crash already when compressing 8k sizes! Hence the nvdxt tools are only useful for compressing small tiles.

b) After compressing levels 0 to 4 of my normalmap tiles again with -dxt5nm, the illumination of the earth surface appears very low and only in a partial FOV. Yet the nm shading is visible at small FOV.

So it seems there is a bug in the tile part of the code,...
I suppose you never explicitly tested the functioning of your new code with VT's!?

Bye Fridger

[chris]

So it seems there is a bug in the tile part of the code,...
I suppose you never explicitly tested the functioning of your new code with VT's!?

Ugh. No, I didn't. I'm sorry about that . . . It turns out that the compression flag was not getting set for virtual textures. I fixed that, but it's a bit of a hack. I'm wondering if now if checking for DXT format is really the best way to specify texture compression. The problem is that with a virtual texture you can't tell whether it's compressed until the first tile has been loaded. I think that I may have to add a new item to the .ctx format to specify that it's a compressed normal map.

--Chris

[t00fri]

So it seems there is a bug in the tile part of the code,...
I suppose you never explicitly tested the functioning of your new code with VT's!?

Ugh. No, I didn't. I'm sorry about that . . . It turns out that the compression flag was not getting set for virtual textures.

That's why I was testing the VT's.

I fixed that, but it's a bit of a hack. I'm wondering if now if checking for DXT format is really the best way to specify texture compression. The problem is that with a virtual texture you can't tell whether it's compressed until the first tile has been loaded. I think that I may have to add a new item to the .ctx format to specify that it's a compressed normal map.

--Chris

Anyway NOW everything works great!

What was your precise incentive to add that additional R<->G flip, relative to the NV White paper? Since as it is now, the nvdxt tools work very nicely, with LOTS of quality and speed options etc.

Should one actually include mipmaps or not? After all the various tile levels ~ act like mipmaps don't they?

Below, I made a concise comparison of the smoothness and detail of the level4 nm tiles in PNG (top) versus the new DXT5nm compressed tiles (bottom). The latter are even zoomed in a bit more, yet I think the quality and smoothness of the new compression is REMARKABLE.

+++++++++++++++++
So what exactly are we gaining: when comparing PNG vs DXT5nm on a 256MB FX card?
++++++++++++++++

Opinions?

Cheers,
Fridger

[chris]

Anyway NOW everything works great!

That's very good news!

What was your precise incentive to add that additional R<->G flip, relative to the NV White paper? Since as it is now, the nvdxt tools work very nicely, with LOTS of quality and speed options etc.

I think it was the NVIDIA white paper which recommended using green instead of red. DXT5 compressed textures are divided into 4x4 blocks that each have a palette generated by interpolating two 'anchor' colors. These colors are packed into 16 bits, with 5 bits for red, 6 bits for green, and 5 bits for blue. The extra bit of precision in green is why I picked it instead of red.

Should one actually include mipmaps or not? After all the various tile levels ~ act like mipmaps don't they?

Right. Mipmaps are unnecessary for VTs except for the root level textures.

Below, I made a concise comparison of the smoothness and detail of the level4 nm tiles in PNG (top) versus the new DXT5nm compressed tiles (bottom). The latter are even zoomed in a bit more, yet I think the quality and smoothness of the new compression is REMARKABLE.

+++++++++++++++++
So what exactly are we gaining: when comparing PNG vs DXT5nm on a 256MB FX card?
++++++++++++++++

Opinions?

PNG (24-bit RGB) normal maps:
Advantages:
- Better quality (though as your images demonstrate, DXT5nm is very competitive)
- Works on any hardware that supports the vertex shader/DOT3 path
Disadvantages:
- Requires a lot of memory

DXT5nm
Advantages:
- Uses less memory (4:1 compression because 24 bit per pixel RGB textures get expanded to 32-bit per pixel RGBA textures in video memory.)
- Since normal z is generated, the normals will *always* have unit length
Disadvantages:
- Requires DX9/OpenGL 2.0 class hardware
- Extra calculation required in the pixel shader--could be slower on some systems
- Quality not quite as good as 24-bit RGB

--Chris

[t00fri]

What was your precise incentive to add that additional R<->G flip, relative to the NV White paper? Since as it is now, the nvdxt tools work very nicely, with LOTS of quality and speed options etc.

I think it was the NVIDIA white paper which recommended using green instead of red. DXT5 compressed textures are divided into 4x4 blocks that each have a palette generated by interpolating two 'anchor' colors. These colors are packed into 16 bits, with 5 bits for red, 6 bits for green, and 5 bits for blue. The extra bit of precision in green is why I picked it instead of red.

Yes that 565 argument was mentioned in NV Dev and is what I assumed you wanted to exploit. But it is a bit less "standard" since Doom3 uses the red channel for alpha. Correspondingly, the nvdxt tools are also straight supporting the red-> alpha map.

PNG (24-bit RGB) normal maps:
Advantages:
- Better quality (though as your images demonstrate, DXT5nm is very competitive)
- Works on any hardware that supports the vertex shader/DOT3 path
Disadvantages:
- Requires a lot of memory

DXT5nm
Advantages:
- Uses less memory (4:1 compression because 24 bit per pixel RGB textures get expanded to 32-bit per pixel RGBA textures in video memory.)
- Since normal z is generated, the normals will *always* have unit length
Disadvantages:
- Requires DX9/OpenGL 2.0 class hardware
- Extra calculation required in the pixel shader--could be slower on some systems
- Quality not quite as good as 24-bit RGB

--Chris

There is another significant disadvantage for MONSTER sets: DXT5nm uses more than a factor of 2 more space on the harddisk and for dowloading! That difference can easily come up to > 1 GB. PNG's compress 9:1 while DXT5 does only 4:1.

On the level of 1k /tiles/ and 256MB cards, the DXT5 memory advantages seem less convincing. By playing with the new packed tileset, I got the feeling, however, that the texture loading is faster/smoother than in case of PNG tiles. I will look into that aspect quantitatively soon.

Bye Fridger

[t00fri]

The latest nvdxt tools (Windows, v. 8.22) work very well in their special DXT5nm mode to compress normalmap tiles in high-quality mode.
So you may easily install them with an installer from

http://developer.nvidia.com/object/dds_utilities.html
Don't forget to install the Photoshop dds plugin as well, if you have PS.

Here is the console command that you may use to convert whole levelx directories of *.png normalmap tiles to the new *.dds format.

Code: Select all

nvdxt  -quality_highest  -file *.png  -nomipmaps -dxt5nm


If you inspect the DXT5nm compressed tiles with the included DDS viewer wtv.exe, they appear with gray background now.

Don't forget, you need the latest CVS code of Celestia for this to work.

I have now analyzed, what the -dxt5nm option precisely does:

It copies r->alpha, g -> r,b and then DXT5 compresses the result.

For consistency you should make the simple replacement (.ga -> .ra) in shadermanager.cpp that Chris specified above. But things also work without that modification.

These simple actions allow others to experiment with the new format as well.

Incidentally, if you have ImageMagick >6.0, you may also use the 'convert' utility to modify the layers of the nm tiles precisely as needed, using the -channel and -fx options. 'convert' can work with STDIN, whence it may be piped behind my tools for normalmap creation. But it's kind of slow and inefficient...

Bye Fridger

[selden]

comments about graphic card tradeoffs have been moved to the thread

http://www.celestiaproject.net/forum/viewtopic.php?t=10044

[t00fri]

comments about graphic card tradeoffs have been moved to the thread

http://www.celestiaproject.net/forum/viewtopic.php?t=10044

Thanks, Selden.

[t00fri]

Meanwhile I have completed the DXT5nm compressed level5 of my 64k normalmap.

Moreover, I exploited another new feature: my 64k spec file also has on land a little light, i.e. a slight deviation from black. This slight spec effect boosts the new normalmap rendering just great. I took the value 0x40 (hex) which almost looks black, but isn't!

So here are three close-up test shots from the Andes. Watch the amazing normalmap rendering due to the little spec light. Also note that these are DDS compressed VT's!

Bye Fridger

a) Close-up of the coastal region
Have a click!

b) Close-up of the alti-plano
Have a click!

c) Close-up of the alti-plano
Have a click!

[ElChristou]

...Watch the amazing normalmap rendering due to the little spec light...

I don't know how it looks on your giant screen, but on my 1024 the spec light is too much plastic like to my taste...

Now the normal map seems really fantastic...

[chris]

The normal map looks amazing. I agree with ElChristou that the specular lighiting is unrealistic. However, enabling specular highlights is an excellent way to show off the quality (or lack of quality) in a normal map. The power function in the Phong specular lighting model will reveal fine detail (and small glitches) in a normal map that often don't appear with diffuse lighting.

--Chris

[t00fri]

Yes, that slight shiny 'plastic' look comes from the spec lighting during the normalmap rendering.

Here is a more enhanced reminder from Mars.
Can that impression somehow alleviated?

[chris]

Yes, that slight shiny 'plastic' look comes from the spec lighting during the normalmap rendering.

Here is a more enhanced reminder from Mars.
Can that impression somehow alleviated?

We need to figure out what photometric model is appropriate for the Martian surface. It's not the Phong specular lighting, which is intended to approximate how light reflects from a smooth surface. Of the photometric models that Celestia implements, LunarLambert is likely the closest match to reality.

--Chris

[cartrite]

What specpower are you using? On Mars I set mine to "specpower 1" and I don't get that plastic look. I also use a mono color spec map that is all 2e2e2e's. On earth my land areas are 595959 and my settings are

Code: Select all

   SpecularColor [ 0.266 0.233 0.183 ]
   #SpecularColor [ 0.5 0.5 0.55 ]
   SpecularPower 25.0

and I get a slight plastic look. Mabey the land areas should be darker in the specmap?
cartrite

[t00fri]

What specpower are you using? On Mars I set mine to "specpower 1" and I don't get that plastic look. I also use a mono color spec map that is all 2e2e2e's. On earth my land areas are 595959 and my settings are

Code: Select all

   SpecularColor [ 0.266 0.233 0.183 ]
   #SpecularColor [ 0.5 0.5 0.55 ]
   SpecularPower 25.0

and I get a slight plastic look. Mabey the land areas should be darker in the specmap?
cartrite

The Mars image above is not how my mars texture looks like. It's just a drastic example to illustrate the 'plastic' look

Bye Fridger