POV-Ray : Newsgroups : povray.beta-test : v3.8 Clean up TODOs. kNoiseGen_Default switch use. Server Time
14 Oct 2024 04:13:44 EDT (-0400)
  v3.8 Clean up TODOs. kNoiseGen_Default switch use. (Message 1 to 2 of 2)  
From: William F Pokorny
Subject: v3.8 Clean up TODOs. kNoiseGen_Default switch use.
Date: 4 Apr 2020 06:26:12
Message: <5e8860c4$1@news.povray.org>
Documenting some cleanup which I think should happen on any resumption 
of v3.8 work. It's work I am doing in my cut down povr.

In working on pattern / function handling changes (documented mostly in 
the non-web presented newsgroup povray.beta-test.binaries(1)) the 
following code caught my eye in the granite pattern:

         switch (noise_generator)
         {
             case kNoiseGen_Default:  // <---- ????
             case kNoiseGen_Original:
                 temp = 0.5 - Noise (tv2, noise_generator);
                 temp = fabs(temp);
                 break;

             default:
                 temp = 1.0 - 2.0 * Noise (tv2, noise_generator);
                 temp = fabs(temp);
                 if (temp>0.5) temp=0.5;
                 break;
         }

kNoiseGen_Default "Indicates that the scene's global settings noise 
generator should be used." It's not the local pattern noise default
and should not be used as such. The coding is harmless to result, but 
not completely to performance - the case statement should be removed and 
also in wrinkles. Perhaps there are other such uses - turbulence??? Not 
looked.

The above issue got me looking more at the noise code and CPU specific 
optimizations. The AMD optimization file:

       platform/x86/avxfma4/avxfma4noise.cpp

is missing the #if CHECK_FUNCTIONAL test blocks comparing results to the 
non-optimized portable Noise and DNoise code which exists in the other 
optimization files. Looks like the check existed when Noise / DNoise was 
in texture.cpp - so this I think missed when the file above was created 
in the v3.8 / master branch.

Lastly, I'll ramble a little about what look to me to be less than clear 
statements in comments about mean, media and ranges which led me to take 
detailed looks at the distributions on my machine 
(platform/x86/avx2fma3/avx2fma3noise.cpp). All three generators end up 
with gaussian like distributions centered near 0.5 and in a 0-1 range as 
expected.

The Perlin-Skinner distributions are a little asymmetric, but smoother 
than the implemented Perlin version. All three have still visible 
artifacts, though the current generator 2 default is the best in this 
respect.

Aside: In the granite call I coded up a version which alternates between 
Perlin and Perlin-Skinner(2) as it sums up the scaled, fractional noise 
and to me looks really good artefact wise. Have others tried this? 
Thinking I might keep it as a noise option in my cut down povr code. 
We'll see.

Bill P.

(1) - Partial lie as images to this group show up in the 100 most recent 
images group until no longer in the most recent 100. I started to use 
the group so as not to present noise to most web interface users while 
still storing what I see where other hackers / developers (and I) can 
find stuff by news group search...

(2) - Granite introduces clamping as part of the pattern. (Something 
never really optimized for Perlin(3) it looks. Perhaps the Skinner(2) 
clamping good enough with Perlin too?)


Post a reply to this message

From: clipka
Subject: Re: v3.8 Clean up TODOs. kNoiseGen_Default switch use.
Date: 29 May 2021 17:15:00
Message: <web.60b2ae15c40d1d79860b50e9afff112@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
> Documenting some cleanup which I think should happen on any resumption
> of v3.8 work. It's work I am doing in my cut down povr.
>
> In working on pattern / function handling changes (documented mostly in
> the non-web presented newsgroup povray.beta-test.binaries(1)) the
> following code caught my eye in the granite pattern:
>
>          switch (noise_generator)
>          {
>              case kNoiseGen_Default:  // <---- ????
>              case kNoiseGen_Original:
>                  temp = 0.5 - Noise (tv2, noise_generator);
>                  temp = fabs(temp);
>                  break;
>
>              default:
>                  temp = 1.0 - 2.0 * Noise (tv2, noise_generator);
>                  temp = fabs(temp);
>                  if (temp>0.5) temp=0.5;
>                  break;
>          }
>
> kNoiseGen_Default "Indicates that the scene's global settings noise
> generator should be used." It's not the local pattern noise default
> and should not be used as such. The coding is harmless to result, but
> not completely to performance - the case statement should be removed and
> also in wrinkles. Perhaps there are other such uses - turbulence??? Not
> looked.

I should note that the documentation of `kNoiseGen_Default` is probably not
authoritative. Judging by the comment style, it was probably added by me, and
I'm sure I did so to document my understanding of things at the time I added
them, which may have be flawed. (Of course, today I understand every jot of the
code...)

It is entirely possible that `kNoiseGen_Default` is used for multiple
independent things that use noise generators, and used in the documented sense
in some places, and in other senses elsewhere.


> The above issue got me looking more at the noise code and CPU specific
> optimizations. The AMD optimization file:
>
>        platform/x86/avxfma4/avxfma4noise.cpp
>
> is missing the #if CHECK_FUNCTIONAL test blocks comparing results to the
> non-optimized portable Noise and DNoise code which exists in the other
> optimization files. Looks like the check existed when Noise / DNoise was
> in texture.cpp - so this I think missed when the file above was created
> in the v3.8 / master branch.

To the best of my knowledge, the `CHECK_FUNCTIONAL` stuff is an artifact of the
approach Intel used on their end back in the days to make sure the optimized
code variants they provided for the AVX instruction sets were faithful to the
original unoptimized code, apparently testing the function "on the job" in a
living POV-Ray build, rather than in a dedicated testbed. when they later
adapted the code to optimize it for the AVX2/FMA3 instruction set, they seem to
have simply left it in there, or re-used it for the very same purpose. This is
also the reason why I never bothered to throw it out: Don't fuss with code that
some 3rd party provided for us, in case we ever want them to re-visit their
code.

Their counterparts at AMD, who provided the AVX/FMA4 optimizations, presumably
started from the original non-optimized noise, and did not use the same approach
for testing, so they had no reason to leave the same kind of artifacts in there.


> Lastly, I'll ramble a little about what look to me to be less than clear
> statements in comments about mean, media and ranges which led me to take
> detailed looks at the distributions on my machine

Welcome to my world: POV-Ray is full of old code that has not been documented at
all, documented vaguely, imprecisely, sometimes wrong or no longer in sync with
the code, and where it is highly precise it tends to also be utterly
incomprehensible for anyone but an expert in the field. And more often than not
the corresponding code is written for maximum performance on antiquated
compilers that provided little in the way of automated optimizations, so the
code itself also tends to be highly unintelligible.

The earliest pieces of the POV-Ray source code are 30 years old now.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.