3D simplex noise exhibiting spacial artifacts not found in 2D simplex noise

[timscaffidi]

Hi,I've notice that the 3D snoise function produces very noticeable diagonal streaking that doesn't seem to appear (or not as noticeably) in the 2D snoise.

Compare the following revisions of this sandbox sketch:
2D Simplex
3D Simplex

The streaks exist in the 3D version even without an animation (just setting the z component to a constant).

Why does this happen and is there a way to minimize the effect?

[stegu]

The pattern becomes different, and possibly better, if you use the (y,z) or
(x,z) plane for the planar slice , i.e use snoise(position.x, time_0.25,
position.y) or snoise(time_0.25, position).

The fundamental problem is that the randomization is not good enough. There
is still some residual correlation in the gradients. ​Designing a good
gradient hash function is more or less a black art. There are statistical
measures for how "good" a permutation is in terms of decorrelation, but the
constraints here are rather severe. It is not just a matter of changing a
permutation table, it needs to be a permutation polynomial, and I have no
good ideas on exactly how to improve it.

/Stefan Gustavson

[unicomp21]

Not as sexy as pure simplex noise, but a viable approach for 3D noise.

http://http.developer.nvidia.com/GPUGems/gpugems_ch05.html

[stegu]

I did a very similar texture-based GLSL implementation back in 2004. It is
linked from the Github wiki:

http://www.itn.liu.se/~stegu/simplexnoise/GLSL-noise-vs-noise-Win32.zip

To my disappointment, that ten year old version is still faster on most
high performance GPUs, and can be made to look better because of the lack
of restrictions on the permutation table.

[unicomp21]

Why don't we create a new github project for it?

On Saturday, July 12, 2014, Stefan Gustavson notifications@github.com
wrote:

I did a very similar texture-based GLSL implementation back in 2004. It is
linked from the Github wiki:

http://www.itn.liu.se/~stegu/simplexnoise/GLSL-noise-vs-noise-Win32.zip

To my disappointment, that ten year old version is still faster on most
high performance GPUs, and can be made to look better because of the lack
of restrictions on the permutation table.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[stegu]

We could do that, but that old code is not nearly as easily pluggable as
the pure GLSL version. It requires a special texture that is created at
startup by CPU code. The current version also contains the archaic
weirdness of float indexing of float values in a texture to perform what is
actually pure integer operations. In all, I would consider it more of an
ugly hack than the pure computational version.

[unicomp21]

Got it, thanks!

On Sun, Jul 13, 2014 at 5:39 AM, Stefan Gustavson notifications@github.com
wrote:

We could do that, but that old code is not nearly as easily pluggable as
the pure GLSL version. It requires a special texture that is created at
startup by CPU code. The current version also contains the archaic
weirdness of float indexing of float values in a texture to perform what is
actually pure integer operations. In all, I would consider it more of an
ugly hack than the pure computational version.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[unicomp21]

Actually, just realized there was a bunch of other stuff on that page, I was referring to the "Fast Noise" toroidal approach ie pnoise folded back on itself, leveraging the trilinear part of the asic.

[unicomp21]

Stefan, is there any faster way to perturb normals than taking 3-4 samples?

http://http.developer.nvidia.com/GPUGems/gpugems_ch05.html

On Sun, Jul 13, 2014 at 5:54 AM, John Davis jdavis@pcprogramming.com
wrote:

Got it, thanks!

On Sun, Jul 13, 2014 at 5:39 AM, Stefan Gustavson <
notifications@github.com> wrote:

We could do that, but that old code is not nearly as easily pluggable as
the pure GLSL version. It requires a special texture that is created at
startup by CPU code. The current version also contains the archaic
weirdness of float indexing of float values in a texture to perform what
is
actually pure integer operations. In all, I would consider it more of an
ugly hack than the pure computational version.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[stegu]

Note my upload of "psrdnoise2D.glsl" yesterday. Analytical derivatives are reasonably straightforward to compute for simplex noise in all dimensions. There's also another open issue in this tracker about gradients for 3D noise. That thread contains a solution to computing the gradient of 3D noise.

[jjxtra]

What are the odds of a psrdnoise3D.glsl being created?

[stegu]

I made a C version of 3D flow noise back in 2005 or thereabouts, but it's kind of ugly, in the sense that the gradients are not strictly uncorrelated through the rotations, making it at least potentially unsuitable for particle flow animations. I never had anyone express any interest in it, so I dropped it. It did look OK when used for 3D texturing, though. If you think a GLSL version would be useful, I would say the odds of it being created are at least fair. I have some time on my hands over the next few weeks. I will use some of it to take a good look at my old C code and try to port it to GLSL.

[jjxtra]

@stegu If you do get it, let me know I will tip you a LARGE beer

[stegu]

I'm still trying to find time (and, more importantly, focus) to actually sit down and code this. I have an algorithm for "psrdnoise3D.glsl" worked out since months back, and it's not much more computationally intensive than plain 3D simplex noise with gradients. The conundrum of finding a simplex grid that still tiles over rectangular periods is solved, with some slight restrictions on the choice of period. So, you could say I'm currently at the point of having a solution for "psdnoise3D.glsl", without the "r" part, although not yet coded in GLSL. However, I still need to find a permutation function to create a good distribution of gradient rotation axes for the 3D "swirling" motion. My first naive attempt did not turn out well, but that can be fixed. Probably even "brute force and ignorance" will do the trick, just testing a lot of variations to see what works.

[stegu]

I am sorry to say that I have been hit with a rather bad case of "long haul Covid-19", and my recovery is very slow. One of the symptoms is a rather severe mental fatigue, and I can't even focus long enough to do any coding right now. I will be on sick leave for a good while longer, from the look of it. I hope to have my brain back again soon, because I am utterly bored without it, but at the moment, nothing is happening with this issue.

[unicomp21]

@stegu I am so sorry to hear this, hope you get to feeling better soon.

My father also got hit w/ covid, his health wasn't that great to begin with, so he was at a disadvantage.
http://c100k.blogspot.com/2020/12/covid-happens.html

Does adding an offset, and keeping all coordinates positive fix the issue? I seem to remember this helping.

For anyone interested, there are some nice periodic implementations, but not as fast, over in https://github.com/aqsis/aqsis/blob/883cc9e027108d596437e231f6d05ef01d0cdda8/libs/math/noise.cpp

[unicomp21]

The point I'm trying to make above, is much can be done w/ tiled, in memory, noise textures.

[stegu]

Textures are certainly good for many applications, even as part of the toolbox to create better permutations with a more "controlled" randomness, so to speak. Designers of high-end GPU architectures spend a lot of effort on making the texture subsystem fast and efficient, and in many cases it's detrimental to performance if you don't make good use of that resource. However, the point of this repository is to provide purely computational noise, for the applications where that is to be preferred, so I won't dive too deeply into the use of textures here.

[stegu]

A functioning "psrdnoise3D.glsl" now exists, but I will submit a journal article about it before I publish it here. Pardon the hassle, but this was non-trivial enough to at least try getting it published in a peer reviewed journal. The article is being written, and I will not dally, but if you want a preview of the function, let me know and I can send it to you in "private confidential communication". For legal purposes, that would require you to give me a "real" e-mail contact address. Sending it through the GitHub messaging system would make it untraceable. Please send your contact information to "stefan.gustavson@gmail.com".

[unicomp21]

@stegu will it be open source? Can I use it for this task I have open in babylon.js?

BabylonJS/Babylon.js#10446

[unicomp21]

@stegu So I can buy a copy, which journal?

[stegu]

In the middle of that wall of text, I wrote: "It will be an MIT license like the rest of my GLSL noise functions." So, yes. Just keeping it a little under cover for now. I'm aiming for JCGT (http://jcgt.org/), because they are quick, well respected and widely read, but I don't know if it will be accepted. They are an open access online journal, no need to buy anything if they decide to accept. But they are pretty picky with their content, so I might be aiming too high. We'll see.

[stegu]

While waiting for the article review, I have retrofitted one important change to the permutations that should reduce the problems with diagonal streaks quite considerably. I am not sure they are eliminated, but they are definitely a lot less common. All functions in the repo have been updated.

[unicomp21]

Thanks! Currently I’m away from keyboard, in Alaska. Does this apply to 4d noise too?

…

On Tue, Jun 29, 2021 at 1:33 AM Stefan Gustavson ***@***.***> wrote: While waiting for the article review, I have retrofitted one important change to the permutations that should reduce the problems with diagonal streaks quite considerably. I am not sure they are eliminated, but they are definitely a lot less common. All functions in the repo have been updated. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEFL7L45WR3I43663LXNADTVGHOLANCNFSM4ARH2OYA> .

[unicomp21]

With respect to calculating gradients, has anything changed?

…

On Tue, Jun 29, 2021 at 5:23 AM John Davis ***@***.***> wrote: Thanks! Currently I’m away from keyboard, in Alaska. Does this apply to 4d noise too? On Tue, Jun 29, 2021 at 1:33 AM Stefan Gustavson ***@***.***> wrote: > While waiting for the article review, I have retrofitted one important > change to the permutations that should reduce the problems with diagonal > streaks quite considerably. I am not sure they are eliminated, but they are > definitely a lot less common. All functions in the repo have been updated. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#10 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEFL7L45WR3I43663LXNADTVGHOLANCNFSM4ARH2OYA> > . >

[stegu]

Basically everything has changed in the new and improved version, but the repo doesn't have it yet, as the article about it is still under review and I need to keep the code reasonably under wraps a little while longer. I just changed the permutation, which was a very small but important change that should get rid of the most prominent flaw of the old version. All version of all kinds of noise are affected by this change, and hopefully improved as well. I have not tested 4-D noise properly in all planes all across its huge domain, but please tell me if there are problems with it still. What will arrive once the article is accepted for publication somewhere is 2-D and 3-D versions of periodic (tiling) simplex noise with a very flexible choice of tile size, an option to rotate the gradients in place à la "flow noise", extended to 3-D, with analytic gradients and (optionally) analytic second order derivatives. An updated version of 4-D noise is not planned for the short term, but some of the changes, like the periodicity and the analytic gradient, can most likely be retrofitted with a reasonable effort. The 3-D tiling grid and the "flow noise" option can each solve some of the problems that previously required 4-D noise, so you might want to have a look at that. /Stefan

[stegu]

JCGT article to appear soon. These things take time, unfortunately, but now the article is accepted, only awaiting final approval after some wisely suggested revisions, and then it's time for a final touch-up session with the language editor. Yes, JCGT has a language editor, even though they are an open access journal run on a very low budget on a volunteer basis. Their peer reviewers were awesome as well. It really is a great journal.

[unicomp21]

@stegu is it ok to start using it publicly? (the email version) Or better to wait? I'm starting to play around w/ webgpu.

[stegu]

Still awaiting a formal final approval. Once it's formally cleared, I'm fine with having the code appear in public with a note "to appear" rather than "as seen in". It should only be a matter of days now. The editor-in-chief is making his final read-through. I'll let you know, and then I will hopefully have an expected publication date as well. Thanks for your patience. I have a bunch of fun demos I am itching to put online as well. If you feel like sending me some links to interesting experiments, we can list them in the repository. I will most likely be updating that Github repo (TBA) regularly with my own demos and tutorials over the next few months. Den sön 14 nov. 2021 13:21John Davis ***@***.***> skrev:

…

@stegu <https://github.com/stegu> is it ok to start using it publicly? (the email version) Or better to wait? I'm starting to play around w/ webgpu. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFGK2RJUMJIT5T2DWI7KQ3UL6SSZANCNFSM4ARH2OYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[unicomp21]

@stegu no worries. Thanks for this incredible gift to the planet. If I'm lucky enough to create a noteworthy demo, I'll be sure and share it. Thanks!

[stegu]

Entering final editing phase for that article. Publishing is a slow grind, but I want peer review publications to maintain a high standard, and being unhurried is a good and proven way. The repo is going to be github.com/stegu/psrdnoise/, but the 3-D code isn't there yet. Real soon now...