Hello,
I’m not really getting a normalized output from the scalar function, even with the normalize toggle on - looking at the debug window, I’d expect min/med/max values of about 0/.5/1.
Its normalized to [-1, 1]. You can add 1 then divide by 2 to get [0, 1] if you’d like.
And the reason is to keep it consistent with Vector Noise which would make no sense producing values between [0,0,0] and [1,1,1] as it would exclude all negative axes. So Vector Noise normalizes the X,Y and Z between -1 and 1, and the (scalar) Noise produces a Float between -1 and 1 when normalized.
Yep, that’s what I’d expect. But I get this:
dropbox.com/s/cxq94mu9cxvy1 … .27.34.png
With a 0 : 1 input, the output is in the -0.15 : 0.076 range.
It depends on two things - the input value, and the Octaves. If I have Octaves set to 1 and the input value divided by, say, 10.0, I get Min and Max values between -1.0 and 1.0.
As you increase the number of the Octaves, multiple layers of noise come together (this is similar to the Levels property in Max Noise maps) and the values get averaged and of course never reach the peaks of a single layer.
Also, as you increase the division number of the input value, the output seems to get lower and lower. Going from 10.0 to 100.0 reduces the Min. and Max. to -0.9378 / +0.9378, but they are still very close to 1.0. Dividing by 1000.0 produces -0.39119/0.39119 and so on.
If I disable Normalize and have a single Octave, it still produces a the same value between -1 and 1. But if I increase the number of Octaves, the resulting Noise can go out of that range (for example with a divisor of 10.0), but not always (with higher Divisors).
I am not sure exactly how the input affects the output (hope Darcy can clarify what I am seeing), but it seems that the Normalize option is good for certain pure settings and simply ensures the output will never be below -1 or higher than 1, but does not guarantee there WILL be such values anywhere… After all, Noise is supposed to produce variable values, so Normalizing is not the same as with Scalars or Vectors.
You might want to just divide yourself behind the Noise with a value that produces what you want to see, and/or Clamp the output between the desired values.
Ok, I think I understand. Post dividing it looks like a good solution. Thanks!
As Bobo mentioned, the octaves & input values will definitely affect the results.
The octaves parameter determines how many layers of Noise are added (and each layer is weighted by half as much as the last by default), so with 4 octaves without normalization you could get a value of 1+.5+.25+.125 = 1.875 if everything lined up just perfectly. That being said, it really depends on what input values you offer since getting the maximum value for all layers at once is pretty unlikely. The normalize setting just automatically inserts a divide by 1.875 in this case.
The noise output is unique in the [0,256) range for the highest layer, and is 0 at every fully integer location ( ex. [1,2,3], but not [1.1, 2.2, 3.3] ). Therefore noise at [256,0,512] is exactly the same as [0,0,0].
Dividing your input is essentially the same as fitting it into a smaller and smaller region of the noise field so you should expect to have less variance. The exact numbers you are going to converge to are dependent on where in the [0,256) you are going towards. Just dividing without also adding a translation will move your points towards [0,0,0] and whatever the noise value is in that region.
Keep in mind that the corners of any integer cube are always 0, so there is only so much variation that can occur in between. You want to multiply your inputs in order to get more variation, while dividing them to get less variation.
Now that’s interesting, thanks! In the case of driving it with the magma index channel then, it should still be divided, to avoid the integers, right? And you can divide by particle count / 256, to put the index in the 0-256 range?