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

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.

Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.