I've just tried what you said and in fact the unified noise
doesn't even seem to use the full [0, 1] range as one would
expect from reading the doc. At least not in H13. Or maybe I did
something wrong. If this turns out to be true, it'd kill the
primary purpose of the node to bring coherency between the
different noise types. Not great for lookdev as you said.
This bring back blurry memories where I digged into the unified
noise a couple of years ago and ended up coding my own, maybe
because of this exact reason. But then I eventually lost the
digital asset that I had built and ended up using the default
noises instead :)
On 27 April 2017 at 16:42, Andy Nicholas <a...@andynicholas.com
<mailto:a...@andynicholas.com>> wrote:
The `Unified Noise VOP`, which is a fairly useful node that
outputs all the noise values in the [0, 1] range, takes
pretty much all of its logic from the `pyro_noise.h` include
file. Which means that you can easily have access to the
same functionalities in VEX, like so:
#include <pyro_noise.h>
v@perlin = vnwrap_perlin3(v@P, 0, 0);
f@pflow = fnwrap_pflow1(v@P, {1, 2, 3}, 0);
Aah, thanks for that Chris. Didn't realise you could access
the noise functions like that. Good to know :)
Also, it's interesting to see how they managed to unify the
noise values in `pyro_noise.h`: they basically ran a lot of
samples and picked the min/max values of each noise to
approximate their range. Statistics for the win! :)
Yep, that's what I've been doing. I'm concentrating on FBM
modes of evaluating the basic noise functions (noise(),
xnoise(), snoise(), onoise(), anoise) as that's what I tend
to use the most. Unified Noise is okay, but I still find
problems with shifting offsets in the noise.
For example, make a grid with 150 divisions, create a Unified
Noise in a Point VOP and set it to use Signature:->"3D Input,
3D noise", Noise Type->"Perlin", Fractal Type "Standard
(fBm)" add the vector output to the point position and then
try playing around with the Max Octaves, Lacunarity, and
Roughness. You'll see that you get a global uniform "DC"
offset along the each axis. That's not cool! If I'm using
that as a noise force, then it has just pushed all my
particles in the (1,1,1) direction. You'll also find that
switching between noise types noticably changes the amplitude
range. Again, not great if I'm doing lookdev and I just want
to try a different noise type without changing the general
magnitude force amount.
In addition to sampling the noise values, I'm doing some
curve fitting to that data in Python's scipy which smooths
out some of the statistical glitches with the sampling. It's
giving some good results that don't exhibit the DC offset
that I mentioned above. All this should let me create a
replacement for the Anti-Aliased Noise VOP. I'm not dealing
with the anti-aliasing aspect yet though, so it won't be as
good for shaders, but the offset isn't quite so important in
that context as it is for using it for forces.
Still need to do some testing and then package them up into
VOPs, but once they're ready I'll release them in siLib for
everyone to try.
A
------
Softimage Mailing List.
To unsubscribe, send a mail to
softimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with
"unsubscribe" in the subject, and reply to confirm.
--
Christopher Crouzet
/https://christophercrouzet.com/
------
Softimage Mailing List.
To unsubscribe, send a mail tosoftimage-requ...@listproc.autodesk.com
<mailto:softimage-requ...@listproc.autodesk.com> with "unsubscribe" in the
subject, and reply to confirm.
