POV-Ray : Newsgroups : povray.binaries.images : Documenting wrinkles normal pattern bias. v3.7/v3.8. : Re: Documenting wrinkles normal pattern bias. v3.7/v3.8. Server Time12 Jun 2021 18:25:38 EDT (-0400)
 Re: Documenting wrinkles normal pattern bias. v3.7/v3.8.
 From: William F Pokorny Date: 7 May 2021 08:13:15 Message: <60952edb@news.povray.org>
```On 5/6/21 1:46 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>> :-) Re: "vastly easier" - I had the thought, "not with my C++ skills..."
>
> I was stating that from the perspective that such would be "an algorithmic
> process" rather than a function {}.
>
> What you're proposing seems awfully similar to how slope and aoi already work,
> no?  Perhaps there's a way to piggyback on those in SDL, or repurpose that
> already-written source code for the normal perturbation?
>

Me thinking aloud...

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.

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

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.

> Thinking about this some more today reminded me that I am not at all clear about
> how a scalar function perturbs a normal vector.  Maybe this got covered in the
> quilted pattern thread - I will have to look.  It would be nice if this was
> covered in the docs somehow.
>
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.

> It also caused me to wonder if there is a way to define a pattern in SDL that
> has an rgb output, such that the .r .g and .b could be used.  The average {}
> pattern?
> If so, then could we in theory have "vector functions" by rolling 3 pigment
> {function {}} statements into an average{} block, and then using function
> {pigment{}} ?
>

Like Tor Olav, I've played some with this and you can pass vector
information around this way, but I've found it slow. I think it's likely
all you can do in standard POV-Ray releases. The vector interface where
it exists with functions leans on / is tangled with the parser code.

Bill P.
```