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