Jump to content

Unified Noise problem


Recommended Posts

Hi,

if the input signature of the Unified Noise VOP is vector4, the noise type is Perlin

or Simplex and the fractal type is other than None the output is biased, so that the

average of the resulting noise is not around 0.5 but some higher value. It is also

apparent that in these cases the average that Unified Noise outputs is considerably

different - around the half of - that the calculated average by Attrib Promote.

For the sake of simplicity I used Pyro Noise in the attached file, but my tests shows

that the problem is rooted in Unified Noise.

My question is that is it a bug or some inevitable implementation side effect (no pun

intended)?

thanks in advance

Mate

unified_noise_problem.hip

Link to comment
Share on other sites

That's not a bug. Each type of noise output different min/max values. Have a look at "turbulent noise" in the help, to see their ranges. Use "fit range" with the relevant min/max values if you need the noise output normalized.

For the sake of simplicity, use a "Turbulent Noise" or "Anti-Aliased Noise" instead :)

Edited by bunker
Link to comment
Share on other sites

Thanks Julien, but my question is about some specific settings of the Unified Noise operator which is intended to output its results in the 0-1 range for every noise and fractal types. Actually it's not the output range that is incorrect, but the average (middle point) of the result, which is harder to detect, but can cause strange results later in your scene if you expect it to be in the middle.

Link to comment
Share on other sites

Noise functions are not random noise generators. You can't assume that the average value or the power of the noise function will be in the middle of the range. Every noise function has it's own characteristic behaviours. For me the power of the function is far more important than the median value as it gives you a better interpretation of the function.

I attached a simple file that uses CHOPs to analyze the results from the Unified Noise VOP. No real surprises really. All of the perlin and simplex noises have average values around 0.5 and reasonable min-max values knowing the perlin and simplex functions.

unified_noise_analyze_with_chops.hip

As for the cell type noises (worley and alligator), the average value is well below 0.5. As expected, the two worley noises are all about the distance between cell values and can fluctuate based on the frequency (distance between cell points) while all the other noises tend to go from 0-1 (given the noise function behaviour). The Alligator cell noise does extend from 0-1 if you want cell noise with the average value below 0.25 again as expected.

So the 0-1 min-max works where it should (perlin usually goes from 0.1-0.9 and is in keeping with this function) and doesn't where it doesn't (worley noises).

Median average values? Again hovering around 0.5 for the perlins and simplexes but not for the cell based noise functions.

Link to comment
Share on other sites

Thanks Jeff!

I attached a modified version of your file with the signature of the

Unified Noise set to f4 (vector4 input float output) and the fractal

type set to fBm (I left the noise type at Simplex). This is one of the

cases where the problem is present.

ps.: I forgot to mention in my original post that the output signature

must be float to see the problem.

unified_noise_analyze_with_chops_problematic.hip

Link to comment
Share on other sites

Yep I see the issue.

Please submit the issue in to Support and see what is up with this.

Works fine with a float input but with vector input where the second and third elements of the vector are constants gives inconsistent results with the min and max ranges.

-jeff

Link to comment
Share on other sites

Ok, I will submit it. Thanks for your help!

Huh. Seems like there was a little hiccup when auto-generating the stats tables.

Not sure what happened there, but the "running mean" value (which is not necessarily the same as the average of the minimum and maximum values encountered -- it is the mean over approx 5 million samples) for the ns_fsimplex4 wrapper didn't get calculated properly or got corrupted somehow (it got assigned a value of 0.294652 which is clearly wrong).

These tables were generated automatically and are used by the algorithm to "normalize" the output to [0,1] (while spanning as much of that range as possible). The biasing you're seeing in that particular flavor of noise (simplex, 4d-IN, 1d-OUT) is due to this flawed entry in the tables.

I haven't checked lately so this may have been corrected already by SESI, but I'll post the BUG just in case anyway.

In the meantime, if you need a fix "right now", you can change one value in the file $HH/vex/include/pyro_noise.h as follows (you may need to change permissions on that file to be able to edit it):

At lines 403-404, where it currently reads:

#define ns_fsimplex4   \
   nsdata ( "simplex"   , 0.0943673  , 0.912882 , 0.294652  , 1 ) // +/- 0.0064

should instead read:

#define ns_fsimplex4   \
   nsdata ( "simplex"   , 0.0943673  , 0.912882 , 0.503625  , 1 ) // +/- 0.0064

This new mean value of 0.503625 may not be super accurate (it's just the average of the min and max) but all simplex means hover around 0.5 anyway so it couldn't be too far wrong either.

Hope that helps.

  • Like 1
Link to comment
Share on other sites

Thanks Mario!

Please check - if you didn't already - (perlin, 4d-in, 1d-out) since it also seems corrupted.

Mate

Yes, 4d->perlin->1d and 4d->perlin->3d included.

Again, if you need to patch by hand right now, these additional two changes are:

At lines 395-398, where it currently reads:

#define ns_fperlin4    \
   nsdata ( "perlin"    , 0.0168713  , 0.998413 , 0.324666  , 1 ) // +/- 0.0073
#define ns_vperlin4    \
   nsdata ( "perlin"    , 0.00576016 , 1.025    , 0.32356   , 1 ) // +/- 0.0037

It should instead read:

#define ns_fperlin4    \
   nsdata ( "perlin"    , 0.0168713  , 0.998413 , 0.507642  , 1 ) // +/- 0.0073
#define ns_vperlin4    \
   nsdata ( "perlin"    , 0.00576016 , 1.025    , 0.518260  , 1 ) // +/- 0.0037

The rest of the 4d stats look OK -- and it was the 4D batch that was compromised for some reason (maybe because I ran it in Windows? :P).

As an aside, I'd recommend using simplex over perlin from now on, if you can.

Thanks for catching these!

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...