In early January Cousin Ricky posted on the normal mechanism's scalar 
value pattern's normal calculation bias.

http://news.povray.org/povray.binaries.images/thread/%3C5ff4b8da%241%40news.povray.org%3E/

Web Message: 5ff4a6cc$1@news.povray.org

---

There were posts in several newsgroups last fall regarding issues - 
including some positionally bias related - with the quilted normal pattern.

http://news.povray.org/povray.binaries.images/thread/%3C5f830726%40news.povray.org%3E/

Web Message: 5f830726@news.povray.org

---

With this post I want to document a bias issue with the existing 
wrinkles normal block pattern. In the attached image at left a sphere 
with some phong shading. In the middle wrinkles with a bump_size of 0.5. 
The two phong centers should more or less match(a), but do not. On the 
right a hacked version of wrinkles removing the abs() of the DNoise 
returned vector component values.  The phong position and shading has 
spread some, but it's not offset(b).

(a) - Unbiased now too is the overall sphere's shading due the perturbed 
normals.

(b) - The pigment_pattern { wrinkles } looks different, has at identical 
scale and bump_size no noticeable bias - though the scalar value type 
bias is there, and it looks correct for phong position and general shading.

The normal { wrinkles } perturbation's calc creates vector offsets which 
only add to the existing normal vector values. Further, the amount of 
the add/offset depends upon the bump_size value and whether 
no_bump_scale is set or not.

When considered along with transformations it makes textures/materials 
using normal { wrinkles } very difficult to control / set-up for general 
use.

---

Thinking aloud: The misbehavior with wrinkles does suggest an 
interesting idea. One I see as related to those using large bump_size 
values to affect a materials interaction with lighting.

Might we implement a normals pattern which allows users to lean/bend 
normals toward a light source as a new normal block pattern?

Suppose it would be done with a vector specifying a point in space(1) 
with the bump_size then indicating how hard to bend normals toward that 
point(2).

(1) - The point would have to undergo the same inverse transformations 
as rays to be specified in global space I guess.

(2) Hmm, would this need to be done along with (after) other normal 
perturbation patterns are applied. Maybe so...

Bill P.

Post a reply to this message

Attachments:
Download 'nrmlwrnklissue.jpg' (21 KB)

Preview of image 'nrmlwrnklissue.jpg'

> Might we implement a normals pattern which allows users to lean/bend
normals toward a light source as a new normal block pattern?

Sure (?) - would grabbing the light source position and applying the shear_trans
with the normalized inverse position, and using a normal {function {}} (like I
_just_ did for Mike H's fake shadow) not do it?

Add that (normalized) vector to whatever existing normal(s) and then
renormalize?

Post a reply to this message

On 5/5/21 6:22 AM, Bald Eagle wrote:
>> Might we implement a normals pattern which allows users to lean/bend
> normals toward a light source as a new normal block pattern?
> 
> Sure (?) - would grabbing the light source position and applying the shear_trans
> with the normalized inverse position, and using a normal {function {}} (like I
> _just_ did for Mike H's fake shadow) not do it?
> 

A thought, but I'm thinking simpler at the moment. A weighted normalized 
vector addition to the incoming normal in the direction of the point 
light(1).

(1) - Partly because in adding the ability to pass a vector to represent 
the point light, the same 'eventual keyword parsing' could be used to 
specify an arbitrary axis of rotation for other types of normal 
perturbation patterns I have banging around in my head.

> Add that (normalized) vector to whatever existing normal(s) and then
> renormalize?
>

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> A thought, but I'm thinking simpler at the moment. A weighted normalized
> vector addition to the incoming normal in the direction of the point
> light(1).

Yep - that's the revised version that I came up with during lunch, after I
scratched my initial suggestion.

Normalize the normal vector.
Normalize the Light source vector.
Have the normal function take a parameter that gets clamped to 0-1.

Then interpolate over the line segment extending between the actual normal and
the light source based on that parameter.  No angles, no atan2, no matrix
transform.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > A thought, but I'm thinking simpler at the moment. A weighted normalized
> > vector addition to the incoming normal in the direction of the point
> > light(1).

And of course that's vastly easier to do in source, since POV-Ray functions
return scalar values not vectors.
https://wiki.povray.org/content/Reference:Function_Pattern

Maybe there's a clever way to do this in SDL using the color channels and
average {} or some other method...

Post a reply to this message

On 5/5/21 7:00 PM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>>> A thought, but I'm thinking simpler at the moment. A weighted normalized
>>> vector addition to the incoming normal in the direction of the point
>>> light(1).
> 
> And of course that's vastly easier to do in source, since POV-Ray functions
> return scalar values not vectors.
> https://wiki.povray.org/content/Reference:Function_Pattern
> 
> Maybe there's a clever way to do this in SDL using the color channels and
> average {} or some other method...
> 

:-) Re: "vastly easier" - I had the thought, "not with my C++ skills..."

Not useful to most, but as mentioned elsewhere, my povr branch has 
functions packing/unpacking three 21 bit / two 32 bit values into the 
passed around double's 'space'. I think the 21 bit x,y,z enough for most 
normals work.

This works today all in the functional space, but guess we could open up 
2x/3x value paths into the map-pattern and normal pertubation spaces via 
double values. With normal perturbation it more or less directly fits as 
a new perturbation pattern(1), with scalar map pattern's might be 
limited to specific patterns.

I'll have to let that thought cook for a bit. :-)

Bill P.

Post a reply to this message

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?

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.

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{}} ?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> 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?
>
> 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.
>
> 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{}} ?

Yes, you are right; something like that is possible. But patterns can only
return values from 0 to 1, so it must be done with pigments only.

Here's one way of doing it:

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

#include "Gaussian_Blur.inc"

#declare FnX = function { x*z };
#declare FnY = function { y - 0.2 };
#declare FnZ = function { y + z };

#declare Fn = function { FunctionsPigmentRGB(FnX, FnY, FnZ) };

#declare vP = Fn(0.5, 0.6, 0.3);

#debug "\n"
#debug concat("<", vstr(3, vP, ", ", 0, -1), ">")
#debug "\n\n"

#error "Finished"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

For this be be more useful, one can create one or more functions that one wraps
around the FnX, FnY and FnZ functions in order to map their return values into
the 0 to 1 interval and one or more functions that one applies to the returned
components from the Fn vector function in order to map them from the 0 to 1
interval into one or more desired intervals.

IIRC somebody once made some macros that did something like this.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

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.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

Following along in /source/core/material/normal.cpp

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

Seems like (most of) the internal functions and values at play are
EPoint
TPoint
Tnormal
Intersection
Layer_Normal
Warp_Normal ()
Warp_EPoint ()
Pyramid_Vect []



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

const Intersection *Inter


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

Not sure about the accuracy, and not clear why the pyramid is "biased".
I had problems using the internal sum () function, but adding the 4 pyramid
vectors by hand gave me <0, 0, 0> (out to 8 dec places) so I'm not sure what the
bias would be.

Post a reply to this message