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'