On 5/24/20 10:22 AM, William F Pokorny wrote:
> On 5/21/20 8:32 AM, William F Pokorny wrote:
...
> 
> The finish irid feature assumes a 0-1 distribution and does some math to 
> get a zero centered, -1 to 1 one for further calculation. It hard codes 
> the turbulence parameters and has omega at 0.5. This feature has some 
> other issues like lack of ability to scale relative to the incoming 
> coordinates which will make it tricky to get something which always 
> works with respect to scene dimensions. The documentation also mentions 
> irid_amount and I don't see it anywhere in the calculations... I think 
> given numerical accuracy there should be some >=0 clamping to not 
> sometimes get negative thicknesses... Anyway work to do here.
> 

Attached an image up the updated irid code running with the fixed 
Turbulence(). I also added the clamp to prevent the film thickness from 
going below 0.0 and one of our demo scenes hits this clamp. See the 
lower right sphere in the middle set. Less colorful result but I think 
correct. There is no film there.

I also tried for a matching fudge factor to match the breadth of the old 
Turbulence() distribution. Cannot match previous precisely, but not bad 
in my view.

Bill P.

Post a reply to this message

Attachments:
Download 'iridturbulencedistfixandclamp.jpg' (72 KB)

Preview of image 'iridturbulencedistfixandclamp.jpg'

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

> The patterns agate, marble, spiral1, spiral2 where turbulence is used
> will be getting violent shifts both on use of turbulence where not a
> default and on omega changes. Aside: wood uses turbulence too by in x
> and y so DTurbulence() and is OK. The plan is to do nothing with the
> affected patterns post Turbulence() change unless something pops.

I (and likely others) would like some way to better understand the distribution
of values in the pigment patterns.   That's from the perspective of "I would
like a bit more of THAT tone in my wood pattern ....   so what portion of my
texture map do I need to adjust...?"

I bring that up because I'm trying to envision omega, octaves, lamda, etc, and
I'd need a graph of that to better understand what knobs to fiddle with when I'm
crafting a turbulated pattern.

Specifically with respect to noise and turbulence, and the range of values that
functions return, it would be nice to have a way to know or be reminded that an
inbuilt function, where the calculations are invisible to the user, deviate from
a 0-1 range.

I'd say that from an isosurface perspective, it would be MOST helpful in
determining where to set the threshold, or what to subtract from the equation in
order to get a zero-value surface.

http://wiki.povray.org/content/Documentation:Tutorial_Section_3.2#Noise_and_pigment_functions
"Using this simple noise3d function results in the image on the right. The value
-0.5 matches the default threshold value of zero. The f_noise3d function returns
values between 0 and 1:

function { f_noise3d(x,y,z)-0.5 }"

(Most folks would be tempted to just use noise and a 0 threshold, and then waste
a lot of time trying to "debug" the isosurface object.

> The finish irid feature ....
> ... This feature has some
> other issues like lack of ability to scale relative to the incoming
> coordinates which will make it tricky to get something which always
> works with respect to scene dimensions.

I would very much like a function that "scales space" prior to passing world
space cooordinates into functions.
Having had to grapple with that issue, I'm wondering what the best
implementation of that would be.  I'm also curious what your approach is when
you use functions.
I haven't figured out how to graph a function with the native (x,y,z) - so I
define all my functions with capitals, which just act as containers for the
lowercase I pass to it on invocation.
Then I can graph them using a #for (X, 0, tau) loop ....

Yeah - iridescence seems ... "special".
Using Iridescence
"Iridescence is what we see on the surface of an oil slick when the sun shines
on it. The rainbow effect is created by something called thin-film interference
(read section Iridescence for details). For now let's just try using it.
Iridescence is specified by the irid statement and three values: amount,
thickness and turbulence. The amount is the contribution to the overall surface
color. Usually 0.1 to 0.5 is sufficient here. The thickness affects the busyness
of the effect. Keep this between 0.25 and 1 for best results. The turbulence is
a little different from pigment or normal turbulence. We cannot set octaves,
lambda or omega but we can specify an amount which will affect the thickness in
a slightly different way from the thickness value. Values between 0.25 and 1
work best here too."

> I think
given numerical accuracy there should be some >=0 clamping to not
sometimes get negative thicknesses

maybe abs() ?


> Not tested to confirm, but the fog features using turbulence I suspect
> are in bad shape. There is a min(1.0,Turbulence(..)... bit used a ouple
> places which I believe will make it very hard to get much turbulence
> given the distribution center is way the heck out at 4.0 with defaults!

yeah wow - that's WAY out there...

Post a reply to this message

On 5/24/20 12:18 PM, William F Pokorny wrote:
> On 5/24/20 10:22 AM, William F Pokorny wrote:
...
>> always works with respect to scene dimensions. The documentation also 
>> mentions irid_amount and I don't see it anywhere in the 
>> calculations... 
...

Forgot to mention documentation's irid_amount gets mapped to just 'irid' 
in the code. It's there.

Bill P.

Post a reply to this message

On 5/24/20 12:16 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
> I (and likely others) would like some way to better understand the distribution
> of values in the pigment patterns.   That's from the perspective of "I would
> like a bit more of THAT tone in my wood pattern ....   so what portion of my
> texture map do I need to adjust...?"
> 
> I bring that up because I'm trying to envision omega, octaves, lamda, etc, and
> I'd need a graph of that to better understand what knobs to fiddle with when I'm
> crafting a turbulated pattern.
> 
> Specifically with respect to noise and turbulence, and the range of values that
> functions return, it would be nice to have a way to know or be reminded that an
> inbuilt function, where the calculations are invisible to the user, deviate from
> a 0-1 range.

I agree, more inbuilt ability to see the value distributions is needed. 
It would, over the years, have saved me huge chunks of time - especially 
where POV-Ray has been wrong! Not yet quite sure how to approach it in a 
practical sense. By adding functions like f_turb() I am making 
accessible what's not been, but that's just a piece of what is needed.

> 
> I'd say that from an isosurface perspective, it would be MOST helpful in
> determining where to set the threshold, or what to subtract from the equation in
> order to get a zero-value surface.

I think pretty much always have the threshold at 0.0 for best 
interoperability of functions. Subtract or add to the function to get to 
a zero values surface as you say. Aside: I think putting out a bunch of 
canned functions with thresholds all over the place mostly makes things 
more difficult for typical users. I get why mathematicians would think a 
non-zero threshold capability a good idea, but in a tool like POV-Ray 
it's mostly a bad one.

> 

...
Yep, agree.

> 
...
> 
> I would very much like a function that "scales space" prior to passing world
> space cooordinates into functions.

This was an aim of the new to povr pattern_modifiers {} keyword.

> Having had to grapple with that issue, I'm wondering what the best
> implementation of that would be.  I'm also curious what your approach is when
> you use functions.
> I haven't figured out how to graph a function with the native (x,y,z) - so I
> define all my functions with capitals, which just act as containers for the
> lowercase I pass to it on invocation.
> Then I can graph them using a #for (X, 0, tau) loop ....

I used to do loops more often; creating spheres and such to represent 
value regions. More though, I'm using functions as pigments - partly 
reasons for raw_wave and function_interval wave modifier keywords in 
povr. The blend functions support ranges other than 0-1, but the wave 
form modification code in POV-Ray proper clamps and modifies values to 
always be in a 0-1 range... Even with the new functionality in povr, it 
still means remapping or collapsing the values into a more workable ranges.

> 
>> Not tested to confirm, but the fog features using turbulence I suspect
>> are in bad shape. There is a min(1.0,Turbulence(..)... bit used a ouple
>> places which I believe will make it very hard to get much turbulence
>> given the distribution center is way the heck out at 4.0 with defaults!
> 
> yeah wow - that's WAY out there...
> 
Yep...

So, you taken any more runs at the elliptical_torus? I hate the thing 
now! It seems like it should be doable (even not that hard), so I keep 
taking runs at it - and I just cannot get it... :-)

Bill P.

Post a reply to this message

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

> I agree, more inbuilt ability to see the value distributions is needed.
> It would, over the years, have saved me huge chunks of time - especially
> where POV-Ray has been wrong! Not yet quite sure how to approach it in a
> practical sense. By adding functions like f_turb() I am making
> accessible what's not been, but that's just a piece of what is needed.

Agreed.   Certainly the mapping of the pigments with the function values helped
me understand that more, as did writing out / copying all of the source code
pigments into SDL (the easy ones  ;) ).

> Aside: I think putting out a bunch of
> canned functions with thresholds all over the place mostly makes things
> more difficult for typical users.

Yes, and I need to work on my idea of casting out a bit and searching for a more
suitable level set value, if the user-defined one is chosen badly.


> > I would very much like a function that "scales space" prior to passing world
> > space cooordinates into functions.
>
> This was an aim of the new to povr pattern_modifiers {} keyword.

Ah, excellent.  :)


> I used to do loops more often; creating spheres and such to represent
> value regions. More though, I'm using functions as pigments - partly
> reasons for raw_wave and function_interval wave modifier keywords in
> povr.

I have started to do that more myself, having recognized the value and ease of
it.  :)

I was starting to do more of that here, but I needed some education and
direction:
http://news.povray.org/povray.advanced-users/thread/%3Cweb.5ec33c80cab151a1fb0b41570%40news.povray.org%3E/


> So, you taken any more runs at the elliptical_torus? I hate the thing
> now! It seems like it should be doable (even not that hard), so I keep
> taking runs at it - and I just cannot get it... :-)

The above thread was part of my effort to get a more solid footing, and I sent
out an email to a math/comp sci professor - which has yet to be acknowledged or
replied to.  I will try spamming a few more ivory tower academics...  ;)

The radius gets elliptified as one increases the eccentricity.   So maybe one
way to approach it is to figure out what terms to add in to negate that
effect...
define the minor radius as an ellipse, and do the adjustments there...

I had an entrepreneurial business project I got roped into, so I've been coding
a bunch of stuff and had an all-nighter or two, so that's eaten up a bunch of
time and energy lately.   As you say - it _looks_ like it should be SO easy....
 so I won't be able to let it go, will I?   ;)  :D

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> By adding functions like f_turb() I am making
> accessible what's not been, but that's just a piece of what is needed.

I'm this doesn't make things any easier to follow:

http://wiki.povray.org/content/Reference:Warp#Turbulence
Turbulence
The turbulence pattern modifier is still supported for compatibility issues, but
it is better nowadays to use the warp turbulence feature, which does not have
turbulence's limitation in transformation order (turbulence is always applied
first, before any scale, translate or rotate, whatever the order you specify).
For a detailed discussion see Turbulence versus Turbulence Warp

The old-style turbulence is handled slightly differently when used with the
agate, marble, spiral1, spiral2, and wood textures."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


I'm thinking that maybe with tools like Wolfram or ShaderToy that are capable of
doing very fast calculation and visualization, some POV-Ray functions can be
represented, and values can be adjusted with sliders.   Just to get the general
idea, and fast, interactive RT feedback

Post a reply to this message

Op 24/05/2020 om 18:16 schreef Bald Eagle:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 

[snip]

>> The finish irid feature ....
>> ... This feature has some
>> other issues like lack of ability to scale relative to the incoming
>> coordinates which will make it tricky to get something which always
>> works with respect to scene dimensions.
> 
[snip]

> 
> Yeah - iridescence seems ... "special".
> Using Iridescence
> "Iridescence is what we see on the surface of an oil slick when the sun shines
> on it. The rainbow effect is created by something called thin-film interference
> (read section Iridescence for details). For now let's just try using it.
> Iridescence is specified by the irid statement and three values: amount,
> thickness and turbulence. The amount is the contribution to the overall surface
> color. Usually 0.1 to 0.5 is sufficient here. The thickness affects the busyness
> of the effect. Keep this between 0.25 and 1 for best results. The turbulence is
> a little different from pigment or normal turbulence. We cannot set octaves,
> lambda or omega but we can specify an amount which will affect the thickness in
> a slightly different way from the thickness value. Values between 0.25 and 1
> work best here too."
> 

I am probably wrong, but I seem to recall that Christoph did some 
massive work in overhauling iridescence a number of years ago...? Indeed 
in 2011:

http://news.povray.org/povray.binaries.images/thread/%3C4ed6f24c@news.povray.org%3E/

...there should be more about this.

Or is this unrelated to the present problem?

-- 
Thomas

Post a reply to this message

On 5/25/20 2:33 AM, Thomas de Groot wrote:
> Op 24/05/2020 om 18:16 schreef Bald Eagle:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
> 
> [snip]
> 
>>> The finish irid feature ....
>>> ... This feature has some
>>> other issues like lack of ability to scale relative to the incoming
>>> coordinates which will make it tricky to get something which always
>>> works with respect to scene dimensions.
>>
> [snip]
> 
>>
>> Yeah - iridescence seems ... "special".
>> Using Iridescence
>> "Iridescence is what we see on the surface of an oil slick when the 
>> sun shines
>> on it. The rainbow effect is created by something called thin-film 
>> interference
>> (read section Iridescence for details). For now let's just try using it.
>> Iridescence is specified by the irid statement and three values: amount,
>> thickness and turbulence. The amount is the contribution to the 
>> overall surface
>> color. Usually 0.1 to 0.5 is sufficient here. The thickness affects 
>> the busyness
>> of the effect. Keep this between 0.25 and 1 for best results. The 
>> turbulence is
>> a little different from pigment or normal turbulence. We cannot set 
>> octaves,
>> lambda or omega but we can specify an amount which will affect the 
>> thickness in
>> a slightly different way from the thickness value. Values between 0.25 
>> and 1
>> work best here too."
>>
> 
> I am probably wrong, but I seem to recall that Christoph did some 
> massive work in overhauling iridescence a number of years ago...? Indeed 
> in 2011:
> 
> http://news.povray.org/povray.binaries.images/thread/%3C4ed6f24c@news.povray.org%3E/

> 
> 
> ...there should be more about this.
> 
> Or is this unrelated to the present problem?
> 

Thank you for the newsgroup pointer.

His updates - assuming they are the code I see - are tangle with this 
problem because Turbulence() wasn't - or isn't now in any case - 
returning the distribution and range assumed in the code.

Christoph's changes were - I believe made for the v37 release. The 
documentation notes changes to actual physical dimensions for v37(1). 
Which, on more thought, means I need to yank my fudge matching, magic 
factor back out of the code and update the scenes for the proper end 
thicknesses given the turbulence instead!

He mentions being unable to scale for the same effect - which I believe 
is correct with respect to the viewer frame. I'm suggesting when using 
turbulence adding some method to scale and/or shift the turbulence of 
the thickness a good idea given the difficulty matching up with changing 
scene scaling of some object. Like media and density, if you want the 
turbulence to be constant (maybe yes, maybe some, maybe no) you'd need 
to 'counter' adjust it in some way on scene scaling - we cannot do this.

(1) The documentation in r3_6.html#r3_6_1_3_7 has this 3.7 note:

"Note: The version 3.7 iridescence feature has had a major overhaul. The 
syntax remains the same, however, both the thickness and amount values 
are now specified in microns. Consequently, iridescence effects will 
vary from previous versions."

which emphasizes 'both' thickness and amount being in microns. The 
'thickness amount' is, and the 'turbulence amount' is, but the 
irid_amount is just a color intensity multiplier for the irid_wavelength
color specified in global_settings. We could likely help new to irid 
users by making this clearer.

The "See also the global setting Irid_Wavelength for additional 
information." sentence I think should probably be up in the paragraph 
with irid_amount because - indirectly - this is the 'amount' of color, 
color to which it's related.

Anyway, this rushed so apologies for the mistakes. Off to real life for 
a few days. Thanks again for the prompt. I need to yank that fudge 
factor in my povr code.

Bill P.

Post a reply to this message

On 5/24/20 12:18 PM, William F Pokorny wrote:
...
> 
> I also tried for a matching fudge factor to match the breadth of the old 
> Turbulence() distribution. Cannot match previous precisely, but not bad 
> in my view.
> 
...
In povr, irid updated to yank fudge factor and scenes updated with 
accurate base thicknesses. Thanks Thomas.

When I looked at the fixed internal turbulence() with fog picked up 
additional bugs I expect kept folks from doing a lot especially with 
turbulence (copy constructor was creating new, but not copying old 
turbulence values, for example).

Anyway. In povr I've got the turbulence() fix in - with fixes to irid 
and a significant re-work of fog updating and adding features/keywords. 
Image attached showing some of the fixed and extended features.

The agate pattern looks different, but OK, with the turbulence() fix. 
Not looked in detail at marble or the two spiral patterns as yet. Still 
some f_turbulence() work to finish off.

Bill P.

Post a reply to this message

Attachments:
Download 'fogstory.jpg' (148 KB)

Preview of image 'fogstory.jpg'

Well done, sir. Keep up the good work!

-- 
Thomas

Post a reply to this message