In the last few days I got to creating an official normal block 'micro' 
perturbation only pattern from the initial 'bevy 9' playpen code(a). 
Attaching an image that fell out while testing.

(a) - There is a bug in how the 'x' directions are handled in the 'bevy 
9' shipped with the povr branch tarball back in October. I didn't pick 
it up with my initial test cases...

Bill P.

Post a reply to this message

Attachments:
Download 'microreflectionplay.jpg' (77 KB)

Preview of image 'microreflectionplay.jpg'

Op 23-1-2022 om 12:38 schreef William F Pokorny:
> In the last few days I got to creating an official normal block 'micro' 
> perturbation only pattern from the initial 'bevy 9' playpen code(a). 
> Attaching an image that fell out while testing.
> 
> (a) - There is a bug in how the 'x' directions are handled in the 'bevy 
> 9' shipped with the povr branch tarball back in October. I didn't pick 
> it up with my initial test cases...
> 

Very nice one! More images should "fall out"...


-- 
Thomas

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ... Attaching an image that fell out while testing.

no idea what I'm looking for, or at, but it is "pleasant to behold".  :-)


> (a) - There is a bug in how the 'x' directions are handled in the 'bevy
> 9' shipped with the povr branch tarball back in October.

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


also, I'm currently playing with some code where I frequently use the rtr
feature to get a quick "all-round" look at an object, and it works beautifully.
so good in fact that I'd love to be able to put that preview in a frame in a
frontend, any news on the '-win $id' thing?  :-)


regards, jr.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> In the last few days I got to creating an official normal block 'micro'
> perturbation only pattern from the initial 'bevy 9' playpen code(a).
> Attaching an image that fell out while testing.
>
> (a) - There is a bug in how the 'x' directions are handled in the 'bevy
> 9' shipped with the povr branch tarball back in October. I didn't pick
> it up with my initial test cases...
>
> Bill P.

To me this looks close to just as cute as the cutest cat ! Any chance of such a
feature ever making it to main POV master ?

Post a reply to this message

On 1/23/22 07:49, Thomas de Groot wrote:
> Very nice one! More images should "fall out"...

Thanks! :-)

It's on my todo list to aim more often for more complex images! For 
whatever reason I always drift back into chasing things in the code.

Attached is another test image. The one where I first turned up the 
POV-Ray issue with 'too large for our exr reader' channel values in the 
exr HRDI sky_sphere file.

The three spheres are using different normal 'micro' pattern bump sizes. 
Further the scene uses povr's intensity_max control in both the 
reflection block and with the metallic in the overall finish block. The 
latter keeps all the reflected colors in a 0-1 channel range where the 
AA still works.

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). Where perturbed normal inversions occur, 
the result starts to look more like a milky glass. I don't completely 
understand why...

Bill P.

(a) Only a few of povr's normal patterns prevent such inversions - and 
micro doesn't.

Post a reply to this message

Attachments:
Download 'hmm99_nocam.jpg' (271 KB)

Preview of image 'hmm99_nocam.jpg'

On 1/23/22 10:32, jr 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
> 
> 
> also, I'm currently playing with some code where I frequently use the rtr
> feature to get a quick "all-round" look at an object, and it works beautifully.
> so good in fact that I'd love to be able to put that preview in a frame in a
> frontend, any news on the '-win $id' thing?:-)
> 

Thanks.

In current and future povr releases the sky_sphere emission keyword 
should instead be 'amplify'.

The 'amplify' keyword being a block oriented color multiplier vector in 
povr. These multipliers exist already to some extent under different 
keyword names and where they don't I've been adding them.

Aside: The sky_sphere's 'emission' keyword was always only a color 
vector multiplier. Backgrounds and sky_spheres always emit light in the 
radiosity sense.

No news on the -win id thing. The end of the year was both busy and 
bumpy health wise for me. Truth is I'm mostly only now getting back to 
last work left hanging last October. :-)

Bill P.

Post a reply to this message

On 1/23/22 14:02, Mr wrote:
> To me this looks close to just as cute as the cutest cat ! Any chance of such a
> feature ever making it to main POV master ?

Thanks. A chance I guess should the work be picked up by real POV-Ray 
developers. The micro normal pattern is relatively stand alone.

The big jitter and true random jitter features of povr make 'micro' a 
little more flexible in practice.

All the povr changes are part of the tarball and I consider all my code 
work contributed to the POV-Ray team should they have an interest in any 
of it.

As I move forward with my personal povr branch, my fix and feature 
environment is moving further from the current POV-Ray baseline. Often 
enough now, if a posted problem works for me in povr, but not for those 
in one of the official releases, I find myself unsure why. Unsure what 
combination of changes/fixes make it so.

Bill P.

Post a reply to this message

On 1/24/22 05:51, William F Pokorny wrote:
> Attached is another test image.

And attaching one more. It's the previous image, but where I've applied 
'normal { micro ... }' to the camera too.

Bill P.

Post a reply to this message

Attachments:
Download 'hmm99_cam.jpg' (82 KB)

Preview of image 'hmm99_cam.jpg'

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/23/22 10:32, jr wrote:
> > ...sky_sphere code ...
>
> Thanks.
>
> In current and future povr releases the sky_sphere emission keyword
> should instead be 'amplify'.
>
> The 'amplify' keyword being a block oriented color multiplier vector in
> povr. These multipliers exist already to some extent under different
> keyword names and where they don't I've been adding them.

no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>

which brings me to the next problem, how to write a scene so both 'povr' and the
various POV-Rays are happy?  I had hoped that the version could be used, given
the "unofficial" declaration[*], but cannot see a difference.  asking because I
use a mixture of (shell) aliases + functions and scripts like 'povr' (all
different executables) for the scenes, and ideally the emission/amplify thing
and such would be conditional.  do I have to use self-declared constants?

[*] that too is confusing.  the docs say 'version' is a float, yet in your
scenes you use "#version unofficial 3.8;".  where is stuff like that documented?
 not here:
<https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>


> No news on the -win id thing. The end of the year was both busy and
> bumpy health wise for me. Truth is I'm mostly only now getting back to
> last work left hanging last October. :-)

glad you're "back in the groove".  (I get the feeling that option is not much of
a priority.  :-))


regards, jr.

Post a reply to this message

On 1/24/22 07:36, jr wrote:
> no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
> 

As you know the povr documentation is kinda hit or miss a present - 
partly because I don't want to document while still settling on 
approaches only to need to do the work again.

The new functions as documented in functions.inc are decent, but 
otherwise....

Grepping now I see amplify mentioned some in revisions_povr.txt and 
pretty sure I added notes about it in a posting or two as well.

> which brings me to the next problem, how to write a scene so both 'povr' and the
> various POV-Rays are happy?  I had hoped that the version could be used, given
> the "unofficial" declaration[*], but cannot see a difference.  asking because I
> use a mixture of (shell) aliases + functions and scripts like 'povr' (all
> different executables) for the scenes, and ideally the emission/amplify thing
> and such would be conditional.  do I have to use self-declared constants?
> 
> [*] that too is confusing.  the docs say 'version' is a float, yet in your
> scenes you use "#version unofficial 3.8;".  where is stuff like that documented?
>   not here:
> <https://wiki.povray.org/content/Reference:Numeric_Expressions#Built-in_Variables>
> 

Yeah, it's unfortunately a bit of mess since v3.7. One which clipka 
tried variously to somewhat address.

Writing from memory from earlier last year or late 2020... The 
versioning stuff is something in an awkward state and I have no idea how 
to really fix it.

Ignoring that there was a more complex versioning proposal part of 
uberpov, it was supposed to be we could write something like:

#version unofficial povr 3.8;

where the 'unofficial' keyword would STOP folks running a scene targeted 
for some particular unofficial release in an official release of POV-Ray.

I have no idea why unofficial is not itself documented. It's been there 
a long time. Maybe because there was a worry folks would add it to 
regular POV-Ray scenes or something... I think it should be documented.

My 'assumption' is official window's releases do stop cold on seeing 
'unofficial', but I don't run windows - so I don't know.

The non-windows stuff is compiled by other people whether individuals or 
by package providers. Those releases are ALL unofficial though probably 
today the majority in use. In such releases you only get warnings where 
an unofficial keyword is used. Stopping cold would probably be better 
for at least the distribution provided packages.

The 'povr' or whatever token was supposed to be a hook upon which 
conditional stuff could be done in the SDL. You can still see this form 
of versioning if you look say at:

http://megapov.inetart.net/samples.html

Unfortunately, and guessing some, it seems we at some point (v3.7 ?) 
broke the ability to indicate the branch token and this state of affairs 
exists in many recent official releases of POV-Ray proper...

So, where you see me using only:

#version unofficial 3.8; // povr

in example povr scenes I post or ship, it's because creating a warning 
about the SDL using 'unofficial' is all I can reliably do to warn people 
it's unofficial SDL code for povr.

> 
>> No news on the -win id thing. The end of the year was both busy and
>> bumpy health wise for me. Truth is I'm mostly only now getting back to
>> last work left hanging last October.:-)
> glad you're "back in the groove".  (I get the feeling that option is not much of
> a priority.  :-))

Eh, I don't know. Pretty much all of the pfm rtr frame snap shot 
capability and actual cycle control was done with a -win capability in 
mind. The work just got dropped along with everything else.

Unfortunately it's really painful once you are out of the coding 
"groove" to get back in it. What was I thinking months back? Where did I 
put those files? Oh yeah! They're in that jr_causing_trouble directory. 
:-)

Bill P.

Post a reply to this message

Op 24/01/2022 om 12:31 schreef William F Pokorny:
> On 1/24/22 05:51, William F Pokorny wrote:
>> Attached is another test image.
> 
> And attaching one more. It's the previous image, but where I've applied 
> 'normal { micro ... }' to the camera too.
> 
> Bill P.
> 

Haha! That's Cooky Monster looking back at you!

-- 
Thomas

Post a reply to this message

Op 24/01/2022 om 11:51 schreef William F Pokorny:
> On 1/23/22 07:49, Thomas de Groot wrote:
>> Very nice one! More images should "fall out"...
> 
> Thanks! :-)
> 
> It's on my todo list to aim more often for more complex images! For 
> whatever reason I always drift back into chasing things in the code.
> 
> Attached is another test image. The one where I first turned up the 
> POV-Ray issue with 'too large for our exr reader' channel values in the 
> exr HRDI sky_sphere file.
> 
> The three spheres are using different normal 'micro' pattern bump sizes. 
> Further the scene uses povr's intensity_max control in both the 
> reflection block and with the metallic in the overall finish block. The 
> latter keeps all the reflected colors in a 0-1 channel range where the 
> AA still works.
> 
> 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). Where perturbed normal inversions occur, 
> the result starts to look more like a milky glass. I don't completely 
> understand why...
> 
> Bill P.
> 
> (a) Only a few of povr's normal patterns prevent such inversions - and 
> micro doesn't.

That milky glass effect is quite nice imo, while the lower right sphere 
seems strongly overdone. Food for thoughts... especially the milky glass.

-- 
Thomas

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/24/22 07:36, jr wrote:
> > no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
> ...
> Grepping now I see amplify mentioned some in revisions_povr.txt and
> pretty sure I added notes about it in a posting or two as well.

yeah, my memory..  :-(


> > ..."#version unofficial 3.8;" ...
>
> Yeah, it's unfortunately a bit of mess since v3.7. One which clipka
> tried variously to somewhat address.
>
> Writing from memory from earlier last year or late 2020... The
> versioning stuff is something in an awkward state and I have no idea how
> to really fix it.
>
> Ignoring that there was a more complex versioning proposal part of
> uberpov, it was supposed to be we could write something like:
>
> #version unofficial povr 3.8;
>
> where the 'unofficial' keyword would STOP folks running a scene targeted
> for some particular unofficial release in an official release of POV-Ray.
>
> I have no idea why unofficial is not itself documented. It's been there
> a long time. Maybe because there was a worry folks would add it to
> regular POV-Ray scenes or something... I think it should be documented.

if asked, and if written as above, I'd suggest introducing 'unofficial' as a new
built-in variable which only exists if the keyword was used.  it could contain
the id string, allowing something like:

#if (defined(global.unofficial))
  #if (!strcmp(unofficial,"povr"))
  ...
  #end
#else
  ...
#end

aside - 'povr' emits a warning when I use unofficial, the 'beta.2' simply
ignores it :-).


> >> ... the -win id thing ...
>
> Eh, I don't know. Pretty much all of the pfm rtr frame snap shot
> capability and actual cycle control was done with a -win capability in
> mind. The work just got dropped along with everything else.

have only used the snapshot setting a couple of times, to try.  found that
'convert' works just fine, no need for the "i version" ('file' too recognises
them).

I am hoping that your (+ JG's) work on the X window handling, and the "-win
thing" perhaps, will appear in POV-Ray proper (and before the heat-death of the
universe, ideally :-)  is anyone working on 'beta.3'?).


> Unfortunately it's really painful once you are out of the coding
> "groove" to get back in it. What was I thinking months back? Where did I
> put those files? Oh yeah! They're in that jr_causing_trouble directory.
> :-)

</grin>  (must weigh Gigabytes, by now ;-))


regards, jr.

Post a reply to this message

On 1/25/22 02:14, Thomas de Groot wrote:
> Haha! That's Cooky Monster looking back at you!

:-) Indeed. Those do look like eyes...

Bill P.

Post a reply to this message

On 1/25/22 02:21, Thomas de Groot wrote:
> That milky glass effect is quite nice imo, while the lower right sphere 
> seems strongly overdone. Food for thoughts... especially the milky glass.

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.

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.

I'll attach another image using again the milky effect, but on three 
star mesh include stars. Appropriate given Mike-the-elder was about on 
these newsgroups again recently after years away. His star mesh code / 
and version of it, I've used quite a bit over the years. Anyhow, the 
milky look is a little different than with the spheres I think, the 
environment is different too...

Bill P.

Post a reply to this message

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

Preview of image 'hmm88.jpg'

On 1/25/22 03:37, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 1/24/22 07:36, jr wrote:
>>> no, thank you.  I was sure I'd grep'd the documentation, evidently not.  </sigh>
>> ...
>> Grepping now I see amplify mentioned some in revisions_povr.txt and
>> pretty sure I added notes about it in a posting or two as well.
> 
> yeah, my memory..  :-(

Mine too. With changes like this I have a few places put in parser 
checks which generate more specific errors. For example, reflection now 
supporting only reflection blocks, but it's work and it happened in the 
reflection case mostly because the code was more or less there to do it 
even with a code comment it was the old form and that it was going away. 
It just wasn't generating an error yet though it looked like someone had 
set up to do it at some future point.

I'd like to make the differences easier to handle, but, it really comes 
to not knowing how to do it in the tiny amount of resource I have/want 
to spend on it.

I've been thinking about creating more documentation from the code base 
itself now that I understand it better, but not gotten to trying it.

> 
> 
>>> ..."#version unofficial 3.8;" ...
>>
>> Yeah, it's unfortunately a bit of mess since v3.7. One which clipka
>> tried variously to somewhat address.
>>
>> Writing from memory from earlier last year or late 2020... The
>> versioning stuff is something in an awkward state and I have no idea how
>> to really fix it.
>>
>> Ignoring that there was a more complex versioning proposal part of
>> uberpov, it was supposed to be we could write something like:
>>
>> #version unofficial povr 3.8;
>>
>> where the 'unofficial' keyword would STOP folks running a scene targeted
>> for some particular unofficial release in an official release of POV-Ray.
>>
>> I have no idea why unofficial is not itself documented. It's been there
>> a long time. Maybe because there was a worry folks would add it to
>> regular POV-Ray scenes or something... I think it should be documented.
> 
> if asked, and if written as above, I'd suggest introducing 'unofficial' as a new
> built-in variable which only exists if the keyword was used.  it could contain
> the id string, allowing something like:
> 
> #if (defined(global.unofficial))
>    #if (!strcmp(unofficial,"povr"))
>    ...
>    #end
> #else
>    ...
> #end
> 
> aside - 'povr' emits a warning when I use unofficial, the 'beta.2' simply
> ignores it :-).
> 

Something like that is a good idea. And thanks for reporting the warning 
only being there for povr. It looks like the current v4.0 master code 
has just:

#if POV_RAY_IS_OFFICIAL
         Get_Token();
         Error("This file was created for an unofficial version and\n"
               "cannot work as-is with this official version.");
#else
         // PATCH AUTHORS - you should not enable any extra features
         // unless the 'unofficial' keyword is set in the scene file.
#endif

in Parse_Version(...) where I have a warning in that #else. Maybe 
something I just did at some point? Or maybe I picked up something now 
gone in the official branches? I don't remember...

I just ran an old megapov scene in v3.7 and v3.8 beta1 (my beta 2 
testing was on my raspberry and I'm not on it at the moment). With both 
there parser dies with:

File 'area_light_refl.pov' line 16: Parse Error: Expected 'numeric
expression', undeclared identifier 'megapov' found instead...

which isn't as informative as it could be, but guess I like that the 
parsing dies up front on something that isn't going to work anyway.

I think that Get_Token() in the '...IS_OFFICIAL' branch might be to pick 
up tokens like 'mega_pov' or 'povr' and generate instead the error 
message. Maybe given the existing branches have empty warning branches I 
can just do want I want for povr in the else...

I'll look at your idea today and see if I can make something work for 
povr.

> 
>>>> ... the -win id thing ...
>>
>> Eh, I don't know. Pretty much all of the pfm rtr frame snap shot
>> capability and actual cycle control was done with a -win capability in
>> mind. The work just got dropped along with everything else.
> 
> have only used the snapshot setting a couple of times, to try.  found that
> 'convert' works just fine, no need for the "i version" ('file' too recognises
> them).
> 
> I am hoping that your (+ JG's) work on the X window handling, and the "-win
> thing" perhaps, will appear in POV-Ray proper (and before the heat-death of the
> universe, ideally :-)  is anyone working on 'beta.3'?).
> 

I'm not aware of any v3.8 beta work presently, but the github repository 
wasn't the only one. There exists some more private ones some of which I 
was aware, but I never knew much of anything about those. The developer 
mailing list has been quiet for a while - supposing I'm still connected 
to it and it's working. Some of the windows support always got done 
somewhere else as a dll I think, the documentation too. There is 
somewhere a repository or two for moray code where work seemed to start 
a few times, but then die out. There is active Blender interface work 
some of which is posted about here. All I know.

Bill P.

Post a reply to this message

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.

Post a reply to this message

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'

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

On 2022-01-26 09:39 (-4), Cousin Ricky wrote:
> 
> 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.

The f_ridge() inversion is unrelated to bump_size.

For reference, these are the functions used for the normals:
  f_ridged_mf (x, y, z, 0.1, 3, 7, 0.7, 0.7, 2)
  f_ridge (x, y, z, 0.1, 1, 7, 0.7, 0.7, 0)

Note: The scene file was written for POV-Ray 3.6; the last argument to
f_ridge() should be changed to 2 for 3.7+ compatibility.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.

how .. unexpected..  :-)


> ...
> 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()'.
> ...
> 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.

unsure.  a function return to test against would not be very different from
comparing string ids, and it sounds like it would work.  otoh, it feels like,
um, a crutch.  (sorry)  perhaps an effort ought to be made to get clipka
involved, to see how/when the parser gets taken forward from here.


regards, jr.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> [running v3.8.0 beta 1 in Windows 10]
> It parses and renders OK for me as well.

yeah, my bad.  'povr's syntax is different, and I had not caught on.


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

"common understanding"?!  :-)  apart from a simple scene I'm hoping to complete
in the next days, I have never used a sky_sphere, so thanks for the
"background".


regards, jr.

Post a reply to this message

On 1/26/22 10:03, Cousin Ricky wrote:
> On 2022-01-26 09:39 (-4), Cousin Ricky wrote:
>>
>> 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.
> 
> The f_ridge() inversion is unrelated to bump_size.
> 
> For reference, these are the functions used for the normals:
>    f_ridged_mf (x, y, z, 0.1, 3, 7, 0.7, 0.7, 2)
>    f_ridge (x, y, z, 0.1, 1, 7, 0.7, 0.7, 0)
> 
> Note: The scene file was written for POV-Ray 3.6; the last argument to
> f_ridge() should be changed to 2 for 3.7+ compatibility.

Hmm.

Maybe this just a difference between the official POV-Ray functions and 
mine, but in the current povr code for f_ridge() those arguments will 
more or less return little because the first three to f_ridge are 
basically arguments to POV-Ray's internal turbulence function (Noise).

Meaning those after x,y,z are lambda, octaves, omega. A workable result 
for povr would be:

f_ridge(x, y, z, 2.5, 3, 0.5, -0.5, +0.05, 3, 1)

I added a last multiplier/scaling argument to the f_ridge* functions 
povr because results often gets scaled and this is done faster internal 
to the function than outside. At 1.0 no scaling happens.

Bill P.

Post a reply to this message

On 1/26/22 11:25, jr wrote:
>> Would using f_odd() in this way be useful or not? It's all I've got for
>> options at the moment.
 >>
> unsure.  a function return to test against would not be very different from
> comparing string ids, and it sounds like it would work.  otoh, it feels like,
> um, a crutch.

I've been thinking about this.

Instead of using f_odd() to return additional patch/branch information, 
I think it should instead return always a value f_odd() cannot. For 
example, 99.0(a).

The 99 indicates the code contains a patch or is a significant branch of 
its own. Further, that two additional parse time functions exist in:

patch_str(<n>) and patch_val(<n>)

With this approach we use f_odd() as a hook into all versions of POV-Ray 
back through v3.5(c) to indicate the two patch_* keywords exist.

What each branch/patch provider does with those is up to them both to 
implement and document to their users.

Allowing any number of strings and values would allow documenting 
particular functionality and the version of that functionality -> 
"amplify" 0.003.

Is this a better approach(b) than f_odd alone?

It's gets us away from any dependency POV-Ray's official development.


Aside: I had the thought too for a patch_keyword("sky_sphere"). Which 
might return say "unchanged". Or "emission sub keyword is now amplify" 
or "removed" or "new" or "substantially updated see povr documentation" 
or... I'm thinking more about code which self documents to some minimal 
degree.


Bill P.

(a) - It happens the return of f_odd (and its twin f_cushion) are 
clamped to a -10 to 10 range.

(b) - With official POV-Ray there's been significant effort to maintain 
near infinite backward capability so old scenes and tooling writing 
POV-Ray SDL continue to work.

A place and value for this approach, but it doesn't come free. The 
reality is a fair bit of the backward capability is bent if not broken 
to what is documented. To the degree it's tested due old scene and 
include files, it's probably workable.

It's much harder to write significant patches if you have to worry 
yourself about maintaining infinite backward capability. My povr branch 
supports only v3.8+. So as a patch_* return pair I might also have:

"Minimum POV-Ray version" 3.8

If v4.0 development resumes, there will be a point where I won't be able 
to retrofit some v4.0 change / feature to povr and I'd then need maybe:

"The povr branch is aligned with POV-Ray version" 3.8

(c) - I'm only aware of patched versions back through v3.6.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Instead of using f_odd() to return additional patch/branch information,
> I think it should instead return always a value f_odd() cannot. For
> example, 99.0(a).
>
> The 99 indicates the code contains a patch or is a significant branch of
> its own. Further, that two additional parse time functions exist in:
>
> patch_str(<n>) and patch_val(<n>)
>
> With this approach we use f_odd() as a hook into all versions of POV-Ray
> back through v3.5(c) to indicate the two patch_* keywords exist.
>
> What each branch/patch provider does with those is up to them both to
> implement and document to their users.
>
> Allowing any number of strings and values would allow documenting
> particular functionality and the version of that functionality ->
> "amplify" 0.003.
>
> Is this a better approach(b) than f_odd alone?
>
> It's gets us away from any dependency POV-Ray's official development.

gut reaction[*] - yes, something along that line.  while compatibility is
important of course, I think that this mechanism is of value only from current
versions on.  not quite sure I really understand the detail, so I'd write eg:

#if (99 = f_odd(0,0,0,99))
  #if (!strcmp(patch_val("id"),"povr"))
    ...
  #end
#else
  ...
#end

where/how does 'patch_str' get used?

from my admittedly limited vantage I see no downsides, other than that
'functions.inc' (presumably) would need to be sourced.

[*] also .. pleasing that a function with that exact name should get shouldered
with this odd job.  :-)

((real) minor nit, suggest 'fork', or perhaps even 'branch', rather than
'patch')


> Aside: I had the thought too for a patch_keyword("sky_sphere"). Which
> might return say "unchanged". Or "emission sub keyword is now amplify"
> or "removed" or "new" or "substantially updated see povr documentation"
> or... I'm thinking more about code which self documents to some minimal
> degree.

a macro to return a 'dictionary{}' would be real nice.  could have keys for the
changed stuff ("amplify") as well as version/patch level, everything in one
place.  :-)


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > ...
> > Instead of using f_odd() to return additional patch/branch information,
> > I think it should instead return always a value f_odd() cannot. For
> > example, 99.0(a).

> a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> changed stuff ("amplify") as well as version/patch level, everything in one
> place.  :-)
>
>
> regards, jr.

Aside, or perhaps in addition to, what can be done under the hood,

what if the versioning mechanism not only has internal functions, but checks for
the existence of "versions.inc" in the path?  Preferably this would be a
"wrapper" inc file that then looks for the most recent "versions_DateCode.inc"
to use...

That would allow all manner of code to be run based upon the values returned by
the internal function(s), either in addition to, or instead of the "default"
behaviour.

Also, the output for any given version could be easily updated by people in the
absence of any official developer presence / availability / activity.

Also, I would suggest a way to implement Semantic Versioning, so that all the
little changes that get made along the way can be documented.
Maybe a 9-digit number XXXYYYZZZ.

Just thinking about long-term expandability and making the capabilities
available NOW.

Post a reply to this message

On 1/27/22 10:54, jr wrote:

jr & Bald Eagle, Thanks both for the feedback and ideas.

> gut reaction[*] - yes, something along that line.  while compatibility is
> important of course, I think that this mechanism is of value only from current
> versions on.  not quite sure I really understand the detail, so I'd write eg:
> 
> #if (99 = f_odd(0,0,0,99))
>    #if (!strcmp(patch_val("id"),"povr"))
>      ...
>    #end
> #else
>    ...
> #end
> 
> where/how does 'patch_str' get used?

What I was thinking about was more like:

#declare povr     =  0;
#declare povr_ver = -1;
#if (99 = f_odd(0,0,0,99))
     #if (!strcmp(patch_str(0),"povr"))
         #declare povr = 1;
         #declare povr_ver = patch_val(0);
     #end
#else
   ...
#end

The patch_str() and patch_val() would be paired by count. I am leaning 
this way because the parser is set up for keywords to always be of one 
type.

Having the pair makes it easy to set up a loop to pull more than one key 
value pair aimed at creating, say, a table.

Using a count for access, I believe, will make it a little less likely 
users will get the feature tangled up on string specification or 
interpretation.

Though, nothing would stop any given branch developer from setting up to 
pull values out of returned strings in the SDL - if that's the set up 
they want.

> 
> from my admittedly limited vantage I see no downsides, other than that
> 'functions.inc' (presumably) would need to be sourced.
> 
> [*] also .. pleasing that a function with that exact name should get shouldered
> with this odd job.:-)

Indeed! :-)

Yes, including functions.inc is a bit clunky and it touches on the 
parser performance issue I was trying to address somewhat with my 
'munctions' (macro call defined functions) idea - a little work toward 
which showed up in my last release.

True to some degree for any include, but when we pull in functions.inc 
in particular we define upwards of one hundred symbols in a symbol 
table. These can and do collide by hash value(a) which slows down 
functions at RUN time as well as slowing general parsing at parse time.

We only include functions.inc to declare - create global symbol table 
entries - for each inbuilt function name. For f_odd we could, and 
probably should, use(b) just:

#declare f_odd = function { internal(43) }

ahead of the call to f_odd.

This selective declaration of inbuilt functions has always been 
recommended against because the positional values in the internal 
function table might change. True, but, they haven't actually changed in 
a very, very long time - until povr really. There has always been a 
performance reason to do the declares for only the functions in 
functions.inc you use(c).

(a) - This especially true in official POV-Ray where the hashing 
mechanism, though itself very fast, generates hash values heavily 
weighted / bunched around the first token character. The povr branch 
uses a C++ provided string hashing with very good hash value 
distribution - even where strings are quite similar (Fn00,Fn01...). The 
C++ method was slower at low optimizations and faster at -O2 and above 
for the testing done at the time I changed over.

(b) In povr, I'm using entry 43 for f_elliptical_sphrswp() and I will 
have to move f_elliptical_sphrswp() elsewhere.

(c) Though, with hash based symbol/token tables with linked lists 
hanging off each node, whether you see any a performance gain depends on 
the particular symbol table construction. Having fewer symbols/tokens 
will never hurt performance, but it can help quite a lot - depending on 
'stuff.'

> 
> ((real) minor nit, suggest 'fork', or perhaps even 'branch', rather than
> 'patch')
> 

Good idea and I guess in the git sense, fork, the better choice because 
in the usual practice there will often be branch(es) off major forks for 
particular features of the fork. Any branches we should probably handle 
as additional _str and _val entries.

> 
>> Aside: I had the thought too for a patch_keyword("sky_sphere"). Which
>> might return say "unchanged". Or "emission sub keyword is now amplify"
>> or "removed" or "new" or "substantially updated see povr documentation"
>> or... I'm thinking more about code which self documents to some minimal
>> degree.
> a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> changed stuff ("amplify") as well as version/patch level, everything in one
> place.:-)

Yes, good idea. Putting more in include(s) that creates a dictionary for 
such information would be better / easier. The include could itself 
could test the forked version / branch of POV-Ray matches its internal 
information. Hmm, we could create csv file(s) and use table.inc though 
guess I'm not sure if more or less work/value over just creating the 
dictionary straight up?

On automatically including includes, I lean against it. How external 
files get searched for and found is today problematic. I've been trying 
to simplify the povr fork directory search mechanism. Still a long way 
to go there and might have some current changes wrong. Official 
POV-Ray's matching attempts are very aggressive in assuming various 
directories, file suffixes and such. I think this causes as much 
confusion as not in the end.

On versioning... Following some conventions there a good idea, but not 
sure it's something to force as part of any f_odd, fork_*() additions.

For someone actually implementing a one off patch, it's meaningless. I 
have to say too, as a long time user of such versioned tools, I've found 
them not all that reliable - except in maybe the ZZZ minor update 
category (small updates to still compile essentially static releases).

Some systems extend the versioning to components / modules / features of 
the overall 'user tool' - some allowing the user to pick the version of 
behavior for each module. This 'idea' somewhat attractive given the more 
aggressive changes I'm pursuing with povr.

For example, I substantially re-wrote 'fog' a year or more ago. One of 
the changes was making ground fog work more reliably - it basically, 
doesn't function for most scenes in official releases. Last fall I ran 
across an old scene that depended upon the particulars of the previous 
method to do a sort of fog fade at a large distance. It was a use I 
didn't foresee for 'ground fog', so I restored the old method as an 
additional option. There are now two versions of my povr fog code.

Maintaining this per feature versioning is something I think works 
better where a coder is working on say only a few of modules for a 
larger project/tool. I don't have the bandwidth to support anything 
complicated like maintaining multiple user select-able versions, but I 
might be able to increment some version number per keyword to at least 
indicate something changed related to the keyword/option.

I'll think more about what to do versioning wise, what I might be able 
to maintain...

Bill P.

Post a reply to this message

hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> > > ...
> > > Instead of using f_odd() to return additional patch/branch information,
> > > I think it should instead return always a value f_odd() cannot. For
> > > example, 99.0(a).
>
> > a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> > changed stuff ("amplify") as well as version/patch level, everything in one
> > place.  :-)
> >
> Aside, or perhaps in addition to, what can be done under the hood,
>
> what if the versioning mechanism not only has internal functions, but checks for
> the existence of "versions.inc" in the path?  Preferably this would be a
> "wrapper" inc file that then looks for the most recent "versions_DateCode.inc"
> to use...

nice.  made me think there isn't a 'version.inc' yet, so, perhaps, one could be
added to all POV-Rays and variants[*].  standard .inc, only providing a macro or
variable that's true/false depending on whether official or not, and a way to
get info about which executable.  a variant like 'povr' or 'hgpovray' could then
simply add an '#include' in that file to load the specific stuff.  (_if only_
more/most of the code was in 'C'.  anyway :-))


[*] from 3.9 on, perhaps :-)

regards, jr.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/27/22 10:54, jr wrote:
> > where/how does 'patch_str' get used?
>
> What I was thinking about was more like:
>
> #declare povr     =  0;
> #declare povr_ver = -1;
> #if (99 = f_odd(0,0,0,99))
>      #if (!strcmp(patch_str(0),"povr"))
>          #declare povr = 1;
>          #declare povr_ver = patch_val(0);
>      #end
> #else
>    ...
> #end
>
> The patch_str() and patch_val() would be paired by count. I am leaning
> this way because the parser is set up for keywords to always be of one
> type.
>
> Having the pair makes it easy to set up a loop to pull more than one key
> value pair aimed at creating, say, a table.

ok, key/value pairs.  thanks for code example (I find "snippets" helpful).  re
my earlier post, that testing and the "cloaking" of 'internal(43)' hidden,
perhaps, behind a "friendlier" bool macro/variable.


> ...
> >
> > from my admittedly limited vantage I see no downsides, other than that
> > 'functions.inc' (presumably) would need to be sourced.
> >
> > [*] also .. pleasing that a function with that exact name should get shouldered
> > with this odd job.:-)
>
> Indeed! :-)

what was its original purpose?  reading that the argument is a "field strength"
made me wonder whether it's anything to do with 'blob's.


> ...
> We only include functions.inc to declare - create global symbol table
> entries - for each inbuilt function name. For f_odd we could, and
> probably should, use(b) just:
>
> #declare f_odd = function { internal(43) }
>
> ahead of the call to f_odd.

that could/would be the content of a 'version.inc'.


> ...
> > a macro to return a 'dictionary{}' would be real nice.  could have keys for the
> > changed stuff ("amplify") as well as version/patch level, everything in one
> > place.:-)
>
> Yes, good idea. Putting more in include(s) that creates a dictionary for
> such information would be better / easier. The include could itself
> could test the forked version / branch of POV-Ray matches its internal
> information. Hmm, we could create csv file(s) and use table.inc though
> guess I'm not sure if more or less work/value over just creating the
> dictionary straight up?

'table.inc'?  :-)  guess you were thinking 'filed.inc'?  what do you think of a
'version.inc' which, for variants like 'povr', would simply pull in another
include if/where required?


> On automatically including includes, I lean against it.

v much agree.


> ...
> Maintaining this per feature versioning is something I think works
> better where a coder is working on say only a few of modules for a
> larger project/tool. I don't have the bandwidth to support anything
> complicated like maintaining multiple user select-able versions, but I
> might be able to increment some version number per keyword to at least
> indicate something changed related to the keyword/option.
>
> I'll think more about what to do versioning wise, what I might be able
> to maintain...

fwiw, I do not think that it has to be very .. fine-grained, necessarily.  as
long as a user me can establish, in-scene, that the executable supports this
feature or another as easy to use (in conditionals) test(s).


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:
> ...
> ok, key/value pairs.  thanks for code example (I find "snippets" helpful).  re
> my earlier post, that testing and the "cloaking" of 'internal(43)' hidden,
> perhaps, behind a "friendlier" bool macro/variable.
> ...
> that could/would be the content of a 'version.inc'.

have attached a mock-up example of an inc for POV-Ray proper.  the tag would
just change to 'povr', and either inline or via an include have the specific
stuff, and I think, the 'setidtypes.inc' content too.


> > ...
> > > a macro to return a 'dictionary{}' would be real nice.
> >  ...
> > information. Hmm, we could create csv file(s) and use table.inc though
> > guess I'm not sure if more or less work/value over just creating the
> > dictionary straight up?
>
> 'table.inc'?  :-)  guess you were thinking 'filed.inc'?  what do you think of a
> 'version.inc' which, for variants like 'povr', would simply pull in another
> include if/where required?

forgot.  dictionary, "straight up".


regards, jr.

Post a reply to this message

Attachments:
Download 'eg.zip' (1 KB)

On 1/26/22 09:01, William F Pokorny wrote:
> ...So what's going on.

Well, after digging for a chunk of day, the non-fuzzy result comes from 
a "bug fix" made back in 1998 by Nathan Kopp & CEY in the 
Trace::ComputeReflection() function of trace.cpp.

Basically after the calculation of the reflected ray direction using the 
perturbed normal, they added second dot test of that perturbed reflected 
ray with the raw surface normal.

If the perturbed reflected ray was heading in a direction opposite the 
the raw surface normal it triggers some code which does one of two kinds 
of correction...

Where the perturbed ray direction is opposite the perturbed normal 
direction it simply drops back to reflection rays based on the raw 
normal.  This is where we suddenly get non-normal-perturbed 
reflections...

Otherwise, it pulls the perturbed reflected ray more into alignment with 
the raw surface normal by an amount based upon a negative weighting 
factor and the magnitude of the dot product of the perturb ray direction 
with the raw normal to some degree being stronger up to a cut off set by 
the initial test with the perturbed normal(a).

After all the fix up the reflected ray direction is normalized - which 
is the expected ray direction state.

Ah, what to do... Thoughts anyone? I'm going to have to think about this.

I don't like that we are basically ignoring perturbed results to some 
degree or another - for reflections - beyond certain normal 
perturbations point.

With very rough surfaces - think pile of stones - a reasonable 
expectation would be to get some degree of all internal reflections. A 
darkening due reflections bouncing until they die off inside the surface 
structure. This feels like a more correct result to me.

Guess I need to check whether this bug fix is getting done with 
refraction too...

Bill P.

(a) - Yep, this second fix/pull toward the raw surface normal might not 
always set in a non-opposing direction with the raw surface normal.

(a) Yes, I think this is going to also create some extra 
fuzz/inaccuracies for fresnel effects at glancing angles at near 
tangents to a surface. There, with certain rougher surfaces, we should 
see around the complete 'larger-overall' tangent some.

Post a reply to this message

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

> Ah, what to do... Thoughts anyone? I'm going to have to think about this.
>
> I don't like that we are basically ignoring perturbed results to some
> degree or another - for reflections - beyond certain normal
> perturbations point.


Whoa - interesting result of your day of code forensics!

I would tend to start from scratch, and just cancel all of that extra stuff and
see what happens.   Maybe it might explain why they decided to do all of that.

I tend to learn how to approach these types of things by going out and seeing
how various people address them outside of POV-Ray - in Unity, ShaderToy,
academic papers, and other linear algebra / computer graphics / optics / math
resources like websites and video hosting sites.

https://www.youtube.com/watch?v=EBrAdahFtuo

I would try to make a diagram, or write a scene where you have actual objects,
and shoot rays every so often, and show the incoming ray, and then whatever
reflected rays that get generated.   Maybe iterate a color change around the HSV
wheel or something to track how far along the process you are.

Seeing the process and results usually gives far more intuitive understanding of
what the problem is and what the likely solution is, than scribbling equations
and endlessly editing lines of code.

That's my take, anyway.

Post a reply to this message

[William P wrote:]
>
> With povr I've been using the following sort of scene set up to look at
> normals and inversion...
> //---
> #version unofficial 3.8; // povr
> global_settings { assumed_gamma 1 }
> #declare VarOrthoMult = ...
> [...snip]

[JR wrote:]
>
> have attached a mock-up example of an inc for POV-Ray proper.  the tag would
> just change to 'povr', and either inline or via an include have the specific
> stuff, and I think, the 'setidtypes.inc' content too.
>

[running v3.8.0 beta 1 in Windows]
I did not even know that there is an 'unofficial' keyword in POV-ray syntax; it
is not mentioned in 3.8's in-built documentation (at least not in the index of
keywords there). Interesting!

So, running JR's very neat little test scene (with his .inc file) like this:

#version 3.8; // no 'unofficial' keyword
global_settings {assumed_gamma 1}
box {0,1}
#include "version_test.inc"
#if (official_program())
#debug concat("prog is an official POV-Ray.\n")
#else
#debug concat("not an official POV-Ray.\n")
#end
#debug concat("ident: \"",idtag_program,"\".\n")

...... it parses and render fine, with the appropriate message.

But if I run it like this:

#version unofficial 3.8;
......

...... the scene fails outright, with the message
"line 1: Parse error: This scene was created for an unofficial version and
cannot work as-is with this official version."

I'm very naive about this stuff-- but is it to be expected that this
'unofficial' file should also run OK, and even in my Windows version of 3.8
(i.e., a non-"povr" version?) If not, then... never mind ;-) My apologies if I'm
simply "muddying the waters" of this discussion, but I thought I should mention
the parse error.

Post a reply to this message

On 1/28/22 17:01, Bald Eagle wrote:
> I would tend to start from scratch, and just cancel all of that extra stuff and
> see what happens. Maybe it might explain why they decided to do all of that.

A look at the basics is good advice.

I did get to commenting all the fix bugfix code and got results more in 
line with what I originally expected. As of this morning I'm leaning 
toward bringing out various treatments as user controllable variations. 
  I can see physical reasons for a few depending upon the actual surface 
and the non-perturbed rays. Given that glassy result is probably useful 
would likely keep it as perhaps an expanded option. Suppose keeping the 
current behavior as an option a good idea too.

Likely the povr default would be no bugfix / adjustments at all as I 
think it the result most would expect. I also like the look of it over 
the current for usual use 'micro' micro results.


This morning been looking at the refracted side of things.

A simplified view:
------------------

Where the perturbed normal is running along with (inverted with respect 
to the incoming ray) the perturbed normal is inverted and assigned a 
local normal for color calculations.

Where the refracted ray ends in internal reflection the perturbed normal 
is used and the compute reflection bugfix gets used as with any other 
reflection.

Where the refracted ray continues creating a new refracted ray the, 
always pointing back toward the ray, normals - the potentially inverted 
local normals - get used

So! The refraction behavior isn't really aligned with reflection 
behavior at any given surface intersection where the perturbed normals 
point in opposition to the refracted/reflected rays. In the case of 
reflections sometimes if in enough conflict with the raw normal.

A realization for me is, while it's possible in some cases to prevent 
the inversion of perturbed normals with respect to the major surface 
direction with some patterns, it is not possible to do in general 
because there are really two kinds of perturbed normal inversion. One 
with respect to the surface itself, and another with respect to the rays 
involved.

That said, a common to all normal patterns, perturbed normal inversion 
option for where the perturbed normal points away from the raw normal 
might be of use... This would immediately get us to a state where there 
are only the inversions with respect to involved rays issues.

---
I guess a take away here for POV-Ray proper is where you are using 
reflection or refraction, keep the normal bump size smallish (<0.5). 
Even so, where rays nearly tangent to the surface, ANY normal 
perturbations will invert somewhat at those locations with respect to 
incoming rays.

I suppose what can be said generally is the moment we start to fake 
surfaces / shapes to some degree or another, the reflections and 
refraction treatments necessarily get somewhat heuristic.

Bill P.

Post a reply to this message

On 1/29/22 05:07, Kenneth wrote:
> ut if I run it like this:
> 
> #version unofficial 3.8;
> ......
> 
> ...... the scene fails outright, with the message
> "line 1: Parse error: This scene was created for an unofficial version and
> cannot work as-is with this official version."

Thanks! Stopping with this error is what I expected for "official" 
windows versions. This means if we want to write SDL supporting both 
normal POV-Ray releases and forks for windows users, we'd need to strip 
"unofficial" from #version.

Thanks jr, for the initial versions.inc template. Yes, such an include 
could be provided with code. However, we'd need to be careful about 
'declaring' any version of POV-Ray to be an official one. Today ONLY the 
pre-compiled windows releases are official.

Hmm, suppose we could extend this code to optionally end with an #error 
if the desired hook or fork is not found for SDL written specifically 
for a particular fork.

 > what was (f_odd's) original purpose?  reading that the argument is
 > a "field strength" made me wonder whether it's anything to do
 > with 'blob's.

I don't know, I think it was likely some unfinished effort where some 
initial code got copied. Code wise it was always a match for f_cushion() 
and so pointless as shipped.

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Thanks jr, for the initial versions.inc template. Yes, such an include
> could be provided with code. However, we'd need to be careful about
> 'declaring' any version of POV-Ray to be an official one. Today ONLY the
> pre-compiled windows releases are official.

made me think what is John/Jane User's perspective?  if they only ever use
official builds on MS Windows, then "the problems" do not arise.  if however
they write scenes which will get parsed by POV-Ray proper or a variant, then
they can source the include.  I think one can simply "turn the logic around"[*]
without harm, ie name the macro 'unofficial_program' + reverse its result.  then
we could write an even simpler conditional:

  #if (unofficial_program())
    ...
  #end

[*] assuming POV-Ray proper will continue to return clamped values + everybody
else switches to '99'.


> Hmm, suppose we could extend this code to optionally end with an #error
> if the desired hook or fork is not found for SDL written specifically
> for a particular fork.

re error, sorry snipped too much.  just to confirm, unlike on Windows, the
self-compiled POV-Rays all accept "unofficial" w/out a murmur.  while I can see
the logic, it feels wrong - now.  we're 2nd class users anyway, with RTR not
working :-(.

on the point, if I test in a scene for '6e4ed6c2' (:-)) but the executable is
older/newer/not compatible and won't do, then yes, I think it has to be an
error.


>  > what was (f_odd's) original purpose?  reading that the argument is
>  > a "field strength" made me wonder whether it's anything to do
>  > with 'blob's.
>
> I don't know, I think it was likely some unfinished effort where some
> initial code got copied. Code wise it was always a match for f_cushion()
> and so pointless as shipped.

I found _that_ definition (and description in the docs) equally .. illuminating.
 </grin>


regards, jr.

Post a reply to this message

On 1/29/22 07:50, William F Pokorny wrote:
>> I would tend to start from scratch, and just cancel all of that extra 
>> stuff and
>> see what happens. Maybe it might explain why they decided to do all of 
>> that.
> 
> A look at the basics is good advice.

Posting a little more data for those who might find themselves someday 
digging around in the same hole.

Surprise one is that negating the perturbed normals sitting in 
opposition to the raw normals does nothing to the initial perturbed 
reflected ray calculation!

It happens that the reflected ray direction calculation - by side effect 
- already looks at all the perturbed normals as sitting inside the 
negative raw normal's half plane. In other words, while it doesn't 
explicitly negate perturbed normals as does the refraction code, it 
comes to the same result(a).

The above does not mean the reflected rays are not sometimes running 
opposed to raw / perturbed surface normals where there is normal{} 
perturbation.

I took a look at how the fix is getting applied today given different 
bump sizes. The micro pattern being an even distribution of perturbed 
directions makes it a good pattern for looking at how the fixes break 
out given bump_size.

The results are interesting in that pretty much, if you have any 
normal{} perturbation and already tangent or near tangent surface 
relations, this fix is twiddling with our reflected result to some 
degree or other.

One sphere with reflection within sky_sphere.
     Fix0 - Marble look due dropping back to raw normal use.
     Fix1 - The double correction / reflection.
---------------------    Orig  NoFix   Fix0   Fix1
normal { micro 0.00 }  655360 655360      0      0 100%  0%  0%
normal { micro 0.01 }  655360 655317     10     33 100%  0%  0%
normal { micro 0.10 }  655360 651450    976   2934  99%  0%  0%
normal { micro 0.25 }  655360 631096   6162  18102  96%  1%  3%
normal { micro 0.50 }  655360 557621  24868  72871  85%  4% 11%
normal { micro 0.75 }  655360 444730  57817 152813  68%  9% 23%
normal { micro 1.00 }  655360 327379 106134 221847  50% 16% 34%
normal { micro 1.25 }  655360 275507 138012 241841  42% 21% 37%
normal { micro 1.50 }  655360 252949 153439 248972  39% 23% 38%
normal { micro 1.75 }  655360 241388 163163 250809  37% 25% 38%
normal { micro 2.00 }  655360 234691 170364 250305  36% 26% 38%
normal { micro 3.00 }  655360 224005 187031 244324  34% 29% 37%
normal { micro 4.00 }  655360 221058 195115 239187  34% 30% 36%
normal { micro 5.00 }  655360 219605 200161 235594  34% 31% 36%
normal { micro 9.00 }  655360 218117 208661 228582  33% 32% 35%

Bill P.

(a) - I think it might still be worthwhile to add a normal block option 
to make this correction as more than reflections/retractions depend upon 
the actual perturbed normal direction.

Post a reply to this message

On 1/28/22 12:50, jr wrote:
> have attached a mock-up example of an inc for POV-Ray proper.  the tag would
> just change to 'povr', and either inline or via an include have the specific
> stuff, and I think, the 'setidtypes.inc' content too.

OK. I think I have versions of f_odd(), fork_str() and fork_val() 
working for my povr branch.

Attaching a file like the version.inc / version_test.inc but called 
instead forkversionhook.inc which instead puts things in terms of 
whether the fork_str() and fork_val() functions exist.

Each fork's coder(s) could modify - or extend - the optional fork_* 
"information provided" as part of the include as a way to document what
information they offer for conditional behavior of scenes - and do some 
baseline testing of the code besides.

Feedback? Thoughts?

---
As to Bald Eagle's more standard versioning suggestion. I was thinking, 
as pairs, we could directly code up the fork_* pair versions as:

"Major version" 0
"Minor version" 4
"Patch version" 11

but, I've not done this as yet.

Bill P.

Post a reply to this message

Attachments:
Download 'forkversionhook.inc.txt' (5 KB)

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> OK. I think I have versions of f_odd(), fork_str() and fork_val()
> working for my povr branch.

when will/can you make this available?


> Attaching a file like the version.inc / version_test.inc but called
> instead forkversionhook.inc which instead puts things in terms of
> whether the fork_str() and fork_val() functions exist.
> ...
> Feedback? Thoughts?

downloaded, hope to look at it later this week.  thanks.


regards, jr.

Post a reply to this message