POV-Ray : Newsgroups : povray.binaries.images : Documenting wrinkles normal pattern bias. v3.7/v3.8. : Re: Documenting wrinkles normal pattern bias. v3.7/v3.8. Server Time
22 Mar 2023 17:36:43 EDT (-0400)
  Re: Documenting wrinkles normal pattern bias. v3.7/v3.8.  
From: Bald Eagle
Date: 8 May 2021 09:20:00
Message: <web.60968edfc711449a1f9dae3025979125@news.povray.org>
Following along at:

> Patterns for map use always have access to the raw normal and the
> perturbed normal as part of the ray surface intersection work as well as
> the active involved ray. We calculated a scalar value based upon
> intersection x,y,z. This value calculation can be an inbuilt pattern or
> a function.

Presumably that's this last bit starting at line 873:

        shared_ptr<SlopeBlendMap> slopeMap =

        Warp_Normal(Layer_Normal,Layer_Normal, Tnormal,

        // TODO FIXME - two magic fudge factors
        Amount=Tnormal->Amount * -5.0; /*fudge factor*/
        Amount*=0.02/Tnormal->Delta; /* NK delta */

        /* warp the center point first - this is the last warp */

        for(i=0; i<=3; i++)
            P1 = TPoint + (DBL)Tnormal->Delta * Pyramid_Vect[i]; /* NK delta */
            value1 = Do_Slope_Map(Evaluate_TPat(Tnormal, P1, Intersection, ray,
Thread), slopeMap.get());
            Layer_Normal += (value1*Amount) * Pyramid_Vect[i];


> The normal perturbation patterns are passed the raw normal by reference
> as a vector which is then perturbed before returning to the calling ray
> surface intersection code. The code also has access to intersection
> position.

const TNORMAL *Tnormal, Vector3d& normal, Intersection *Inter

> There are probably ten things wrong with my thinking, but I know one
> issue is the intersection usually comes into the pattern as a constant
> pointer. Meaning with the usual set up I cannot update the perturbed
> normal vector as I'd like to do with the 3x 21 bit encoded function value.

Is there a point after that where you have direct access to the intersection /
Maybe you can do what you want off to the side,in parallel, and set a flag.
Then later in the code, if the flag is set, directly overwrite the
intersection/normal.  I guess it all depends on the order of how things happen
and what state things are in throughout all those steps.

> We've discussed it some about and once in private emails. The "pyramid"
> of scalar value samples and the reason for the accuracy keyword/setting.

Well, I just dug all of that up and looked it over again, and I'm not sure what
the specific evidence is that supports the assertion that a bias exists.  When I
add up all of the vectors in the pyramid, I get a vector sum of <0, 0, 0> out to
8 places.  Whatever those values are (presumably carefully selected pairs of
angles from y : 109.5 deg I'm guessing/approximating) they were carefully chosen
to give a result that is centered at the origin.

I haven't unraveled the code to the point where I can see how a scalar value
gets applied differently to each of those 4 vectors in order to give a net
change in the normal, but following things like pointers, etc can be challenging
esp when the code is written by someone else and the comments are too sparse and

Anyway, here's my visual for the vector pyramid.

Post a reply to this message

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