<---------------------- References. Seven previous posts

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ea57285%241%40news.povray.org%3E/

and

http://news.povray.org/povray.beta-test.binaries/thread/%3C5ead9027%40news.povray.org%3E/

Replacing the f_agate simple pattern{} wrap in functions.inc with a new 
inbuilt f_agate which brings out the x,y,z directions and power exponent 
as parameters in addition to parameters for the turbulence call's 
octaves, omega and lambda.

Parameters: x, y, z
7 extra parameter required:
---
1. 0,1 or 2 for x, y or z agate alignment. Pattern's agate always uses z 
(2).

2. Turbulence multiplier. Called agate_turb in the pattern version. (1.0).

3. Power exponent for pow(). Hard coded to 0.77 in the pattern version. 
(0.77)

4. Number of octaves for the turbulence call. Pattern version defaults 
to (6).

5. Omega value for the turbulence call. Pattern version defaults to 0.5.

6. Lambda value for the turbulence call. Pattern version defaults to 2.0.

7. The noise generator to use. Valid values 1-3. Pattern agate uses 
pattern or global setting.

Notes. To match the default pattern agate: 
f_agate(x,y,z,2,1.0,0.77,6,0.5,2.0,2)  <-- Matches pattern agate when 
everything defaulted.  With the pattern agate octaves, omega and lambda 
can be set with those bare keywords immediately after agate changing 
agate's inbuilt turbulence.

For the bottom of the attached image creating an isosurface using both 
the non-preferred directions looks like:

#declare Iso99 = isosurface {
     function { y+f_agate(x*2,y*2,z*2,0,0.08,0.20,6,0.5,2.0,2)*0.135
                 +f_agate(x*2,y*2,z*2,2,0.08,0.20,6,0.5,2.0,2)*0.135
     }
...

On the top of the image subtracted both f_agate()s at multiplier of 0.035.

In a surprise, I expected f_agate() to be a little slower than the 
inbuilt used as a pattern in a pigment, for example. It's running about 
16% faster for reasons not currently understood. This the first pattern 
where - other than f_dents which is cheap - the inbuilt function 
implementation can match the pattern one exactly. (My f_granite23 
inbuilt doesn't match granite.) A mystery for another day.

Bill P.

Post a reply to this message

Attachments:
Download 'story_f_agate.jpg' (285 KB)

Preview of image 'story_f_agate.jpg'

Le 2020-05-07 à 21:45, William F Pokorny a écrit :
> <---------------------- References. Seven previous posts
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ea57285%241%40news.povray.org%3E/

> 
> 
> and
> 
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5ead9027%40news.povray.org%3E/

> 
> 
> Replacing the f_agate simple pattern{} wrap in functions.inc with a new 
> inbuilt f_agate which brings out the x,y,z directions and power exponent 
> as parameters in addition to parameters for the turbulence call's 
> octaves, omega and lambda.
> 
> Parameters: x, y, z
> 7 extra parameter required:
> ---
> 1. 0,1 or 2 for x, y or z agate alignment. Pattern's agate always uses z 
> (2).
> 
> 2. Turbulence multiplier. Called agate_turb in the pattern version. (1.0).
> 
> 3. Power exponent for pow(). Hard coded to 0.77 in the pattern version. 
> (0.77)
> 
> 4. Number of octaves for the turbulence call. Pattern version defaults 
> to (6).
> 
> 5. Omega value for the turbulence call. Pattern version defaults to 0.5.
> 
> 6. Lambda value for the turbulence call. Pattern version defaults to 2.0.
> 
> 7. The noise generator to use. Valid values 1-3. Pattern agate uses 
> pattern or global setting.
> 
> Notes. To match the default pattern agate: 
> f_agate(x,y,z,2,1.0,0.77,6,0.5,2.0,2)  <-- Matches pattern agate when 
> everything defaulted.  With the pattern agate octaves, omega and lambda 
> can be set with those bare keywords immediately after agate changing 
> agate's inbuilt turbulence.
> 
> For the bottom of the attached image creating an isosurface using both 
> the non-preferred directions looks like:
> 
> #declare Iso99 = isosurface {
>      function { y+f_agate(x*2,y*2,z*2,0,0.08,0.20,6,0.5,2.0,2)*0.135
>                  +f_agate(x*2,y*2,z*2,2,0.08,0.20,6,0.5,2.0,2)*0.135
>      }
> ...
> 
> On the top of the image subtracted both f_agate()s at multiplier of 0.035.
> 
> In a surprise, I expected f_agate() to be a little slower than the 
> inbuilt used as a pattern in a pigment, for example. It's running about 
> 16% faster for reasons not currently understood. This the first pattern 
> where - other than f_dents which is cheap - the inbuilt function 
> implementation can match the pattern one exactly. (My f_granite23 
> inbuilt doesn't match granite.) A mystery for another day.
> 
> Bill P.

Those looks like a slightly turbulent quilted pattern. Especially the 
top example.

Post a reply to this message

On 5/7/20 10:23 PM, Alain Martel wrote:
...
> 
> Those looks like a slightly turbulent quilted pattern. Especially the 
> top example.

I agree. :-) You can take the f_agate turbulence to 0.0 and get clean 
lines (or grids) making it look similar to other patterns(1). Suppose on 
some level the underlying driving variables - dimensions - are always 
there.

An f_quilted() inbuilt on my list. It's got better control of the shape 
of both extremes in value. With it I'm thinking of adding options which 
run in x, y and z only. Maybe adding turbulence as an internal option 
makes sense too...

Bill P.

(1) And the agate oriented dimension 'greys out.'

Post a reply to this message

On 5/7/20 9:45 PM, William F Pokorny wrote:
...
> In a surprise, I expected f_agate() to be a little slower than the 
> inbuilt used as a pattern in a pigment, for example. It's running about 
> 16% faster for reasons not currently understood. This the first pattern 
> where - other than f_dents which is cheap - the inbuilt function 
> implementation can match the pattern one exactly. (My f_granite23 
> inbuilt doesn't match granite.) A mystery for another day.
...

A significant part of the performance degrade in the normal agate 
pattern looks to be due the use of a dynamic_cast(1) while it checks 
which turbulence warp exists / is the internal agate one. So, other 
special turbulence patterns likely have this slow down too - though I've 
not tested them.

In povr I'm now on the path of creating a set of it_ prefix turbulence 
keywords and have this going for fog. Plan to move all the special 
turbulence to these over time and move the special turbulence storage 
out of the warp list into whatever. The it_ stands for (i)nternal 
(t)urbulence. What I'm working with currently is:

it_depth      - Scaling by value along ray or other single vector.

it_frequency  - Multiplying the turbulence returned value(s). In action 
                  it's a synonym for it_magnitude, butthe result is used 
for a pattern map, or similar. Meaning the value(s) will see some form 
of fmod() resulting in a frequency of repetitions through the map - or 
whatever.

it_lambda     - Violence of each step(2.0).

it_magnitude  - Synonym for it_frequency in action, but better
description when thinking about vector turbulence and we are changing 
              the magnitude of the returned DTurbulence vectors.

it_octaves    - Integer. Number of iterations 1 to 10?.

it_omega      - Dampening factor (0.5)

it_scale      - Multiplies input coordinates before turbulence 
generated.  Internally x|y|z/<float(s)>. The fog turbulence 3d vector is 
really acting as a 3d inverse scale.it_translate  - Moves from input 
location before turbulence generated.  Internally x|y|z - floats(s)

Today we have ambiguity with just turbulence <vector>. In straight 
turbulence it means it_magnitude. In fog - POV-Ray proper - it means 
it_scale(2). In other places it means wave modification frequency 
multiplication because of what the magnitude multiplication sees post 
value(s) multiplication. Trying to make each sort explicit over time.

Bill P.

(1) - We've hit similar issues before with dynamic_cast. It's really, 
really slow.

(2) - Frequency scaling is missing from our pattern 'magnitude' 
turbulence today which is why you see people do things like:

scale 5/1  // scaling the whole mess up.
warp { turbulence... }
scale 1/5 // scaling the whole mess back down.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 5/7/20 9:45 PM, William F Pokorny wrote:
> ...
> > In a surprise, I expected f_agate() to be a little slower than the
> > inbuilt used as a pattern in a pigment, for example. It's running about
> > 16% faster for reasons not currently understood. This the first pattern
> > where - other than f_dents which is cheap - the inbuilt function
> > implementation can match the pattern one exactly. (My f_granite23
> > inbuilt doesn't match granite.) A mystery for another day.
> ...
>
> A significant part of the performance degrade in the normal agate
> pattern looks to be due the use of a dynamic_cast(1) while it checks
> which turbulence warp exists / is the internal agate one. So, other
> special turbulence patterns likely have this slow down too - though I've
> not tested them.

You mean this train wreck of a C++ function that is abusing dynamic cast for a
type check?

bool AgatePattern::Precompute()
{
    return (!warps.empty() && dynamic_cast<ClassicTurbulence*>(*warps.begin()));
}

Oh hell, if the remaining code was turned into such a pile of junk :-( :-( :-(

Post a reply to this message

On 6/4/20 5:06 PM, Thorsten Froehlich wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>>
>> A significant part of the performance degrade in the normal agate
>> pattern looks to be due the use of a dynamic_cast(1) while it checks
>> which turbulence warp exists / is the internal agate one. So, other
>> special turbulence patterns likely have this slow down too - though I've
>> not tested them.
> 
> You mean this train wreck of a C++ function that is abusing dynamic cast for a
> type check?
> 
> bool AgatePattern::Precompute()
> {
>      return (!warps.empty() && dynamic_cast<ClassicTurbulence*>(*warps.begin()));
> }
> 
...
Similar. For agate most of the impact looks to me to be from:

static inline const ClassicTurbulence *GetTurb(const WarpList warps)
{
     POV_PATTERN_ASSERT(!warps.empty());
     POV_PATTERN_ASSERT(dynamic_cast<const 
ClassicTurbulence*>(*warps.begin()));
     return static_cast<const ClassicTurbulence*>(*warps.begin());
}

as it gets called - or probably 'run' as it's inlined - each time the 
agate pattern is evaluated at a point.

After a couple times finding dynamic_cast to be big performance hits, 
Christoph took a pass removing them from the ray tracing paths, leaving 
the majority of uses in the parsing code. But, some still exist in other 
than the parser. In the csg code there is still a cluster of them as I 
recall.

Bill P.

Post a reply to this message

On 6/5/20 6:43 AM, William F Pokorny wrote:
> ...
> Similar. For agate most of the impact looks to me to be from:
> 
> static inline const ClassicTurbulence *GetTurb(const WarpList warps)
> {


> ClassicTurbulence*>(*warps.begin()));

> }
> 
...

Couple coffees and now wondering if some of what I see is just that I 
have that pattern assert on...

In any case, my plan is to slowly remove the special turbulence 
handling. If I remember, I'll look at agate vs f_agate performance again 
when I get back to pattern cleanup work again. Focused elsewhere at the 
moment.

Bill P.

Post a reply to this message