Celestia Forums

As the title may suggest:

I have a problem changing the height of a Normal map.
The Normal map of the moon I found on the motherlode seems way to exagerated to my opinion.

There is hardly anything in this forum mentioning this option,
there is a also discrepancy about using either the BumpHeight option for this,
or a "NormalHeight" in the solarsys.ssc file.

I tried both options but can't seen any difference either way.

Ren?©

rra wrote:As the title may suggest:

I have a problem changing the height of a Normal map.
The Normal map of the moon I found on the motherlode seems way to exagerated to my opinion.

There is hardly anything in this forum mentioning this option,
there is a also discrepancy about using either the BumpHeight option for this,
or a "NormalHeight" in the solarsys.ssc file.

I tried both options but can't seen any difference either way.

Ren?©

Unlike bumpmaps, the height parameter in normalmaps for Celestia is hardcoded when the NM is generated. So simply make a new NM if you are dissatisfied.

Also, note that all NM's on Motherlode are increasingly incorrect north and south of the equator. What is missing is the spherical geometry correction.

Bye Fridger

Thanks ,
I think can change the amplitude of the bitmaps theirselfs
like you suggested.
Do you think bumpmaps are in principle "better" or is it just
the ones posted on the motherlode ??

Do you, or anyone else, have any links to other
normal or bump maps of the moon ?

Ren?©

rra wrote:Thanks ,
I think can change the amplitude of the bitmaps theirselfs
like you suggested.
Do you think bumpmaps are in principle "better" or is it just
the ones posted on the motherlode ??

Do you, or anyone else, have any links to other
normal or bump maps of the moon ?

Ren?©

For really hires elevation info you need normalmap VT tiles. VT's don't work with bumpmaps in Celestia.
For lowres either one is fine in principle, yet normalmaps are faster. Bumpmaps first have to be converted internally into normalmaps...that takes time.

Unfortunately, really high-quality elevation information of the moon is not available.

Bye Fridger

rra wrote:Thanks ,
I think can change the amplitude of the bitmaps theirselfs
like you suggested.
Do you think bumpmaps are in principle "better" or is it just
the ones posted on the motherlode ??

Bump maps are in fact worse than normal maps in two regards:
- They load more slowly because they have to be converted to normal maps first
- They're lower quality, because the bump map is 8 bits, whereas good quality normal maps are generated from 16-bit or 32-bit data.

--Chris

chris wrote:Bump maps are in fact worse than normal maps in two regards:
- They load more slowly because they have to be converted to normal maps first

Precisely my saying several lines up

t00fri wrote:...yet normalmaps are faster. Bumpmaps first have to be converted internally into normalmaps...that takes time.

Chris wrote:- They're lower quality, because the bump map is 8 bits, whereas good quality normal maps are generated from 16-bit or 32-bit data.

I wonder whether we could not allow for the usual 16 bit (signed) int input for bumpmaps in the .ssc file.
After all that's how elevation maps are published!

This would often be VERY handy for testing, yet the coding effort seems small. Doing this would allow for the same /high-quality/ conversion to the internal 8bit x 3 normalmap as in our external normalmap generators.

The only possible counter argument in my view could be speed. But it might well be worth a try.

Bye Fridger

t00fri wrote:I wonder whether we could not allow for the usual 16 bit (signed) int input for bumpmaps in the .ssc file.
After all that's how elevation maps are published!

This would often be VERY handy for testing, yet the coding effort seems small. Doing this would allow for the same /high-quality/ conversion to the internal 8bit x 3 normalmap as in our external normalmap generators.

The only possible counter argument in my view could be speed. But it might well be worth a try.

It certainly would be possible; it's just the effort of making the changes that have kept me from doing it. It wouldn't be that difficult if you want to have a go at it. At the moment, I've got too many other tasks on my plate.

--Chris

If both of you (Fridger, Chris) agree that Normal maps are the better
bitmaps to use, why isn't there a option to change it's altitude scale
a la "BumpHeight" ??

Also I find some bump/normal maps to contain 3 channel information,
I would expect only 1 channel ("gray") presenting the height.
Can someone point me to any info on how Celestia deals with
the (3) channel data ?


Ren?©

with my site down i will have to uplode my 4k moonbump and normal ( hand air-buushed image " rosiek_lunarDEM_simp.png" )to the motherlode

give this link a try --first time using z11.zupload-- for the 4k bumpmap

http://z11.zupload.com/download.php?fil ... path=40181

about 40 people downloded it so it might be around the bumpmap is a 24bit RGB .png and gives great results and it is a bit exagerated --i like it that way --
as to changing the height in a normal map you nead to make a new one, from a bump map, the nvida photo shop plugin works good there is also a gimp plugin --it's old-- and i dont know how well it works there also is nm16 but that is a whole new ball of wax to play with

Ren?©,

Also I find some bump/normal maps to contain 3 channel information,
I would expect only 1 channel ("gray") presenting the height.
Can someone point me to any info on how Celestia deals with
the (3) channel data ?

BumpMaps are heightmaps and have a single 8 bit channel.

NormalMaps are normal vector maps and have three 8 bit channels.

A description of how normal vector maps work is at http://planetpixelemporium.com/tutorial ... ormal.html

selden wrote:Ren?©,

Also I find some bump/normal maps to contain 3 channel information,
I would expect only 1 channel ("gray") presenting the height.
Can someone point me to any info on how Celestia deals with
the (3) channel data ?

BumpMaps are heightmaps and have a single 8 bit channel.

NormalMaps are normal vector maps and have three 8 bit channels.

A description of how normal vector maps work is at http://planetpixelemporium.com/tutorial ... ormal.html

Selden,

I think Ren?© was aware of this and rather wondering about the apparently different number of "degrees of freedom" in the two related maps.

The first point to notice is that only 2 of the three rgb channels are independent, since normalmaps deal with unit vectors, i.e. r*r + g*g + b*b = 1. Normals are computed in terms of gradients dx, dy to the input height map associated with the given surface.

But I agree he best reads some standard text to understand. Another useful one might be

http://en.wikipedia.org/wiki/Normal_mapping

Published scientific heightmaps (as we use them) involve 16bit integers (signed), not 8bit.

In Celestia the supported bumpmaps are restricted to 8bit more for "historical" reasons. See my suggestion and Chris' reply a few posts up! Since internally Celestia calculates a normalmap from an input bumpmap, the resulting quality is not good (noisy) , since Celestia presently restricts the input bumpmaps to 8bit ints. It would be way better if a 16bit option for bumpmaps was available!

I'll look into the code to estimate the needed work.

Bye Fridger

selden wrote:A description of how normal vector maps work is at http://planetpixelemporium.com/tutorial ... ormal.html

IMHO, This is an excellent reference for 3D modelling tutorials Selden. (I've seen this site before ... perhaps from a prior post of yours )

I'd like to lay down the gauntlet now to all you "Normal mappers" out there to try the following (theoretical) advice from that page:

A properly constructed normal map can fool the eye into perceiving much more complex 3D geometry on a simple surface. Theoretically, normal maps on a cube can make it appear spherical, at least in terms of shading properties (the outline remains unchanged).

So, c'mon guys, let's see who can produce the best "sphere" on a cubic mesh in Celestia !!

Chuft-Captain wrote:So, c'mon guys, let's see who can produce the best "sphere" on a cubic mesh in Celestia !!

You mean the best cube on a sphere !

Cham wrote:

Chuft-Captain wrote:So, c'mon guys, let's see who can produce the best "sphere" on a cubic mesh in Celestia !!

You mean the best cube on a sphere !

No, but not a bad idea Cham.
I was thinking of creating a box model as a spacecraft, and then making it look like a sphere, but with your idea you could skip the modelling step and just use Celestia's inbuilt planetary meshes.....in terms of normals .it's just the inverse of what I suggested after all!

I officially extend the challenge to include either a "spherical cube" OR a "cubic sphere".