Periodicity along diagonal about webgl-noise HOT 6 CLOSED

Yes, this is a known issue, and unfortunately it's a tough nut to crack. Planar cuts through 3D noise are problematic, even for the simplex grid. (It's much worse than this for the "classic" axis-aligned grid.) Try adding some small slope in z to the cut, and the problem might be much less pronounced: n = snoise(vec3(coords.xy, coords.x*0.2); Even using "n = snoise(coords.xy, 0.0)" instead of n=snoise(0.0, coords.xy) could have a positive effect. X, Y and Z are treated slightly differently in the hash value computation. As for the 2D case, well, the permutation is far from optimal - it's not even particularly good. We just settled for something that was "good enough" for most practical purposes and lent itself to implementation within the limited integer range of 32-bit float values. Our original article contains details on how the permutation polynomial is constructed, and why we chose 289 (17*17) as the period. A larger period is perfectly possible, and there may be polynomials that make less objectionable visual patterns, but it's tricky to find them, and the choices are not all that many if you want to use "float" which has an effective integer range equivalent to 23 bits. (Larger numbers chop off some of the least significant bits in the integer, which makes any hash function break down.) Switching to 32-bit integers would make the problem a lot easier, but our goal was to keep it compatible with OpenGL ES and WebGL, where integers are still not available in most implementations. A real 32-bit integer data type and logical operations (AND, OR, XOR) would make it possible to use a more traditional integer hash function, of which there are many variants published by other authors. Some links that may or may not be useful to you: www.cs.utah.edu/~aek/research/noise.pdf This article points out the cause of the problem you found, but implements a fix using permutation tables, which are undesirable for SIMD implementations because of memory accesses. https://briansharpe.wordpress.com/2011/10/01/gpu-texture-free-noise/ This also points to the problem you found, but offers no solution. https://umbcgaim.wordpress.com/2010/07/01/gpu-random-numbers/ Presents a solution requiring 32-bit integer math. (Lots of similar hash functions, some even simpler, exist in literature.) www.sinfocol.org/archivos/2009/11/Goulburn06.pdf Presents the Goulburn function, which has very good "randomness" but takes a fair amout of cycles to compute. It also uses an in-memory table, even though its use might be optional in this particular application. Note that avoiding memory accesses at all costs is not always a good idea. The traditional method of using a permutation table lends itself quite well to implementation as a texture lookup. If you have texture bandwidth to spare, a texture access might actually be faster than a permutation function on current generation GPUs. You can compare the speed in this test: http://www.itn.liu.se/~stegu/simplexnoise/GLSL-noise-vs-noise.zip http://www.itn.liu.se/~stegu/simplexnoise/GLSL-noise-vs-noise-Win32.zip /Stefan Gustavson