"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