On 5/7/21 6:54 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
> Following along in /source/core/material/normal.cpp
> 

As I was thinking aloud I was thinking about what the base normal 
perturbation pattern would see as in normal.cpp and what the base scalar 
value patterns would see in pattern.cpp.

You're right more is available "up the call" chain. I have some code 
partly done adding a new pattern to normal.cpp where I now pass more 
information down to the base pattern. I plan to test the 'pass a 3x 21 
vector' bit as an explicit normal perturbation via a function. We'll see.

Side tracked at the moment on some questions which popped to the surface 
as I worked on the code.

> 
> Not sure about the accuracy, and not clear why the pyramid is "biased".
> I had problems using the internal sum () function, but adding the 4 pyramid
> vectors by hand gave me <0, 0, 0> (out to 8 dec places) so I'm not sure what the
> bias would be.
> 

Bias comes from the fact it's a pyramid of four scalar value evaluations 
about the center intersection point (the evaluation point ie EPoint) and 
not the min of 8 samples (a cube, dual pyramid, dual +, or...) which I 
believe necessary for 'better balanced' sampling(1). The pyramid is 
getting used for performance reasons I'd bet - and maybe we continue to 
use it for this reason(2).

(1) - The reality is there are also biases coming in from shapes on raw 
normal. From isosurfaces, for example, where the raw normals are 
calculated with three + offsets for a 'leaning pyramid' with the EPoint 
at the 'pyramid top'. My belief today is in isosurfaces this is done to 
get the inside/outside surface normals pointing in the right direction 
with respect to the ray/surface intersection (the at zero value), but 
maybe that thinking is off?

(2) - What I've not done is look at how large the bias typically is by 
coding up alternatives and measuring it! A complication is results will 
be affected by the accuracy setting because often during pattern 
perturbations / turbulence the 3D gradients about the EPoint are not at 
all constant.

Bill P.

Post a reply to this message

Following along at:
qtpovray-3.80.1/source/core/material/normal.cpp

> 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 =
dynamic_pointer_cast<SlopeBlendMap>(Tnormal->Blend_Map);

        Warp_Normal(Layer_Normal,Layer_Normal, Tnormal,
                    Test_Flag(Tnormal,DONT_SCALE_BUMPS_FLAG));

        // 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 */
        Warp_EPoint(TPoint,EPoint,Tnormal);

        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];
        }

        UnWarp_Normal(Layer_Normal,Layer_Normal,Tnormal,
                      Test_Flag(Tnormal,DONT_SCALE_BUMPS_FLAG));
    }

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

Hmmm.
Is there a point after that where you have direct access to the intersection /
normal?
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
terse.

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

Post a reply to this message