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
Post a reply to this message
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 =
// 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,
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
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