A few models I've seen lately have a normal map attached to them, rather 
than the standard bump map. POV-Ray uses bumpmaps.

Essentially, a normal map has the x,y,z coordinates in the r,g,b values, 
rather than grayscale. How hard would it be to implement a normal map 
such as this, rather than a bump map?

To further put salt on the wound, the one program out there that seems 
to be able to translate normal maps into bump maps costs $100 for a 
non-educational license, pretty high for a piece of software that has 
such a narrow purpose...

I need to sit down and write a small app that will do it. Maybe support 
for normal maps can go into POV 4's suggestion box? Unless it's trivial 
to add to 3.7, I'm guessing not, due to the way normals work (though, 
some normal patterns do have special normal perturbing functions...)

Post a reply to this message

Mike Raiford schrieb:
> A few models I've seen lately have a normal map attached to them, rather 
> than the standard bump map. POV-Ray uses bumpmaps.
> 
> Essentially, a normal map has the x,y,z coordinates in the r,g,b values, 
> rather than grayscale. How hard would it be to implement a normal map 
> such as this, rather than a bump map?

Question is, do those normal maps carry /absolute/ or /relative/ values? 
That is, are these coordinates in true X;Y;Z space (subject only to 
transformations applied to the whole object), or are they rather to be 
interpreted in U;V;N space?

If they carry absolute values, then the whole thing should be as easy as 
eating pancakes (and should actually give better results than POV-Ray's 
current bump mapping implementation).

If they carry relative values, then they should still be about as easy 
to implement as it would be to fix the major flaw of POV-Ray's bump 
mapping implementation.

I wouldn't be all too surprised if both variants were in use out there.


> To further put salt on the wound, the one program out there that seems 
> to be able to translate normal maps into bump maps costs $100 for a 
> non-educational license, pretty high for a piece of software that has 
> such a narrow purpose...

That's probably because while it is darn easy to convert a bump map into 
a normal map, the reverse needs some more math (and may actually be 
impossible in some cases; there are things you can do with a normal map 
that you can't do with a bump map, e.g. an endless slope around a cylinder).

> I need to sit down and write a small app that will do it. Maybe support 
> for normal maps can go into POV 4's suggestion box? Unless it's trivial 
> to add to 3.7, I'm guessing not, due to the way normals work (though, 
> some normal patterns do have special normal perturbing functions...)

Theoretically it shouldn't be much of a problem: Normal maps are just 
another description of how to mangle the geometric surface normal. To 
the contrary, it should actually be even easier: With bump maps, you 
have to first evluate at least three pixels to get the local slope in U- 
and V-direction; with normal maps, you get the same information in a 
single pixel.

The problem here is that POV-Ray doesn't even treat bump maps properly. 
But it shouldn't make a worse job on normal maps either.


(The biggest obstacle might actually turn out to be that the term 
"normal map" is already occupied in POV-Ray for a totally different 
thing ;-))

Post a reply to this message

clipka wrote:

> Question is, do those normal maps carry /absolute/ or /relative/ values? 
> That is, are these coordinates in true X;Y;Z space (subject only to 
> transformations applied to the whole object), or are they rather to be 
> interpreted in U;V;N space?

 From what I've read, and the normal map I have it seems to hold true 
that it is in the U;V;N space,

> If they carry absolute values, then the whole thing should be as easy as 
> eating pancakes (and should actually give better results than POV-Ray's 
> current bump mapping implementation).
> 
> If they carry relative values, then they should still be about as easy 
> to implement as it would be to fix the major flaw of POV-Ray's bump 
> mapping implementation.

On both fronts, this is good to hear :)

> I wouldn't be all too surprised if both variants were in use out there.

That really wouldn't surprise me one bit.

> That's probably because while it is darn easy to convert a bump map into 
> a normal map, the reverse needs some more math (and may actually be 
> impossible in some cases; there are things you can do with a normal map 
> that you can't do with a bump map, e.g. an endless slope around a 
> cylinder).

Right, it requires integration, but the math on that isn't terribly bad, 
just takes a bit of processing power.

>> I need to sit down and write a small app that will do it. Maybe 
>> support for normal maps can go into POV 4's suggestion box? Unless 
>> it's trivial to add to 3.7, I'm guessing not, due to the way normals 
>> work (though, some normal patterns do have special normal perturbing 
>> functions...)
> 
> Theoretically it shouldn't be much of a problem: Normal maps are just 
> another description of how to mangle the geometric surface normal. To 
> the contrary, it should actually be even easier: With bump maps, you 
> have to first evluate at least three pixels to get the local slope in U- 
> and V-direction; with normal maps, you get the same information in a 
> single pixel.

Right. It's rather simple to take the RGB values, and alter the normal 
at the point of ray->surface intersection to get the new normal.

> The problem here is that POV-Ray doesn't even treat bump maps properly. 
> But it shouldn't make a worse job on normal maps either.

I had no idea POV-Ray was handling bump-maps incorrectly. Interesting, 
I've only skimmed the code for POV-Ray, so I wouldn't know... At the 
time, I was more interested in poking around with the root solver code.

> (The biggest obstacle might actually turn out to be that the term 
> "normal map" is already occupied in POV-Ray for a totally different 
> thing ;-))

Yep. Finding an acceptable grammar for the feature would be a problem... 
But it isn't like that hasn't happened before, material_map, for 
instance, doesn't exactly mean what it says.

normal_pattern, much like pigment_pattern, perhaps? Though I can't see 
using basic patterns as a normal map...

Post a reply to this message

Mike Raiford schrieb:
> I had no idea POV-Ray was handling bump-maps incorrectly. Interesting, 
> I've only skimmed the code for POV-Ray, so I wouldn't know... At the 
> time, I was more interested in poking around with the root solver code.

Basically what happens is that POV-Ray calculates the slope components 
of the bump map (U and V), and computes the pertubed normal vector as 
something along the lines of:

   VNormal = VNormal * slopeN + VAxis1 * slopeU + VAxis2 * slopeV;

While this is not fundamentally wrong, the problem is that POV-Ray fails 
to make sure that VAxis1 and VAxis2 match the U and V axes in texture 
coordinate space - it instead basically picks them at random, just 
making sure they are perpendicular to VNormal.

With more or less random normal pertubations like bozo this is not 
really a problem because you won't be able to tell the difference; 
however, if you're using a bump map image with a clearer structure, this 
may cause apparent inside/outside flipping at best - at worst it will 
look as if the light source had been rotated around the geometric 
surface normal; usually this will look noticeably weird, but often not 
noticeably enough to tell exactly /why/.

Post a reply to this message

> Question is, do those normal maps carry /absolute/ or /relative/ values?
> That is, are these coordinates in true X;Y;Z space (subject only to
> transformations applied to the whole object), or are they rather to be
> interpreted in U;V;N space?
>
> If they carry absolute values, then the whole thing should be as easy as
> eating pancakes (and should actually give better results than POV-Ray's
> current bump mapping implementation).
>
> If they carry relative values, then they should still be about as easy
> to implement as it would be to fix the major flaw of POV-Ray's bump
> mapping implementation.
>
> I wouldn't be all too surprised if both variants were in use out there.

From the softwares I use (Blender and 3DS max) The normal map can be UVN mapped.
For animated objects like characters we generally bake it from a high to a lower
polygon count mesh. There is an option to make this normal map use "tangeant
space", and I always leave it on, which allows the shaded point to be moved
from an already moved normal, like a bump on the side of another. If you want a
sample normal from blender, let me know.
Also besides normal maps, Blender 2.5 is implementing a new bump map method with
even better results but I don't know any more than that about it:
http://blenderlabrat.blogspot.com/2009/07/new-bump-mapping.html

> (The biggest obstacle might actually turn out to be that the term
> "normal map" is already occupied in POV-Ray for a totally different
> thing ;-))

I'd be glad to change that to something else for such a feature (Of course my
opinion is of one who has no POV habits yet :))

Post a reply to this message

Mr schrieb:
> Also besides normal maps, Blender 2.5 is implementing a new bump map method with
> even better results but I don't know any more than that about it:
> http://blenderlabrat.blogspot.com/2009/07/new-bump-mapping.html

I have no idea what the difference is supposed to be - aside from the 
"new method" appearing to use a stronger "contrast".

Post a reply to this message

clipka wrote:

> With more or less random normal pertubations like bozo this is not 
> really a problem because you won't be able to tell the difference; 
> however, if you're using a bump map image with a clearer structure, this 
> may cause apparent inside/outside flipping at best - at worst it will 
> look as if the light source had been rotated around the geometric 
> surface normal; usually this will look noticeably weird, but often not 
> noticeably enough to tell exactly /why/.

Ah, this explains why it seems difficult for me to get the bump mapping 
clear on my creature. (I did manage to convert the normal map to a bump 
map, using the program in trial mode...)

Post a reply to this message

Mike Raiford <mraXXXiford.at.@g1023mail.com> wrote:
> clipka wrote:
>
> > With more or less random normal pertubations like bozo this is not
> > really a problem because you won't be able to tell the difference;
> > however, if you're using a bump map image with a clearer structure, this
> > may cause apparent inside/outside flipping at best - at worst it will
> > look as if the light source had been rotated around the geometric
> > surface normal; usually this will look noticeably weird, but often not
> > noticeably enough to tell exactly /why/.
>
> Ah, this explains why it seems difficult for me to get the bump mapping
> clear on my creature. (I did manage to convert the normal map to a bump
> map, using the program in trial mode...)

Bumping in this old discussion to ask if anything has changed about bump maps
implementation, and if any macro or test build can now deal with tangent space
normal maps?

Post a reply to this message

"Mr" <nomail@nomail> wrote:
> Mike Raiford <mraXXXiford.at.@g1023mail.com> wrote:
> > clipka wrote:
> >
> > > With more or less random normal pertubations like bozo this is not
> > > really a problem because you won't be able to tell the difference;
> > > however, if you're using a bump map image with a clearer structure, this
> > > may cause apparent inside/outside flipping at best - at worst it will
> > > look as if the light source had been rotated around the geometric
> > > surface normal; usually this will look noticeably weird, but often not
> > > noticeably enough to tell exactly /why/.
> >
> > Ah, this explains why it seems difficult for me to get the bump mapping
> > clear on my creature. (I did manage to convert the normal map to a bump
> > map, using the program in trial mode...)
>
> Bumping in this old discussion to ask if anything has changed about bump maps
> implementation, and if any macro or test build can now deal with tangent space
> normal maps?

I posted a few references here
http://news.povray.org/povray.general/thread/%3Cweb.4c25107ec23a6d95cc9c68e0%40news.povray.org%3E/?mtop=3

Any idea, anyone?

Post a reply to this message