POV-Ray : Newsgroups : povray.advanced-users : Calculating normals and perturbing them. : Re: Calculating normals and perturbing them. Server Time
28 Nov 2025 04:08:11 EST (-0500)
  Re: Calculating normals and perturbing them.  
From: Bald Eagle
Date: 26 Nov 2025 18:15:00
Message: <web.6927891629c138871f9dae3025979125@news.povray.org>
Cousin Ricky <ric### [at] yahoocom> wrote:

> So far as I understand, the scalar is an offset from the surface, and as
> such, a vector perpendicular to the unperturbed surface is implied.

I mean, that sounds great.
But as far as I am presently aware, POV-Ray enters the Perturb_Normal() function
in normal.cpp with no geometric information other than the "EPoint".
So in what direction do we offset from that point?  The normal?
I believe that the whole reason for using the pyramid vectors is to compute the
normal in the first place so that it can then be perturbed by a vector-valued
function of amplitude bump_size or scale <x, y, z>.

I could very well be missing some key point, which is why I've been digging into
this when I have the time / remember to.

> POV-Ray then computes a normal vector by comparing adjacent
> perturbations, "adjacent" being defined by the 'accuracy' attribute.

It uses the pyramid vectors to define the sampling points offset from the EPoint
by a value "Delta" which Nathan Kopp hard-codes to 0.02.

> I haven't examined the source code, so I could be wrong, but I would
> expect "adjacent" samples to be free from bias, at least from opposite
> directions.

Yes, it's taken me some time, but I believe that the tetrahedral arrangement of
the sample points ensures exactly that, no matter the orientation.

> > I believe one would need to use a spline function, a pigment function, or some
> > other vector-valued function to properly use a function {} in a normal statement
> > to get meaningful if not proper results.
>
> This actually sounds like an excellent way to *introduce* directional
> bias if you're not careful with the function.  ISTR some of POV-Ray's
> built-in normals already have that problem.

But directional bias is exactly how we are creating the normal pattern to begin
with.  If we just multiplied all of the pyramid vectors by a scalar, they would
all cancel out.  Because there's no inherent directional bias.   In order to
"apply a normal" to a surface, we have to introduce some sort of _directional
bias_ in the form of a vector.

That vector comes from the normal pattern functions, and so I think that in
order to create a real and meaningful normal pattern like we think of them, it
needs to be a 3-dimensional vector.  Otherwise, I think that "1" gets
transformed to <1, 1, 1>, "-1" gets transformed to <-1, -1, -1>, etc.

I may or may not get the opportunity to try this, but it would be useful to plot
expected normal scalar values as an overlay, and also render the potential
vector-promoted scalar values to see if they give the same results.

Definitely a lot to be learned here, on several fronts.

- BW


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.