William F Pokorny <ano### [at] anonymousorg> wrote:
>
> And attaching one more. It's the previous image, but where I've applied
> 'normal { micro ... }' to the camera too.
>

That is really cool. It looks like the technique could be used as 'sort of' a
substitute for camera blur. And much faster, I assume.

[about the spheres themselves...]
> Most puzzling to me is the upper left sphere where I made the micro
> bump_size large (1.5 I think). It happens once bump_size values get over
> the usual 0.5 limit where normals can start to invert in one or more of
> the x,y,z directions due the perturbation values being so large compared
> to the raw normal values(a).

I didn't know about this inversion problem; I sometimes use a bump_size > 0.5
for the bumps pattern (for example), just to get interesting effects...and in my
camera as well. But I didn't actually stop to notice that the effect of the
normal might not be correct. I guess I need to do some testing.

What is considered a 'raw normal value'? Does it depend on the specific pattern
used?

> The reflections which are there are no longer fuzzy though, which has me
> puzzling. A significant number are pointing away / against the raw
> surface normal sphere rather than mostly being aligned...

I wonder if part of that result might be due to the typical behavior of normals
on a sphere object specifically. It somewhat reminds me of the rather odd
'normal' results obtained when using POV-ray's 'trace' feature, to place objects
on a sphere and to find the surface normal at each point. The objects themselves
are placed correctly-- but the 'handedness' or rotation of each object, based on
the found normal, switch 'alignments' depending on where they are placed on the
sphere. (I'm thinking of the behavior of the Point_At_Trans(...) function when
used as-is to place the traced-on objects, and which 'aligns' them according to
particular quadrants on the sphere surface.)

My own thinking is that a normal at any point on a sphere does not intrinsically
'know' what its handedness should be(?), in order to be consistent over the
entire surface.

This is just a wild guess, of course, and may not have any significance for your
problem.

Post a reply to this message

On 1/26/22 03:19, Kenneth wrote:
> That is really cool. It looks like the technique could be used as 'sort of' a
> substitute for camera blur. And much faster, I assume.
> 

I think so too. Sort of fits with my often liking ray traced / rendered 
results which don't look to be the typical computer generated kind.

An everything out of blur camera - there is no focal plane through which 
the origin and direction are jittered.

Not measured it, but I expect it to be faster, but I often enough get 
surprised. Both blurring approaches are affected by settings which very 
much effect how fast they run - and what ones to pick for a performance 
comparison...

> [about the spheres themselves...]
>> Most puzzling to me is the upper left sphere where I made the micro
>> bump_size large (1.5 I think). It happens once bump_size values get over
>> the usual 0.5 limit where normals can start to invert in one or more of
>> the x,y,z directions due the perturbation values being so large compared
>> to the raw normal values(a).

> I didn't know about this inversion problem; I sometimes use a bump_size > 0.5
> for the bumps pattern (for example), just to get interesting effects...and in my
> camera as well. But I didn't actually stop to notice that the effect of the
> normal might not be correct. I guess I need to do some testing.
> 

Suppose I see normal inversion away from the primary raw surface normal 
as usually a problem, but if not using fancy finish elements maybe OK...

There are partial inversions (perturbation where there is still a 
non-zero dot product with the raw surface normal) which are usually OK.

Inverting a camera's normal might be what you want to do for some effect.

Norbert posted an example of the problem from his "well off people's 
apartment with walls of VERY expensive artwork" image to which I 
responded maybe a a year back. More detail there.

The 0.5 or less is a good rule of thumb, but where you get inversion 
depends primarily on the normal pattern itself and no_bump_scale(a) use.

(a) The behavior of no_bump_scale at some point in POV-Ray's development 
became inconsistent. Certain shapes with certain transform types are 
flattened into a different shape state internally for performance while 
others are not - an action no visible to mere users. In other words, the 
transforms for some shapes are getting flattened to help performance, 
but that transform going away changes the behavior of no_bump_scale...

With povr I've been using the following sort of scene set up to look at 
normals and inversion. Using it I've created the attached image using 
normal bumps and bump sizes of 0.5, 1.0 and 5.5 left to right. Where you 
see red the normal is now perturbed in such a way as to be facing away 
from the camera (be facing into the z plane).

//---
#version unofficial 3.8; // povr
global_settings { assumed_gamma 1 }
#declare VarOrthoMult =
     2.1/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
     orthographic
     location <0,0,-2>
     direction z
     right VarOrthoMult*x*max(1,image_width/image_height)
     up VarOrthoMult*y*max(1,image_height/image_width)
}
#declare White = srgb <1,1,1>;
#declare Red = srgb <1,0,0>;
#declare Green = srgb <0,1,0>;
#declare Blue = srgb <0,0,1>;

#declare Plane00 = plane { -z, 0 }

#declare Nrml00 = normal {
     bumps
     bump_size +5.5
     scale 1/6
}

#declare Txtr00 = texture {
     pigment {
         aoi function_interval
         color_map {
             [-1.0 Red]
             [+0.0 rgb 0]
             [+1.0 Green]
         }
     }
     normal { Nrml00 }
     finish { ambient 1.0 }
}

#declare Obj00 = object {
     Plane00
     texture { Txtr00 }
}

//--- scene ---
     camera { Camera01z }
     object { Obj00 }
//---

> What is considered a 'raw normal value'? Does it depend on the specific pattern
> used?
> 

A raw normal is what the shape or surface itself return's at an 
intersection on shape's surface, or on surface's surface. The final 
direction of which in global space might or might not go through a 
transforms from the local 'object's' space. It's not supposed to have 
anything to do with the 'normal { pattern } being applied, but the raw 
value 'could' be changed by the pattern I guess.

Or a previously perturbed normal could be considered the raw normal for 
a normal pattern coming in a chain of normal patterns after the first. 
This is sort of thing currently sitting as a few types in povr's bevy 
normal pattern collection, but I don't think it happens in official 
POV-Ray code.

>> The reflections which are there are no longer fuzzy though, which has me
>> puzzling. A significant number are pointing away / against the raw
>> surface normal sphere rather than mostly being aligned...

> I wonder if part of that result might be due to the typical behavior of normals
> on a sphere object specifically. It somewhat reminds me of the rather odd
> 'normal' results obtained when using POV-ray's 'trace' feature, to place objects
> on a sphere and to find the surface normal at each point. The objects themselves
> are placed correctly-- but the 'handedness' or rotation of each object, based on
> the found normal, switch 'alignments' depending on where they are placed on the
> sphere. (I'm thinking of the behavior of the Point_At_Trans(...) function when
> used as-is to place the traced-on objects, and which 'aligns' them according to
> particular quadrants on the sphere surface.)
> 
> My own thinking is that a normal at any point on a sphere does not intrinsically
> 'know' what its handedness should be(?), in order to be consistent over the
> entire surface.
> 

My first take is that effect is somewhat different. I think Bald Eagle 
(and Tor Olav ?) posted good explanations after looking at that issue a 
while ago.

> This is just a wild guess, of course, and may not have any significance for your
> problem.
> 

Significance... There is always an itch where I don't understand what I 
see. Half the time it means there is a bug (or bugs) in the code. :-)

Bill P.

Post a reply to this message

Attachments:
Download 'pt5_1pt5_5pt5.jpg' (84 KB)

Preview of image 'pt5_1pt5_5pt5.jpg'

On 2022-01-25 08:55 (-4), William F Pokorny wrote:
> 
> Agree, though, I still don't get what all is happening there to get the
> milky effect. On the overdone sphere - remember I'm testing limits not
> going for any given look. Even the milky effect I found by using bump
> sizes larger than what I think most would / should typically use in
> practice.
> 
> I'm thinking some of the milkiness is coming from getting less overall
> reflection because some of the normals are inverting and some not - some
> we see more of the metallic effect in the result. More of the raw color
> shows through.

I've used bump_size as high as 2, with f_ridged_mf used as a normal,
though not in an attempt at micronormal effects.  I did not see any sign
of normal inversion.

> The reflections which are there are no longer fuzzy though, which has me
> puzzling.

I ran into this issue with my 2020 year-in-review scene.

Post a reply to this message

On 1/26/22 02:29, Kenneth wrote:
> BTW, I find it interesting that the sky_sphere syntax does not accept an actual
> finish{...} block, like...
> 
>       finish{emission rgb <.825,.825,1>}
> 
> .... even though it does accept a pigment{...} block.

There isn't any real surface (no ray -> surface intersection) upon which 
to base finish operations where background or sky_spheres are used.

Bill P.

Post a reply to this message

On 2022-01-26 09:19 (-4), Cousin Ricky wrote:
> On 2022-01-25 08:55 (-4), William F Pokorny wrote:
>>
>> Agree, though, I still don't get what all is happening there to get the
>> milky effect. On the overdone sphere - remember I'm testing limits not
>> going for any given look. Even the milky effect I found by using bump
>> sizes larger than what I think most would / should typically use in
>> practice.
>>
>> [...]
> 
> I've used bump_size as high as 2, with f_ridged_mf used as a normal,
> though not in an attempt at micronormal effects.  I did not see any sign
> of normal inversion.

I just looked back at my images, and though f_ridged_mf() showed no
signs of inversion, f_ridge() most certainly did.  However, I have not
checked to see whether the inversion was due to bump_size.

waves-ridge2.jpg uses f_ridged_mf() bump_size 2.
waves-ridge3.jpg uses f_ridged() bump_size 2.

Post a reply to this message

Attachments:
Download 'waves-ridge2.jpg' (122 KB) Download 'waves-ridge3.jpg' (72 KB)

Preview of image 'waves-ridge2.jpg'

Preview of image 'waves-ridge3.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Significance... There is always an itch where I don't understand what I
> see. Half the time it means there is a bug (or bugs) in the code. :-)

For me, almost always.

Post a reply to this message

On 1/25/22 16:55, William F Pokorny wrote:
> Yeah, that's a thought. I didn't really think about the normal 
> components potentially canceling and going to zero. It could happen, but 
> I'd say not all that often - but maybe there is some clamping or cut 
> offs somewhere in the code that get us to zeroing.
> 
> Using aoi a good thought too! The povr aoi pattern doesn't cut off like 
> the official POV-Ray one does where the normals point away. I made this 
> change so folks can to a degree see any perturbed normal inversions - 
> they can run something to see at what bump_size they have a problem.

OK attached a 'povr aoi' image where the micro bump size is always the 
1.5 I was using for the milky looking result.

The left a z plane more or less as I expect - it's just noisy.

The middle a sphere and again just noise but because of the orthographic 
camera rays in +Z we get more inversion, more read at the edges (nearer 
tangent rays) of the sphere.

The right image is again the plane, but where the color_map is changed 
to show white pixels where they do essentially zero out. There are not 
many cases where this happens.

...So what's going on.

Bill P.

Post a reply to this message

Attachments:
Download 'mircoinversion_1pt5.jpg' (396 KB)

Preview of image 'mircoinversion_1pt5.jpg'

Cousin Ricky <ric### [at] yahoocom> wrote:
>
> waves-ridge3.jpg uses f_ridged() bump_size 2.

*f_ridge

Post a reply to this message

On 1/26/22 08:19, Cousin Ricky wrote:
> I've used bump_size as high as 2, with f_ridged_mf used as a normal,
> though not in an attempt at micronormal effects.  I did not see any sign
> of normal inversion.

Attached an image using, left to right:

function { f_noise3d(x*3, y*3, z*3, 2) }
dump_size 0.5

function { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, -1.0, 3.0, 3.0, 1) }
bump_size 0.5

function { f_ridged_mf(x,y,z, 0.6, 3.0, 6.0, +0.0, 3.0, 3.0, 1) }
bump_size 2.0

So... Whether you get inversion or not depends on LOTS of stuff.

--- More for those interested...

The base shape and the direction of it's normal relative to the incoming 
ray. With functions there is always the possibility the results 
themselves include negative values as shown in the middle case - the 
value base normal code uses those values straight up.

If you wrap everything in normal { pigment_pattern }} as done in far too 
many of the shipped normal examples and images in the documentation, 
you trip a path through the pigment pattern mechanism which - always in 
POV-Ray proper(a) - does a bunch of clipping (a bug for functions ) and 
clamping/wrapping into a 0-1 value range.  Which might still be enough 
to invert normals depending upon the raw normals coming off your surface 
or shape-surface.

(a) - The povr branch has a bunch of code fixes and two new value 
pattern modifiers in function_interval (-1 to +1) and raw_wave (whatever 
  values might come from a function are allowed to be used in maps)

There is in play too, for all the value derived normal perturbations, 
that magic accuracy value. I dislike parts of the current implementation 
because there are magic values / sampling in the underlying code.

Things which can cause a biased normal perturbation and which decouple 
the accuracy value from anything dimension based the user might be able 
to develop a sense for. That accuracy value as specified today is a sort 
of magic with which the user must play pattern to pattern, use to use. I 
think at the very least some new options for less potentially biased 
sampling would be good. Maybe the internal magic values can be exposed 
in some way too - something which lets the user more 'directly' control 
the sampling.

Ah dang, I got on my soapbox... My apologies.

The key bit, is what happens with perturbed normals depends on LOTS of 
stuff.

Bill P.

Post a reply to this message

Attachments:
Download 'f_ridged_mf_nrmlinv.jpg' (180 KB)

Preview of image 'f_ridged_mf_nrmlinv.jpg'

On 1/26/22 08:39, Cousin Ricky wrote:
> On 2022-01-26 09:19 (-4), Cousin Ricky wrote:
>> On 2022-01-25 08:55 (-4), William F Pokorny wrote:
>>>
>>> Agree, though, I still don't get what all is happening there to get the
>>> milky effect. On the overdone sphere - remember I'm testing limits not
>>> going for any given look. Even the milky effect I found by using bump
>>> sizes larger than what I think most would / should typically use in
>>> practice.
>>>
>>> [...]
>>
>> I've used bump_size as high as 2, with f_ridged_mf used as a normal,
>> though not in an attempt at micronormal effects.  I did not see any sign
>> of normal inversion.
> 
> I just looked back at my images, and though f_ridged_mf() showed no
> signs of inversion, f_ridge() most certainly did.  However, I have not
> checked to see whether the inversion was due to bump_size.
> 
> waves-ridge2.jpg uses f_ridged_mf() bump_size 2.
> waves-ridge3.jpg uses f_ridged() bump_size 2.

Ah, you're quicker than me - yeah, what happens in the end depends on a 
lot of variables. :-)

Bill P.

Post a reply to this message