How to correctly use BumpMapping ?

[dak]

Hi,

I have a GeForce 4 MX and I've read that I can use BumpMapping with it.
But I've also read that BumpMapping can't be enabled with DDS textures and the textures I'm using are in the DDS format ... Is it true ? (I'm asking this because it seems that BumpMapping isn't enabled with my Earg :/)

Moreover, bumpmapping files should be put in "NormalMap" or "BumpMap" ? What are the differences between them ?

Thanks.

[bh]

I've been told that bump mapping does not work with version 1.3.0! You have to install a later beta. Most annoying!

[JackHiggins]

I've got a GeForce 4 MX 440 & i can see all the eye candy stuff (haze, bumpaps, normalmaps, spec lighting etc)

1. Bumpmaps can be used with dds textures, what you probably read is that you cant have a "dds bumpmap"- menaing you cant have "earth-bump.dds". If you try to, Celestia will crash. (Believe me, ive tried)

2. Bumpmaps (always grayscale) should be used with an ssc code of "BumpMap". Normalmaps are different they're usually bluey-pink coloured, but do the same job. I think they're faster to load or something...?

[selden]

Normalmaps are different they're usually bluey-pink coloured, but do the same job. I think they're faster to load or something...?

Briefly: normalmaps can provide more precision in the description of how shading should be done than greyscale bumpmaps can have.

greyscale bumpmaps can only have 256 altitude levels.

Normalmaps use all three color channels to describe the direction that the pixel is "facing." In principle, they can have up to 24 bits of precision instead of only 8.

[ElPelado]

I need a .dds normalmap for the Earth. I found one but its not good. Where I can find a good one??

[John Van Vliet]

How about using my Eathh Normal map
I have it posted as a .png and as a .dds in 8k and 4k

[t00fri]

How about using my Eathh Normal map
I have it posted as a .png and as a .dds in 8k and 4k

A good Normal map of Earth would start directly from the 16bit/channel GLOBE elevation data, and be converted with Chris' new tool to an 8bit/channel Normalmap. Then it would be encoded with 24bit color option to DXT3.

As soon as I find some more time, I will do this.
I have made the analog Normalmap for Mars from the 16bit/channel MOLA data. The results are simply spectacular and in no way comparable to anything before! Remember, that most of the details you see in a texture within Celestia, actually comes from the Normal map!

Chris' converter so far is only existing for Linux. People without that tool can use another technique that I explored previously for 16bit/channel elevation data. It also gives excellent results/smoothness. Convert a number of 16bit raw data independently via dithering to 8bit (Photoshop) and stack these on top of each other, like one does in CCD astronomy!

Bye Fridger

[ElPelado]

I tryed yours John, but it didnt look so good.

[John Van Vliet]

I am still learning so give me time
3 years ago i could not even opporate a computer (still cant spell)
Now that you mention it i dont care for mine to mutch ether
it works and looks ok ,but not great

[Evil Dr Ganymede]

Normalmaps use all three color channels to describe the direction that the pixel is "facing." In principle, they can have up to 24 bits of precision instead of only 8.

Really?!?!
Bloody heck, that's dead clever, that is.

So does it work like this?: You have three colour channels for a given pixel. Channel A determines the slope of that surface parallel to one axis (say, the left-right axis of the image). Channel B determines the slope of that surface parallel to the top-bottom axis of the image. Channel C determines the slope of that surface parallel to the up-down axis (coming into/out of the plane of the screen).

Does that sound about right?

[selden]

Yup.

I had a reference to a Web page that showed the differences, but I've managed to misplace it. I know I mentioned it in a previous posting somewhere here...

[t00fri]

...

greyscale bumpmaps can only have 256 altitude levels.
...

Here I disagree. Let me explain.

/Usually/ grayscale elevation maps use 8bit <=> 256 levels only. But, of course, this is not at all a limitation of principle. Some of us, like myself, are experimenting since quite a while with 16bit grayscale elevation/bump maps. All the really good elevation data from Earth (GLOBE-DEM, ETOPO2) and Mars (MOLA) use 16bit integers encoded in *.raw format to characterize the elevations. Clearly, one needs this many levels, e.g. in order to describe subtle elevation details of Olympus Mons that is between 21 and 22 km high!

However, many software applications do not work yet with 16bit/channel maps (...Celestia...) or only partially (Photoshop). Others do work well already with 16bit/channel, like ImageMagick or a special version of GIMP.

Chris has just written a short piece of code that uses the full 16bit information of such *.raw data to calculate the gradients ("derivatives") in the normal map. It truncates the result to 8bit /at the very end/, after the normal map is done!

I had previously obtained about equivalent results by stacking and blending a number of maps together that each involved /randomly/ dithered 16bit->8bit reduction, a technique very familiar from CCD astronomy. This way one may /emulate/ 16bit/channel smoothness with 8bit/channel textures...

Normal maps involve calculating the /vector/ of derivatives with respect to 3 suitable spacial directions, in order to determine the normal /vector/ of the given texture in a certain point. The 3 componets of that vector are mapped on the 3 color channels R,G,B of the normal map.

People with some insight into /numerical math/ know that the numerical calculation of /derivatives/ is notoriously a tricky affair: small uncertainties can blow up badly in derivatives. So starting from 16bit/channel for the elevation map is a great leap forward towards calculating those derivatives with much better smoothness!

Bye Fridger

[t00fri]

Here is a quick illustration what the 16bit quality of the ETOPO2 Earth bathymetry elevation data looks like, if converted with Chris' 16bit->8bit tool into a normalmap.



For experts: I have chosen this evening light, because artifacts related to lacking smoothness of the normalmap tend to become most visible this way. Look specially at the "flat" desert areas towards the setting sun in the upper left: absolutely smooth and clean!

Also look at the structure in the Red sea bed;-). This 8k normal map gives marvelous "bathimetry views"...

Bye Fridger

[chris]

Normalmaps are different they're usually bluey-pink coloured, but do the same job. I think they're faster to load or something...?

Briefly: normalmaps can provide more precision in the description of how shading should be done than greyscale bumpmaps can have.

greyscale bumpmaps can only have 256 altitude levels.

Normalmaps use all three color channels to describe the direction that the pixel is "facing." In principle, they can have up to 24 bits of precision instead of only 8.

Jack, you're right that normal maps load faster. That's because grayscale bump maps need to be converted to normal maps before they can be used for rendering. With a precomputed normal map, this process can be skipped.

Precomputed normal maps may also be higher quality than the ones computed from height maps, but it's not because they have 24 bits of precision. There are two ways to get better quality with a normal map--starting with 16-bit source data, and using a more sophisticated filter to compute the gradients. 16-bit source data makes the biggest difference; Fridger's experiments with 'better' filters haven't produced nicer looking normal maps so far.

Someplace in the forum, I did a precision analysis of using 8-bit and 16-bit height data to generate an 8-bit per channel normal map. Basically, it comes down to the fact that you're interested in gradients--height differences--not absolute height values. The minimum slope between adjacent texels is very large on 8-bit height maps of Mars and Earth because the range between the maximum and minimum heights is so large. With a 16-bit height map and an appropriately chosen bump height, subtle sloping areas will still appear as such even with an 8-bit normal map.

Eventually, I'm going to play around with 16-bit per component normal maps. The x and y gradients will each be 16-bits. The third component can be calculated on the fly in a pixel shader instead of being stored in the texture . . . This should produce outstanding results, though it remains to be seen how much better they'll look than 8-bit per component normal maps.

--Chris

[t00fri]

...
There are two ways to get better quality with a normal map--starting with 16-bit source data, and using a more sophisticated filter to compute the gradients. 16-bit source data makes the biggest difference; Fridger's experiments with 'better' filters haven't produced nicer looking normal maps so far.
...
--Chris

Chris:

I am not sure whether I interpret correctly what you want to say in reference to the 16bit studies I have been pusuing since a long while.

First of all, I have always pointed out that 16bit source data is inevitably the key to a smooth calculation of gradients. Many many times in this forum...
So my "filter" experiments were certainly a secondary issue in this context.

Another crucial improvement aspect beyond the two you listed above (16bit/channel source code and optimal filters in the normal map calculation) concerns the fact that Celestia does not work yet with 16bit bump maps. So the question arises, how to convert the 16bit elevation source data /best/ into 8 bit with the constraint of keeping optimal smoothness!

My method of stacking and blending randomly 8bit dithered 16bit elevation maps certainly leads to much improved 8bit quality. It simply has to, provided the dithering was truly random;-). One can show rigorously that this familiar method emulates eventually 16bit quality. It's just a bit tedious in practice.

Recently it turned out that one obtains similar quality with less work (!), by using your tool that computes the gradients at 16bit level and then simply truncates the result to 8bit at the very end. So this is an alternative method of arriving at 8bit. And it's an economic one, hence I think it is the method of choice in the future...

Bye Fridger

[chris]

[
Chris:

I am not sure whether I interpret correctly what you want to say in reference to the 16bit studies I have been pusuing since a long while.

I was talking about your experiments with using different filtering techniques (e.g. a 3x3 Sobel kernel) to produce the gradients. You mentioned that they appeared to 'over-smooth' the data. That's all . . .

--Chris

[t00fri]

[
Chris:

I am not sure whether I interpret correctly what you want to say in reference to the 16bit studies I have been pusuing since a long while.

I was talking about your experiments with using different filtering techniques (e.g. a 3x3 Sobel kernel) to produce the gradients. You mentioned that they appeared to 'over-smooth' the data. That's all . . .

--Chris

Sorry, I somehow felt I was misinterpreting something ... (well, these 'foreigners'...;-))

Of course, I completely agree with that part of the story. 2x2 blocking is best provided the source was smooth enough.


Bye Fridger