I hope this is the right place to ask that...

Can someone explain to me how the perturbated normal of a given
point of a surface is calculated ?

I think I uderstood partially, but I miss parts of the
reasoning. AFAIK, the "apparent height" of a point is determined
by the pattern value of the point (0 to 1) and the bump_size.
Now, how do you determine the "apparent" normal at that point ?
Do you have to take the "height" of adjacent points in 
order to determine the slope ?  If so, how much points, and
how far ?

(i'm currently writing a POV-Ray doc in french, and I need
to uderstand this well to explain slope_map clearly)

Thanks,
Fabien.

Post a reply to this message

Fabien Mosen <fab### [at] skynetbe> wrote...
> I hope this is the right place to ask that...
>
> Can someone explain to me how the perturbated normal of a given
> point of a surface is calculated ?
>
> I think I uderstood partially, but I miss parts of the
> reasoning. AFAIK, the "apparent height" of a point is determined
> by the pattern value of the point (0 to 1) and the bump_size.
> Now, how do you determine the "apparent" normal at that point ?
> Do you have to take the "height" of adjacent points in
> order to determine the slope ?  If so, how much points, and
> how far ?

Yes.  When turning a pattern (3d potential function with an output range of
0..1) into a bump map, POV uses a pyramid of four (I think) sample points to
determine the gradient of the function.  This gradient is used to perturb
the surface normal.  The specific details of when and where this pyramid of
sample points is selected differs between POV 3.1 and MegaPov (MegaPov fixes
some bugs).  Also, the perturbed normal at times needs to be transformed
sometimes, too.  The exact algorithm, taking into account layered textures,
averaged textures, and various transformations and warps, is actually rather
complex and difficult to explain, but I hope that this has helped at least a
little bit.

-Nathan

Post a reply to this message

Nathan Kopp wrote:
...
> complex and difficult to explain, but I hope that this has helped at least a
> little bit.

Thank you very much, that's pretty much what I needed.  Also, a 
look at the MegaPOV - better commented - source code was very 
instructive.

Fabien.

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: Yes.  When turning a pattern (3d potential function with an output range of
: 0..1) into a bump map, POV uses a pyramid of four (I think) sample points to
: determine the gradient of the function.

  Wouldn't it be faster to calculate the normal of a (pattern) function using
its derived versions (d/dx, d/dy and d/dz)? This way only three functions
have to be calculated instead of four. If it's a 2D function only two
functions has to be calculated. If it's a 1D function (like gradient), only
one function has to be calculated.
  (Povray doesn't have to calculate the derived functions itself; they are
of course hard-coded as the original functions themselves.)

  Of course it's a bit difficult to calculate the derived of an iterative
function (like mandel), but for some other (non-iterative) functions it
should be possible and even easy.

  Or is this already done this way?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp wrote in message <3964c7c1@news.povray.org>...
>  Wouldn't it be faster to calculate the normal of a (pattern) function
using
>its derived versions (d/dx, d/dy and d/dz)?

I think this is the new normal calculation method used for isosurfaces.
However, it wouldn't be very useful for patterns.  How would you calculate
the derivative of the noise3d function?  Many of the basic patterns use
this, and most of the ones that don't use a special function to calculate
the normal instead of the pyramid method.  Additionally, how would you
handle slope_maps other than the default map?  How would you handle waveform
modifiers?

Mark

Post a reply to this message

Mark Wagner <mar### [at] gtenet> wrote:
: I think this is the new normal calculation method used for isosurfaces.

  Wow! Does megapov have a function derivation routine? Kewl.

: However, it wouldn't be very useful for patterns.  How would you calculate
: the derivative of the noise3d function?  Many of the basic patterns use
: this, and most of the ones that don't use a special function to calculate
: the normal instead of the pyramid method.  Additionally, how would you
: handle slope_maps other than the default map?  How would you handle waveform
: modifiers?

  I'm not sure but I have the feeling that it may not be impossible (nor
difficult) to calculate the correct vector from the function value, it's
default normal and the slope map and waveform. I may be wrong, of course.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote...
>   Wouldn't it be faster to calculate the normal of a (pattern) function
using
> its derived versions (d/dx, d/dy and d/dz)? This way only three functions
> have to be calculated instead of four. If it's a 2D function only two
> functions has to be calculated. If it's a 1D function (like gradient),
only
> one function has to be calculated.
>   (Povray doesn't have to calculate the derived functions itself; they are
> of course hard-coded as the original functions themselves.)

This is already done for bumps, dents, waves, ripples, and wrinkles.  This
is actually why these functions act differently than other functions when
scaled in POV 3.1 (and that is the reason for the "normal bugfix" in
MegaPov).  Also, slope_map appears to be ignored when these normal types are
used, and I think that this is because it's not possible (or at least not
easy) to compute the gradient taking into account the slope_map.

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
: This is already done for bumps, dents, waves, ripples, and wrinkles.  This
: is actually why these functions act differently than other functions when
: scaled in POV 3.1 (and that is the reason for the "normal bugfix" in
: MegaPov).

  Does this mean that MegaPov uses the slower algorithm for these patterns?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <396741d4@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Does this mean that MegaPov uses the slower algorithm for these 
>   patterns?

It uses the method of choosing 4 points and evaluating the pattern at 
each of those points, if that is what you mean. I haven't noticed it 
being any slower...and I think the fact that it works with slope_maps 
and waveforms is enough of a plus to offset any minor speed losses.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote...
> In article <396741d4@news.povray.org>, Warp <war### [at] tagpovrayorg>
> wrote:
>
> >   Does this mean that MegaPov uses the slower algorithm for these
> >   patterns?
>
> It uses the method of choosing 4 points and evaluating the pattern at
> each of those points, if that is what you mean. I haven't noticed it
> being any slower...and I think the fact that it works with slope_maps
> and waveforms is enough of a plus to offset any minor speed losses.
>

Actually, this is incorrect.  For those special normal-only patterns (yes,
there are pigment versions of those patterns, but they internally use a
totally different algorithm when used as a pigment instead of a normal),
MegaPov still uses the already-computed gradient function.  However, MegaPov
fixes some things by applying transformations to the normal where they
should be applied (the official version ignores some of these
transformations and thus can produce incorrect results).  Applying these
transforms has the potential to slow things down a bit, though.  This does
mean that slope_map waveforms still do not work with these special patterns.

You can get slope_map to work with these patterns, though.  How?
1) make a pigment with the pattern that you want to use slope_map with.  Be
aware that this means POV is using a different algorithm to produce the
pattern.  As an example, I'm pretty sure that both bumps and dents use the
bozo pattern when used as pigments, so they will end up looking the same,
even though the normal-only versions of the two patterns look different.
2) use pigment_pattern with that pigment as a basis pattern for the normal
3) use a slope_map on your pigment_pattern

-Nathan

Post a reply to this message