The implementation of bump maps in POV-Ray is broken (well, it was probably
never right in the first place).

A discussion of the symptoms can be found here:
http://news.povray.org/povray.general/thread/%3Cweb.493114d0114da4434dea3830%40news.povray.org%3E/?mtop=291496

I think I just also discovered *why* the bump mapping doesn't work:

The bump_map() function gets three parameters:

- a point in map space
- a structure containing info about the normal "texture"
- a vector identifying the normal at the point

These parameters, however, cannot account for rotations of the bump map around
the (raw) normal axis. This is irrelevant with classic textures, but vital with
bump maps because it makes a difference if the slope is rotated around this
axis.

So there's a conceptual issue here that needs fixing.

There is a similar problem with UV mapping: It is vital for UV-mapped bumps that
the information, which directions correspond to U and V, are passed from the
object to the further processing algorithm.

Post a reply to this message

The problem is that the perturbation of the surface normal by the bump 
normal boils down to a simple VAddScaledEq() call (see normal.cpp), 
which is typical of most renderers.

This is not a true perturbation, though -- the surface normal is not 
being rotated by the bump normal. Because a true rotation takes more 
time, my guess is the approximation using vector addition was done for 
performance reasons (one also doesn't need to worry about the surface 
normal pointing into the object, because adding two up-facing normals 
never produces a downfacing one).

fwiw, I suggest adding true normal perturbation as an option, which 
users can enable at their discretion.

Ray




clipka wrote:
> The implementation of bump maps in POV-Ray is broken (well, it was probably
> never right in the first place).
> 
> A discussion of the symptoms can be found here:
>
http://news.povray.org/povray.general/thread/%3Cweb.493114d0114da4434dea3830%40news.povray.org%3E/?mtop=291496
> 
> I think I just also discovered *why* the bump mapping doesn't work:
> 
> The bump_map() function gets three parameters:
> 
> - a point in map space
> - a structure containing info about the normal "texture"
> - a vector identifying the normal at the point
> 
> These parameters, however, cannot account for rotations of the bump map around
> the (raw) normal axis. This is irrelevant with classic textures, but vital with
> bump maps because it makes a difference if the slope is rotated around this
> axis.
> 
> So there's a conceptual issue here that needs fixing.
> 
> There is a similar problem with UV mapping: It is vital for UV-mapped bumps that
> the information, which directions correspond to U and V, are passed from the
> object to the further processing algorithm.
> 
> 
>

Post a reply to this message