POV-Ray : Newsgroups : povray.binaries.images : Normals have a directional bias : Re: Normals have a directional bias Server Time15 Jul 2024 07:23:20 EDT (-0400)
 Re: Normals have a directional bias
 From: William F Pokorny Date: 5 Jan 2021 14:07:06 Message: <5ff4b8da\$1@news.povray.org>
```
{
"@context": "https://schema.org",
"@type": "DiscussionForumPosting",
"@id": "#5ff4b8da%241%40news.povray.org",
"headline": "Re: Normals have a directional bias",
"dateCreated": "2021-01-05T19:07:06+00:00",
"datePublished": "2021-01-05T19:07:06+00:00",
"author": {
"@type": "Person",
"name": "William F Pokorny"
}
}
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.
```