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

On 2/8/22 09:25, jr wrote:
> when will/can you make this available?

I'm aiming for March, but these fork information hooks are not yet even 
checked in. It's all the first pass at something I think workable and I 
fully expect to further polish the include file header and clean up the 
modified code.

That said, I've begun doing some sanity checking that performance 
related changes implemented over the past few months, hold for the -o3 
-ffast-math -march=native and configure --enable-lto compiles where I 
intend to use my povr branch personally.

The --enable-lto option, especially, is too painful to use during day to 
day development, but I certainly want to use it when really rendering 
scenes.

I've done a fair bit to slow povr code down too in fixing bugs and 
adding options. Trying too, to check none of those cause too much slow 
down as compiled and linked for real use.

Bill P.

Post a reply to this message

On 2/9/22 13:16, William F Pokorny wrote:
> On 2/8/22 09:25, jr wrote:
>> when will/can you make this available?
> 
> I'm aiming for March, but these fork information hooks are not yet even 
> checked in. It's all the first pass at something I think workable and I 
> fully expect to further polish the include file header and clean up the 
> modified code.
> 

Attached is a refinement of the forkversionhook.inc file. The more I 
thought about Bald Eagle's idea of versioning, the more I came to 
believe his "do versioning now" idea a good one. Previously, I basically 
had a release/tarball count, but that could easily change.

So, this version adopts and defines POV-Ray's Major, Minor, Revision, 
Patch set up as creates a new povr release/tarball counter for it's 
simpler 'version' number. Code wise, I also moved the value definitions 
into version.h alongside POV-Ray's normal versioning. That version.h 
file already also defines well what the values mean.

For the code check in I'm about to do there will be no difference 
between povr's minor version and the tarball count (next is 6). All the
other values are currently 0. Of course the earlier five povr tarballs 
have none of this fork hook code.

Bill P.

Post a reply to this message

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

hi,

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

only a couple of "things".  (sorry took a few days)

I (still) think that the .inc would be a good place to store other
'povr'-specific stuff too, like the ids.

from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
hoped for a 'version.inc' which would work regardless, for any version and/or
fork of POV-Ray.

lastly, the constant + macro names are, um, a little verbose?  :-)

thanks.


regards, jr.

Post a reply to this message

On 2/14/22 10:57, jr wrote:
> hi,
> 
> William F Pokorny<ano### [at] anonymousorg>  wrote:
>> Feedback? Thoughts?
> only a couple of "things".  (sorry took a few days)

No worries.

> 
> I (still) think that the .inc would be a good place to store other
> 'povr'-specific stuff too, like the ids.
> 

Here, I wonder if perhaps the scale of change in the povr branch is 
being seen as less extensive than it in fact is. The new setidtypes.inc 
is one of several completely new include files.

Nearly all the remaining, shipped include files are substantially 
different. Only rand.inc hasn't been changed much - mostly because I see 
a good many puzzles there in code that I don't think many use. I'm not 
sure what to do povr's current rand.inc as yet.

The povr branch only ships 14 includes - to be 15 with forkversionhook.inc.

Lastly, an aim is that the 'forkversionhook.inc' file be extensible. 
That, in approach, its able to accommodate multiple forks / patches / 
branches. In other words, in just supporting multiple forks over time, 
it could grow substantially in size. I see no reason this file cannot be 
shared - at least to some degree - across forks.

> from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
> hoped for a 'version.inc' which would work regardless, for any version and/or
> fork of POV-Ray.

I'll try to reduce / rework the mentions of povr.

The current forkversionhook.inc does work for any POV-Ray version - at 
least when I've tested it.

It's only povr specific when the SDL variable Dump_povr_fork_ is set on 
inclusion. Then it prints documentation as to what povr fork_*() 
constants are available and stops - and it only does that much if the 
fork being run is in fact 'povr'. I'll add a commented #debug where I 
had an empty else block indicating something which could be printed when
the fork hook is not found. It's commented because I don't want to 
default to always printing something on inclusion of
forkversionhook.inc. Regular include use will be to make the 
'Have_f_odd_fork_hook()' macro available to scene code and nothing more.

> Have_f_odd_fork_hook()
> lastly, the constant + macro names are, um, a little verbose?:-)
> 

Agree.

In general, I think I'll reduce the f_odd() visibility. No reason day to 
day users need to know this the internal 'hook'.

I also think you're right it's better to call the fork_*()s, constants, 
rather than functions.

Beyond that I'll take you to mean, perhaps, something like the following:

forkversionhook.inc -->  forkhooks.inc ?

Have_f_odd_fork_hook() --> HaveForkConstants() ?

Dump_povr_fork_  --> Fork_povr ?

...I'm less a fan of shortening the constant pairs, but...

fork_str(n) --> frkstr(n) ?
fork_val(n) --> frkval(n) ?

Better?

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/14/22 10:57, jr wrote:
> > ...
> > I (still) think that the .inc would be a good place to store other
> > 'povr'-specific stuff too, like the ids.
> >
>
> Here, I wonder if perhaps the scale of change in the povr branch is
> being seen as less extensive than it in fact is. ...
> In other words, in just supporting multiple forks over time,
> it could grow substantially in size. I see no reason this file cannot be
> shared - at least to some degree - across forks.

yes there is much divergence, and I had not thought "forward", ie after a number
of subsequent releases, so scratch the thought.  (I focus perhaps too much on
"everything in one place", anyway)


> > from the looks of 'forkversionhook.inc' it will be only for 'povr', I'd have
> > hoped for a 'version.inc' which would work regardless, for any version and/or
> > fork of POV-Ray.
>
> I'll try to reduce / rework the mentions of povr.
>
> The current forkversionhook.inc does work for any POV-Ray version - at
> least when I've tested it.  ...
> I'll add a commented #debug where I
> had an empty else block indicating something which could be printed when
> the fork hook is not found. It's commented because I don't want to
> default to always printing something on inclusion of
> forkversionhook.inc. Regular include use will be to make the
> 'Have_f_odd_fork_hook()' macro available to scene code and nothing more.

works as in parses, but (empty else branch) no feedback when it isn't povr.  I
think that I'd hoped for a situation where POV-Ray proper and (eventually) all
forks supply a version.inc which tells, basically, whether or not "official";
forks, and POV-Ray, are then free to add constants and or macros to probe
further.


> > Have_f_odd_fork_hook()
> > lastly, the constant + macro names are, um, a little verbose?:-)
> ...
> Beyond that I'll take you to mean, perhaps, something like the following:
>
> forkversionhook.inc -->  forkhooks.inc ?
>
> Have_f_odd_fork_hook() --> HaveForkConstants() ?

:-)  'forkversion.inc', actually.  it's the "hook" that's .. surplus in my view.
 I don't mind the underscores, think they aid readability.


> ...I'm less a fan of shortening the constant pairs, but...
>
> fork_str(n) --> frkstr(n) ?
> fork_val(n) --> frkval(n) ?
>
> Better?

ouch!  personally (if it mattered) 'fork_{str,val}' is fine, though I'd probably
write 'fork_{key,val}'.


regards, jr.

Post a reply to this message

"jr" <cre### [at] gmailcom> wrote:

just to clarify.

> ...
> think that I'd hoped for a situation where POV-Ray proper and (eventually) all
> forks supply a version.inc which tells, basically, whether or not "official";

I don't mean official as in compiled-by.  "official" returned from a version.inc
would tell me that the scene's SDL will work as detailed in the official
wiki/docs.

Post a reply to this message

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

> Lastly, an aim is that the 'forkversionhook.inc' file be extensible.
> That, in approach, its able to accommodate multiple forks / patches /
> branches. In other words, in just supporting multiple forks over time,
> it could grow substantially in size. I see no reason this file cannot be
> shared - at least to some degree - across forks.

It's just a text file.  And it's for POV-Ray - so just how many edits and forks
there will be ....   I mean, even if it was War & Peace in ASCII, it still
wouldn't be that large of a file.
A functional option, one I'm not sure I like ATM, is to have a version
_directory_ with a tree of inc files that the main file includes and executes -
only if they exist.   Then the individual users can grow or prune the contents
of the directory as they see fit.  Still think that for any given fork, a
generic named file should call the most recent name-with-version.inc
That way people can search the forums (fora?) and easily see if they have the
proper/latest version of what they're looking for.   Even if it's just File1,
File2, File3 ....   it at least makes the filename different, and gives an
easily identifiable sequential progression.

> In general, I think I'll reduce the f_odd() visibility. No reason day to
> day users need to know this the internal 'hook'.

You can have silent and verbose modes.
Silent is for everyday use, verbose can be for anyone looking to figure
something out.   Just set a flag, look for the presence of a dummy file...


As for constant, function, and macro names, there's a school of thought that if
your names are descriptive enough, the code is "self documenting" and doesn't
require comments.   I think this works well for code that isn't long on the
first few (re)write(s) and only gets edited every so often.   Using long names
in day to day use is a DRAG.

Post a reply to this message