Ugly artifacts in 2d simplex

[EntityB]

Ugly artifacts in 2d simplex

[stegu]

I can't replicate the bug. If it persists, please submit the entire shader
so I can test it.

I notice that you are doing bump mapping from noise. Simplex noise has a
distinct advantage over regular noise in that it is a sum of easily
differentiable terms, and its analytic derivative can be computed easily
with a low order polynomial. For a 2D version of simplex noise in GLSL with
an analytic derivative, have a look at the "flow noise" in this demo:

http://www.itn.liu.se/~stegu/gpunoise/

I have not made a GLSL version of 3D noise with analytic derivatives, but
the differentiation is quite straightforward and follows the same pattern
as for 2D noise, only with one more term and one more dimension for each
term. Last time I tested it, the speedup compared to computing a finite
difference approximation is around 2x for 2D noise and slightly more for 3D
noise.

/Stefan

On Fri, Dec 12, 2014 at 6:24 PM, EntityB [email protected] wrote:

It is possible that problem with 3d simplex was fixed before and I just
had old implementation.

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

[stegu]

After looking at the code that generated the artifacts, I think the problem is with using
"precision mediump float" instead of "precision highp float". Some platforms choose a 16-bit floating point representation for "mediump", and that will cause problems with the permutation polynomials even quite close to the origin.

[EntityB]

Thank you, everything is working with "precision highp float"!

[EntityB]

Recent events force me to ask, would be possible to reimplement this noise with precision mediump float?

[stegu]

The problem here is that for compatibility with older versions of GLSL and with WebGL, the permutations are done by integer math with floating point variables.

I see no way to make the permutation polynomial method work with a 16-bit floating point representation. The permutation set would then have to be very small to keep the numbers in the range where the integers N and N+1 map to different representations, and the periodic artifacts from using such a small set of gradients would most probably be too strong to be acceptable.

If texture bandwidth is not a problem, I would recommend using the texture-based lookup table for the permutations, as demonstrated by the older version of noise which I link to on the wiki page in the section "Other noise implementations". The texture-heavy version is generally not as fast on mobile platforms, but on desktop GPUs it can actually be about twice as fast as the pure computational version.