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