beeemtee Posted June 30, 2012 Share Posted June 30, 2012 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 Quote Link to comment Share on other sites More sharing options...
bunker Posted July 1, 2012 Share Posted July 1, 2012 (edited) 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 July 1, 2012 by bunker Quote Link to comment Share on other sites More sharing options...
beeemtee Posted July 2, 2012 Author Share Posted July 2, 2012 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. Quote Link to comment Share on other sites More sharing options...
old school Posted July 3, 2012 Share Posted July 3, 2012 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. Quote Link to comment Share on other sites More sharing options...
beeemtee Posted July 3, 2012 Author Share Posted July 3, 2012 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 Quote Link to comment Share on other sites More sharing options...
old school Posted July 3, 2012 Share Posted July 3, 2012 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 Quote Link to comment Share on other sites More sharing options...
beeemtee Posted July 3, 2012 Author Share Posted July 3, 2012 Ok, I will submit it. Thanks for your help! Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 4, 2012 Share Posted July 4, 2012 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. 1 Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 4, 2012 Share Posted July 4, 2012 Bug and fix submitted (ID:49911). Quote Link to comment Share on other sites More sharing options...
beeemtee Posted July 5, 2012 Author Share Posted July 5, 2012 Thanks Mario! Please check - if you didn't already - (perlin, 4d-in, 1d-out) since it also seems corrupted. Mate unified_noise_analyze_with_chops_perlin.hip Quote Link to comment Share on other sites More sharing options...
Mario Marengo Posted July 5, 2012 Share Posted July 5, 2012 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? ). As an aside, I'd recommend using simplex over perlin from now on, if you can. Thanks for catching these! 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.