I've been working on povr's it_ prefixed, internal turbulence, keywords 
implementation for patterns which have special turbulence handling. 
Those patterns are: agate, marble, spiral1, spiral2 and wood.

I've come to understand the pattern's internal turbulence cannot be run 
apart from also running classic turbulence excepting for agate, which 
has the agate_turb keyword. Even with agate, if you make the mistake of 
specifying an actual turbulence vector value you'll see both internal 
value turbulence and regular spacial turbulence. Supposing you leave the 
turbulence vector at the default 0.0 by using only agate_turb, octaves, 
omega and lambda - the null spacial turbulence is still getting calculated!

While news to me, I do not believe this is news to the v3.7 developers. 
There is in "struct ClassicTurbulence" a carefully set, but unused, 
handledByPattern boolean which was likely intended to skip the classic 
turbulence in the special turbulence patterns when running through the 
warp{} list. I checked v3.6 code and the value/spatial turbulence is 
tangled there too. I think the developers matched previous behavior.

In all but agate, the reason for the coupled value/spatial turbulence is 
the turbulence vector's value is being borrowed for what should be an 
independent agate_turb like keyword in all the patterns. For example, 
spiral2's pattern code has:

Turb = GetTurb(warps);
turb_val = Turb->Turbulence[X]*Turbulence(EPoint,Turb,GetNoiseGen(pThread));
//|||||||||||||||||

Aside: Yes, the EPoint as used in Turbulence could be better decoupled 
too.  As in providing an it_scale / it_offset vector options for 
starters, but perhaps such things are better left to the inbuilt 
functions. Not decided. I am leaning to enabling the it_scale keyword 
for special/value turbulence patterns, but we'll see.

Even if you carefully code say:

spiral1 1 turbulence <0.03,0,0>

to avoid y and z spatial turbulence, you get the x turbulence value as 
regular turbulence on top of the internal spiral1 pattern value turbulence.

There's more detail, but, perhaps another day.

Attached is an image showing size renders labeled A thru F all showing 
spiral1 examples.

(A) v3.8 current tangled turbulences.

     spiral1 1
     turbulence (1/3)*0.5

(B) A version of povr with only the Turbulence() omega distribution 
drift fix, but otherwise still tangled turbulences.

     spiral1 1
     turbulence (1/3)*0.5

(C) v3.8 again, but where we turn off both the internal value turbulence 
and the spatial x turbulence by coding the full vector with x at 0:

     spiral1 1
     turbulence <0,(1/3)*0.5,(1/3)*0.5>

(D) A current povr render with the it_, internal turbulence, keywords. 
Here with it_frequency we get only the pattern's value turbulence.

     spiral1 1
     it_frequency (1/3)*0.5

(E) A current povr render with the it_, internal turbulence, keywords. 
Specifying and getting only spacial turbulence.

     spiral1 1
     turbulence (1/3)*0.5

(F) A current povr render with the it_, internal turbulence, keywords. 
Specifying and getting both the internal value and spacial turbulence.

     spiral1 1
     it_frequency (1/3)*0.5
     turbulence (1/3)*0.5

Aside: Originally I was going to get rid of classic turbulence in povr, 
but, as mentioned recently elsewhere, it allows updates on inheriting 
from an existing pattern, so now thinking I'll keep it. Making, in the 
special turbulence cases this sort of turbulence/warp order:

it_ <-- classic turbulence <-- warp { turbulence, et al }

Aside: In povr I moved the wood pattern's use of DTurbulence() to 
Turbulence() so it uses the pattern specific noise generator if one is 
specified. The wood pattern was somewhat unique in always using noise 
generator 2 due the DTurbulence() use.

Aside: Due the omega distribution drift in Turbulence() I expect at 
times, with these special turbulence patterns, folks were mostly getting 
the spatial turbulence.

FWIW.

Bill P.

Post a reply to this message

Attachments:
Download 'storyspcturb.jpg' (272 KB)

Preview of image 'storyspcturb.jpg'

And so you continue to peel away the layers of the onion...

Any reason E spirals in the reverse direction than all the others?

Post a reply to this message

On 9/24/20 6:29 AM, Bald Eagle wrote:
> And so you continue to peel away the layers of the onion...
> 
> Any reason E spirals in the reverse direction than all the others?
> 
:-) I completely missed that!

When I reworked the two spiral patterns for povr, I changed the 
orientation (starting position) to match other patterns like radial ( 
atan2(y,x) ) - except not using atan2.

To match the v3.8 results I inserted a transformation and I missed a '-' 
(or accidentally deleted it) on that render.

---
I'll mention one more detail too, because it's really a bug. Sometime 
after v3.7, during one of the pattern and parsing refinements, the code 
for function spiral pattern parsing was incorrectly updated. The code, 
currently in parser_materials.cpp, reads:

CASE (SPIRAL1_TOKEN)
     New->Type = GENERIC_PATTERN;
     New->pattern = ParseSpiralPattern<Spiral2Pattern>();
END_CASE

CASE (SPIRAL2_TOKEN)
     New->Type = GENERIC_PATTERN;
     New->pattern = ParseSpiralPattern<Spiral2Pattern>();
END_CASE

That first ParseSpiralPattern template parameter should be Spiral1Pattern.

In recent v3.8s it means pattern use is OK, but function { pattern {} } 
use always uses spiral2.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> I've been working on povr's it_ prefixed, internal turbulence, keywords
> implementation for patterns which have special turbulence handling.
> Those patterns are: agate, marble, spiral1, spiral2 and wood.
[snip]

This is fascinating work that you are doing-- and very detailed.

It makes me wonder about turbulence use in the fog(...) keyword, whether or not
that is also being incorrectly modified or 'applied twice', in the way you have
described. But that is of no great importance right now; you can save that
detective work for another day. ;-)

Keep up the good work!

Post a reply to this message

On 9/24/20 5:39 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> It makes me wonder about turbulence use in the fog(...) keyword, whether or not
> that is also being incorrectly modified or 'applied twice', in the way you have
> described. But that is of no great importance right now; you can save that
> detective work for another day. ;-)
> 
> Keep up the good work!
> 

It isn't.

I substantially reworked / fixed fog for povr. Got into it because it 
used the fixed Turbulence() function. Uncovered quite a bit more not 
right once looking at it. There were several reasons the turbulence with 
fog has never worked that well. The turbulence not getting copied when a 
defined fog was copied is one I remember.

See the thread:

http://news.povray.org/povray.binaries.images/thread/%3C5ed7f187%241%40news.povray.org%3E/


Bill P.

Post a reply to this message

On 9/24/20 5:42 AM, William F Pokorny wrote:
> I've been working on povr's it_ prefixed, internal turbulence, keywords 
> implementation for patterns which have special turbulence handling. 
> Those patterns are: agate, marble, spiral1, spiral2 and wood.
> 
...

An update. I was aiming at another release of the povr code this past 
weekend. It's been a while.

However, I've been playing over the past days some with the new it_* 
keywords with pattern internal Turbulence() working apart from old style 
turbulence in addition. It's easy enough to duplicate previous behavior, 
but I'm finding what can better be accomplished, with the additional 
it_frequency keyword and split turbulence, disappointing. A little 
better sometimes; a little faster sometimes yes, but...

Also learning more about the limitations of the current patterns.

I was already thinking it_scale, it_offset good ideas for clarity and 
control.I now think the it_frequency I used in all five not really the 
right concept for some patterns. Maybe an it_magnitude instead in some 
cases.

We have the wood pattern(1), where, in the ideal case we are missing an 
inbuilt way to vary the growth ring thickness apart from all other 
turbulence/noise(2). Further, the way only x and y turbulence only are 
used internally (no matter the version) introduces asymmetry in the 
result not ideal for a generic treatment of wood cut from a log.

I thought I was further along than I am. I don't yet know exactly what 
I'm doing with these 5 special patterns. FWIW.

Bill P.

(1) - I looked back at v3.1 and it looks there as if the internal 
turbulence was all that was used for wood and marble. The others still 
seeing two coupled turbulences. So looks like there was some change for 
those two patterns over time.

(2) - Wood rings have in seasonal climates early and late contributions. 
  Would an approach to wood more like the pavement and tiling patterns 
make sense... We can with warps handle most turbulence required 
externally. We're also shaping to a triangle wave which doesn't fit the 
ramp wave of growth rings. Might a simple cylindrical pattern (a single 
0-1 ramp) with turbulence and very detailed map(s) be better in general 
for wood. Unsure at the moment where to push.

(2a) Not done it, but pretty sure we can duplicate the existing wood 
pattern with other functionality.

Post a reply to this message