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