William F Pokorny <ano### [at] anonymousorg> wrote:
Following along in /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.
Seems like (most of) the internal functions and values at play are
> 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
> Both scale value patterns and normal perturbation patterns have access
> to all the other pattern settings - the controls, the knobs. Those are
> fixed from parse time.
> What I'm thinking about is 21 bit 3d vectors (in a doubles' space) as a
> function calculated scalar value to a 'special' scalar value pattern.
> One which perturbs the perturbed normal before returning always 0.0 as
> the map value. No new overall mechanism would be needed and this
> 'special' nperturb 'map' pattern would be used as the first pattern in
> an average with a zero weight.
> 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.
const Intersection *Inter
> 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.
> The reason you are perhaps not clear on how it works is the code itself
> has some funky values and scaling in it not documented with comments.
> It's a pyramid of 4 samples (why that type of normal's bias) but why the
> extra stuff I'm not clear. And I wonder too how well the accuracy works
> should the same material be variously scaled in a single scene.
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.
Post a reply to this message