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

Nathan Kopp wrote in message <396802fd@news.povray.org>...
>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,

When used as a pigment, bumps, dents, and bozo all directly call noise3d, so
they are identical.

Mark

Post a reply to this message

In article <39680712@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> When used as a pigment, bumps, dents, and bozo all directly call 
> noise3d, so they are identical.

Not quite...the dents pigment pattern is the result of Noise() cubed. 
The patterns which directly call Noise() and do not modify it are bozo, 
bumps, and spotted.

-- 
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

In article <396802fd@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> 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.

How difficult would it be to have it use the built-in function if no 
slope_map is specified, but to use the second evaluation method if one 
is specified? I don't know that area of the code very well...

-- 
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