snoise(vec3) discontinuities

[ashima]

snoise(vec3) discontinuities

[stegu]

Ah. Line 99: change 0.6 to 0.5. This is an old bug that keeps popping up, sorry. The version I maintain at my own Github repo (stegu) should not have this issue, but I need to check that as well. We had comments that visually, there is a bit too much flat area (zeroes) in 2D slices of 3D simplex noise, hence this slight "fix", which in hindsight was unwise. My newer versions with proper analytical derivatives do not have this bug. Sorry for the confusion. Thanks for reporting this.

…

On Thu, 24 Sep 2020, 16:56 rbnelr, ***@***.***> wrote: Sorry, I meant to say neither show the discontinuities. I tried noise3D.glsl <https://github.com/ashima/webgl-noise/blob/master/src/noise3D.glsl>, which has the issue, while I could not find anything similar when replacing it with either noise2D.glsl <https://github.com/ashima/webgl-noise/blob/master/src/noise2D.glsl> or classicnoise3D.glsl <https://github.com/ashima/webgl-noise/blob/master/src/classicnoise3D.glsl >. I could post my whole shader, but you would need to provide a few uniforms including the camera matrices to use it. I'll try to write a standalone shader that shows the issue. On Thu, Sep 24, 2020 at 11:57 AM Stefan Gustavson < ***@***.***> wrote: > Wait, are you saying that the discontinuities appear on cnoise as well as > snoise? Those are completely different implementations, which makes it even > more puzzling to me. Or was that a typo, and you meant you tried the vec3 > and vec2 versions of snoise? Those are quite similar and might have shared > problems. > > On Thu, 24 Sep 2020, 13:36 Stefan Gustavson, ***@***.*** > > wrote: > > > Could you please provide more detail on this? Show me the code. Note also > > that "noise" in all the flavors presented here were designed for > > satisfactory visual results and speed, and it's bound to have precision > > problems if you look too closely at it. > > > > The images look weird, though. Show me your code and I will try to look > > into this. > > > > > > On Thu, 24 Sep 2020, 02:10 rbnelr, ***@***.***> wrote: > > > >> In my usage of the snoise(vec3) function I easily notice lines of noise > >> value discontinuities in lots of places. > >> See the attached picture. > >> > >> In my use case I use a single layer of the noise, scaled up by 2000, the > >> squares in the image are 1 unit. > >> The discontinuities seems to reach up to 1/1000 units in > >> value-discontinuity relative to the scale of the snoise inputs. > >> In my case this is a significant error that would be hard to hide when > >> used for voxel generation. > >> They appear seemingly everywhere (ie. not just far from the origin). > >> > >> I don't know enough about the math to be able to tell what might be > >> causing this. > >> Although to me this looks like the lines might be corresponding to the > >> simplex cell borders. > >> Although I believe I've ruled out my own code as the source, > >> since I've tried both snoise(vec2) and cnoise(vec3) and neither seem > free > >> from any of these discontinuities. > >> > >> My current use case is a ray marching shader on desktop glsl. > >> > >> [image: issue] > >> < > https://user-images.githubusercontent.com/25484587/94085920-f3aadf80-fdf8-11ea-8582-88997df0efda.png > > > >> > >> — > >> You are receiving this because you are subscribed to this thread. > >> Reply to this email directly, view it on GitHub > >> <#21>, or unsubscribe > >> < > https://github.com/notifications/unsubscribe-auth/AAFGK2VYZUS774R3DEZJDJTSHKFA5ANCNFSM4RXUTPDQ > > > >> . > >> > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#21 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AGCN2K3NRCYPB2SVE2NFKTTSHMX2RANCNFSM4RXUTPDQ > > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFGK2XBZFSZJVVQHR5OD7TSHNMYDANCNFSM4RXUTPDQ> .

[stegu]

Could you please provide more detail on this? Show me the code. Note also that "noise" in all the flavors presented here were designed for satisfactory visual results and speed, and it's bound to have precision problems if you look too closely at it. The images look weird, though. Show me your code and I will try to look into this.

…

On Thu, 24 Sep 2020, 02:10 rbnelr, ***@***.***> wrote: In my usage of the snoise(vec3) function I easily notice lines of noise value discontinuities in lots of places. See the attached picture. In my use case I use a single layer of the noise, scaled up by 2000, the squares in the image are 1 unit. The discontinuities seems to reach up to 1/1000 units in value-discontinuity relative to the scale of the snoise inputs. In my case this is a significant error that would be hard to hide when used for voxel generation. They appear seemingly everywhere (ie. not just far from the origin). I don't know enough about the math to be able to tell what might be causing this. Although to me this looks like the lines might be corresponding to the simplex cell borders. Although I believe I've ruled out my own code as the source, since I've tried both snoise(vec2) and cnoise(vec3) and neither seem free from any of these discontinuities. My current use case is a ray marching shader on desktop glsl. [image: issue] <https://user-images.githubusercontent.com/25484587/94085920-f3aadf80-fdf8-11ea-8582-88997df0efda.png> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#21>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFGK2VYZUS774R3DEZJDJTSHKFA5ANCNFSM4RXUTPDQ> .

[stegu]

Wait, are you saying that the discontinuities appear on cnoise as well as snoise? Those are completely different implementations, which makes it even more puzzling to me. Or was that a typo, and you meant you tried the vec3 and vec2 versions of snoise? Those are quite similar and might have shared problems. On Thu, 24 Sep 2020, 13:36 Stefan Gustavson, <[email protected]> wrote:

…

Could you please provide more detail on this? Show me the code. Note also that "noise" in all the flavors presented here were designed for satisfactory visual results and speed, and it's bound to have precision problems if you look too closely at it. The images look weird, though. Show me your code and I will try to look into this. On Thu, 24 Sep 2020, 02:10 rbnelr, ***@***.***> wrote: > In my usage of the snoise(vec3) function I easily notice lines of noise > value discontinuities in lots of places. > See the attached picture. > > In my use case I use a single layer of the noise, scaled up by 2000, the > squares in the image are 1 unit. > The discontinuities seems to reach up to 1/1000 units in > value-discontinuity relative to the scale of the snoise inputs. > In my case this is a significant error that would be hard to hide when > used for voxel generation. > They appear seemingly everywhere (ie. not just far from the origin). > > I don't know enough about the math to be able to tell what might be > causing this. > Although to me this looks like the lines might be corresponding to the > simplex cell borders. > Although I believe I've ruled out my own code as the source, > since I've tried both snoise(vec2) and cnoise(vec3) and neither seem free > from any of these discontinuities. > > My current use case is a ray marching shader on desktop glsl. > > [image: issue] > <https://user-images.githubusercontent.com/25484587/94085920-f3aadf80-fdf8-11ea-8582-88997df0efda.png> > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#21>, or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAFGK2VYZUS774R3DEZJDJTSHKFA5ANCNFSM4RXUTPDQ> > . >

[rbnelr]

Sorry, I meant to say neither show the discontinuities. I tried noise3D.glsl <https://github.com/ashima/webgl-noise/blob/master/src/noise3D.glsl>, which has the issue, while I could not find anything similar when replacing it with either noise2D.glsl <https://github.com/ashima/webgl-noise/blob/master/src/noise2D.glsl> or classicnoise3D.glsl <https://github.com/ashima/webgl-noise/blob/master/src/classicnoise3D.glsl>. I could post my whole shader, but you would need to provide a few uniforms including the camera matrices to use it. I'll try to write a standalone shader that shows the issue. On Thu, Sep 24, 2020 at 11:57 AM Stefan Gustavson <[email protected]> wrote:

…

Wait, are you saying that the discontinuities appear on cnoise as well as snoise? Those are completely different implementations, which makes it even more puzzling to me. Or was that a typo, and you meant you tried the vec3 and vec2 versions of snoise? Those are quite similar and might have shared problems. On Thu, 24 Sep 2020, 13:36 Stefan Gustavson, ***@***.***> wrote: > Could you please provide more detail on this? Show me the code. Note also > that "noise" in all the flavors presented here were designed for > satisfactory visual results and speed, and it's bound to have precision > problems if you look too closely at it. > > The images look weird, though. Show me your code and I will try to look > into this. > > > On Thu, 24 Sep 2020, 02:10 rbnelr, ***@***.***> wrote: > >> In my usage of the snoise(vec3) function I easily notice lines of noise >> value discontinuities in lots of places. >> See the attached picture. >> >> In my use case I use a single layer of the noise, scaled up by 2000, the >> squares in the image are 1 unit. >> The discontinuities seems to reach up to 1/1000 units in >> value-discontinuity relative to the scale of the snoise inputs. >> In my case this is a significant error that would be hard to hide when >> used for voxel generation. >> They appear seemingly everywhere (ie. not just far from the origin). >> >> I don't know enough about the math to be able to tell what might be >> causing this. >> Although to me this looks like the lines might be corresponding to the >> simplex cell borders. >> Although I believe I've ruled out my own code as the source, >> since I've tried both snoise(vec2) and cnoise(vec3) and neither seem free >> from any of these discontinuities. >> >> My current use case is a ray marching shader on desktop glsl. >> >> [image: issue] >> < https://user-images.githubusercontent.com/25484587/94085920-f3aadf80-fdf8-11ea-8582-88997df0efda.png > >> >> — >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub >> <#21>, or unsubscribe >> < https://github.com/notifications/unsubscribe-auth/AAFGK2VYZUS774R3DEZJDJTSHKFA5ANCNFSM4RXUTPDQ > >> . >> > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGCN2K3NRCYPB2SVE2NFKTTSHMX2RANCNFSM4RXUTPDQ> .

[rbnelr]

As you can see in the last image at the end of this comment, the values jump when the position crosses certain planes.
The jump is small, so it might only be visible when magnifying the the noise function by about a thousand.

This issue might not be visible when using the function as a source for color information or similar,
but it can show up as a very visible jump in some applications like isosurface generation for terrain.
At least when using the function as a base layer to generate large scale structures like mountains or large caverns in 3d.

Please let me know if you can reproduce the issue.

Following is a standalone shader that produces the images below.
Comment out the blocks other than the one you want to see.

Note: When you zoom in on the [A] image you can see that this shows up in
lots of places.

//#include "noise3D.glsl"

void main () {
	vec2 pos = gl_FragCoord.xy - vec2(700.0);

	//// [A] Shows the discontinuity as a clearly visible lines in the derivative, even visible in multiple places
	//pos /= 400.0;
	//float val = snoise(vec3(pos, 0.0) + vec3(300, -300, -300));
	//
	//float dx = dFdx(val * 100);
	//float dy = dFdy(val * 100);
	//frag_col = vec4(dx, dy, 0.0, 1.0);
	////

	//// [B] Same as above but zoomed in to one of the 'crosses' I also see in my raymarcher
	//pos += vec2(900.0, -1000.0);
	//pos /= 2000.0;
	//float val = snoise(vec3(pos, 0.0) + vec3(300, -300, -300));
	//
	//float dx = dFdx(val * 100);
	//float dy = dFdy(val * 100);
	//frag_col = vec4(dx, dy, 0.0, 1.0);
	////

	//// [C] Visualized without the derivative 
        pos += vec2(900.0, -1000.0);

	pos /= 2000.0;
	float val = snoise(vec3(pos, 0.0) + vec3(300, -300, -300));

	val -= 0.403;
	val *= 300.0;
	frag_col = vec4(val, val, val, 1.0);
	////
}

Edit: Deleted previous comment because typing it in gmail made it not have formatting.

[rbnelr]

Indeed 0.5 fixes it on first inspection.
As far as I can tell your repo also uses 0.6 on that line.
I'm going to keep that line changed in my cope for now.

Anyway thanks for the quick reply.

[rbnelr]

I guess I should keep this issue open until the code in this repo is changed.

[stegu]

Yes, please keep it open. I will make the edit as soon as I'm on a proper computer. Github and a smartphone is not a great combination...

…

On Thu, 24 Sep 2020, 18:56 rbnelr, ***@***.***> wrote: I guess I should keep this issue open until the code in this repo is changed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#21 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFGK2QDOVIHYYV5W4H43G3SHN233ANCNFSM4RXUTPDQ> .

[stegu]

At long last, I got around to fixing this issue in both repos (ashima/webgl-noise and stegu/webgl-noise) for both versions affected (noise3D.glsl and noise3Dgrad.glsl). Note that the change from 0.6 to 0.5 affects the range of output values, so I had to tweak the arbitrary final scaling factor as well, to cover the range [-1, 1] reasonably well.
Closing the issue.