Working on an in-buit f_turb and think I finally tracked down an issue 
which has harassed me for years.

Our turbulence moves with omega. This looks not right to me given what I 
understand Brownian Motion to be. The code is effectively unchanged 
since it was added in v3.0. I'd expect with increasing omega for the 
distribution to get larger and possibly larger than 1.0 (docs mention 
this). What seems amiss to me is the more or less linear shift in the 
center of the distribution with omega.

If you don't know turbulence is doing this, using it can be very 
confusing. "My isosurface foliage doesn't line up with my iso tree 
branches - and everything leans one way!"

The irid (comment there about Turbulence returning 0-1 range) and fog 
features use Turbulence() I see. Expect the vector version of turbulence 
affected too. Agate of course, though probably hard to see any shift 
there - or maybe with any traditional pattern. More shift goes with more 
noise typically.

In the attached image created a set up which shows the distribution 
moving from a center of 0.25 and range of 0.5 to a center of about 2.0 
and a range of 4 as you approach an omega of one. Other settings seem 
not to matter much to the distribution, except as looks OK to my eye.

I think the distribution should be centered at 0.1 coming out of 
Turbulence() and DTurbulence() and it being a smaller or larger 
Gaussian, but...

Making a new f_turb centered and using only that sort of turbulence with 
isosurfaces doesn't really fly. I want to exploit the pattern warp stuff 
extensively including turbulence.

Anyone know the history with turbulence? Thoughts, opinions?

I've not yet tried to understand why the distribution's center is 
moving. I also suspect it's not spreading as much as it should, but I 
care about that less.

Bill P.

Post a reply to this message

Attachments:
Download 'turbomegadistributiondistortion.jpg' (135 KB)

Preview of image 'turbomegadistributiondistortion.jpg'

I really don't know anything about this but you seem to have found 
something. Just a question: I suppose this is also true for:

   warp {turbulence MyTurb}

Personally, I prefer to use the warp version which generates more 
interesting results.

-- 
Thomas

Post a reply to this message

On 5/21/20 2:28 AM, Thomas de Groot wrote:
> I really don't know anything about this but you seem to have found 
> something. Just a question: I suppose this is also true for:
> 
>    warp {turbulence MyTurb}
> 
> Personally, I prefer to use the warp version which generates more 
> interesting results.
> 

Yes, the underlying turbulence code is the same.

I think the right thing to do is to center the distribution by default. 
Provide a new turbplus turbulence which lets folks control more aspects 
of turbulence (scale,direction,...) and a distribution offset.

I'm too lazy to do this with the old default turbulence too, so in povr, 
turbulence and the octaves, omega, lamda backdoor methods to 'create' 
turbulence will become parse errors. The warp {turbulence ...} method 
will become the only supported way for users to create a turbulence 
warp/item.

I was thinking some about normal patterns last night with respect to 
this issue. The exposure is there too where the texture version of the 
same pattern can end up shifted relative to normal one should the omega 
values be different. I think what we want is turbulence where things 
stay centered where positioned without turbulence - unless the user 
specifically wants a shift.

Of course, all supposing I can work out the code for something better. 
We'll see.

Bill P.

Post a reply to this message

On 5/21/20 8:32 AM, William F Pokorny wrote:
> On 5/21/20 2:28 AM, Thomas de Groot wrote:
...
> 
> I think the right thing to do is to center the distribution by default. 
> Provide a new turbplus turbulence which lets folks control more aspects 
> of turbulence (scale,direction,...) and a distribution offset.
> 
> I'm too lazy to do this with the old default turbulence too, so in povr, 
> turbulence and the octaves, omega, lamda backdoor methods to 'create' 
> turbulence will become parse errors. The warp {turbulence ...} method 
> will become the only supported way for users to create a turbulence 
> warp/item.
> 
...

An update as much to help me be sure I have things straight in my head 
as to document.

First, we are not as bad off as I first guessed. All of the vector 
related turbulence uses DTurbulence which uses DNoise() and these 
already do return a 0.0 centered in a -1 to +1 range. See the attached 
image.

This vector behavior is what we want I think. However, it doesn't match 
our documentation which says the values are in a 0-1 range for 
turbulence. As far as I know there is no user direct access to 
non-vector turbulence(1) so even if that were the aim of today's code in 
turbulence that's never been what is happening best I can see (some pre 
v30 thing maybe?).

(1) - f_vturb() in povr will be this.

I was - more - confused when I posted the initial image. I'd forgotten 
that I'd changed my usual axises from +-1 to +-2 - AND scaled the 
returned values from Turbulence() by 0.5 trying to see all the 
distribution centers. So, the typical distributions from Turbulence 
today are all the way out at +4.0 not +2.0 as I said...

---
In a survey of affected code:

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.

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.

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! 
Up front plan is to make no code changes here. I think the Turbulence() 
fix will make fog turbulence better.

Bill P.

Post a reply to this message

Attachments:
Download 'storyvectorturbulence.png' (306 KB)

Preview of image 'storyvectorturbulence.png'

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