Yep, Unified Noise is definitely very slow when tweaking the UI
parameters. Haven't done any profiling yet though to see if that's due
to recompiling issues vs actual performance of evaluation.
On 27/04/2017 10:49, Olivier Jeannel wrote:
I found the Unified noise slower than the other noises. No ?
2017-04-27 11:42 GMT+02:00 Andy Nicholas <a...@andynicholas.com
<mailto:a...@andynicholas.com>>:
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.
------
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.
