On 1/25/22 08:39, William F Pokorny wrote:
> I'll look at your idea today and see if I can make something work for povr.

OK.

I spent some time looking at testing whether some keyword is defined. 
It's a tangle.

The short of it is the v4.0 master branch and the povr branch look like 
they can actually do something like:

#ifdef (sphere)

or

#if defined(sphere)

Though you currently get a warning, "...results might not be what you 
expect...", it appears to work in that an option would be to test for a 
povr only keyword say and then run that keyword and have it return povr 
information on versions or whatever.

Unfortunately, it appears this work-ability is part of the later parser 
work clipka was doing. He backed well off those parser updates for the 
v3.8 release. Plus, I fully expect earlier POV-Ray versions do not 
handle testing whether keywords are defined(a).

(a) - Just v3.8 support would have worked for povr as it's strictly a 
v3.8+ branch.

---

The only thing I've come up with, which I think might work, would be for 
povr to re-use a function its currently eliminated in 'f_odd()'.

The function was always useless in that it was, code wise, a duplicate 
of f_cushion. I suspect it was perhaps a place holder for some sort of 
odd / even testing or similar that just never got done.

My thinking is that povr - or any other non-official and substantially 
different - version of POV-Ray could return some unique double value 
given a particular set of inputs. We'd use maybe certain sets of inputs 
for various derivatives. The current inbuilt function would return what 
it returns. The povr branch or others would be hard coded to return some 
other value which would mean something like: This the povr branch and 
the version is, and it's Monday, or...

Would using f_odd() in this way be useful or not? It's all I've got for 
options at the moment.

I kept thinking we need a time machine. Go back to v3.0 and stick in a 
few parser functions which were simply made available to various patch / 
derivative authors to return whatever they wanted for strings and values.

Bill P.

Post a reply to this message

On 1/25/22 16:15, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> 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. Guessing we are
>> hitting some limit where maybe the perturbed normal gets ignored or
>> something except maybe for being inverted. I don't know! I'd have to
>> spend more time in the code to figure it out. The question is rattling
>> around up there in my empty space - maybe the reasons will fully come to me.
> 
> If you have a "+" normal, and a "-" normal of the same magnitude adjacent to one
> another, does the intermediate region get interpolated, and therefore the two
> normals cancel?
> 
> Perhaps if you apply AOI or SLOPE pigment patterns, you can pick up "flat"
> regions on the surface?   Maybe that's somewhere that your RAW thing will help?
> 
> Just guessing.
> 

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.

Any recent POV-Ray release support blend maps with arbitrary negative to 
positive ranges internally. Unfortunately, without changes like those in 
povr, one can't make use of the capability. Something to try.

Bill P.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
>
> running into a different problem with 'povr_6e4ed6c2', the sky_sphere code was
> originally copied from the docs, and the image renders fine with 'beta.2':
>
> File 'o22.pov' line 207:
> Possible Parse Error:
> Unmatched {
> File 'o22.pov' line 217:
> Parse Error:
> No matching }, emission found instead
> Fatal error in parser: Cannot parse input.
> Render failed
>
>
> 206
> 207 sky_sphere {
> 208   pigment {
> 209     gradient y
> 210     color_map {
> 211       [.5 color rgb <.74902,.847059,.847059>]
> 212       [1  color rgb <.258824,.258824,.435294>]
> 213     }
> 214     scale 2.5
> 215     translate -1
> 216   }
> 217   emission rgb <.825,.825,1>
> 218 }
> 219
>

[running v3.8.0 beta 1 in Windows 10]
It parses and renders OK for me as well.

But that example in the docs is a rather strange one, IMO-- only because the
explicitly-given 'emission' color *changes* the color_map's colors.

The docs say that the intended(?) result of the example is this:
"This gives a soft blend from CornflowerBlue at the horizon to MidnightBlue at
the zenith."

But not so; the given emission component values are simple multipliers, and
produce a slightly different color. I have never actually used an explicit
'emission' for a sky_sphere; it's the common understanding that it is set to 1.0
behind-the-scenes as a default (so that the sky_sphere's colors are successfully
used in radiosity, for example).

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.

Post a reply to this message

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'