Yes, exactly, I found the same. I'm quite relieved your experience
mirrors mine as otherwise I've just been wasting a lot of my time! :)
Would love you to beta test when it's ready (if you're interested).
A
On 27/04/2017 11:17, Christopher Crouzet wrote:
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 to softimage-requ...@listproc.autodesk.com with
"unsubscribe" in the subject, and reply to confirm.
------
Softimage Mailing List.
To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with
"unsubscribe" in the subject, and reply to confirm.
