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