On 1/5/21 12:50 PM, Cousin Ricky wrote:
> Normals appear to have an inherent directional bias independent of 
> pattern. 
...

This is something I noticed and discussed some privately with Bald Eagle 
while working on the quilted et al normal only patterns.

The method used for creating the normal from scalar function/pattern 
values uses samples (4) and the sampling has a directional bias. This 
bias does not necessarily exist with true normal perturbation. "Normal 
perturbation based upon scalar value functions and patterns have a 
directional bias."

A similar sampling method is used to create isosurface normals but there 
- usually - the code runs at the surface intersection and due the local 
"shape" values the simpler 3 delta sampling mostly works(1).

(1)- There are still possible issues. If the function/shape is set up 
with a constant or near constant value range on one side or the 
transition through the local 0 value root. Where the three axis 
gradients are significantly different or all nearly the same is another. 
If you run f_normal at a local change in value direction off the surface 
- the sphere origin being an example - you tend to get the a form of the 
sampling bias as the normal.

Aside: I have planned a new special pattern called "access" for pulling 
out both the raw and perturbed surface normals (perhaps more) so I can 
look at what is happening with scalar value calculated normal 
perturbation in more detail.

Aside: Related to above I already change povr's aoi pattern to return a 
full -1 to +1 range of values relative to the incoming rays. This lets 
me set up different colors for positive and negative map values so I can 
see by rendered color where perturbed normal inversions happen - where 
the bump value is large enough to flip the primary direction relative 
the incoming ray.

Aside: As you know, the magnitude of the perturbation values play a roll 
too with whether or not raw normals invert in part or in total when 
perturbed.

Aside: A reason povr is dropping scalar value based normal perturbation 
methods where a custom normal perturbation method exists is that, in 
addition to being more flexible, it's much easier to control / prevent 
normal perturbation inversions. This is a move away from v3.5 onward 
normal updates toward how earlier version of POV-Ray worked.

... There are many details with normal handling I still don't 
understand. Warps and those empty code hooks being one bit ...

Bill P.

Post a reply to this message