Chess effect on snow and mountains about three.js-pathtracing-renderer

[RealTecWare]

I have checked it out and on my android phone it thems to be like you want it.
And on my desktop it looks as good as on my phone.

Nice work.

I will study it in the afternoon.

• Fabian

[erichlof]

Hi @RealTecWare ,
Thank you for the artifact notice! I was toying around with the normals-calculation - turns out that machine precision plays a big role in how much detail you can get when finding gradient differences for normals. Too small of an epsilon like I had it, and you get the stair stepping effect. Too large, like in your first photo, and it there is not enough detail - the snow looks like it is painted on, or a decal. I don't think there is a magic perfect number for the normals epsilon - you either have lower retro-looking detail, or stair-stepping if you intersect the rock with your camera really close.
I updated the epsilon, it still has some stepping if you get REAL close to the rocks, but from most viewing distances, I like how it looks now. Please give it a try and let me know if it works better now.

Thanks again!
-Erich

[RealTecWare]

Hi @erichlof ,
now it's much better than before your patch.
I will checkout the last revision and will study your code, maybe I can learn something and could help anywhere one day.

Have a nice day and keep it up.

• Fabian

[erichlof]

@RealTecWare
Hi Fabian,
Thank you for the update. I just realized now that although it looks better on desktop/laptop, it looks more stair-stepped on my Android mobile device (argh...). I will work on it some more and post another update.

Yes if you study the terrain_calcNormal( vec3 pos, float t ) function, that is where I calculate the normal for the terrain. I don't know how much RayMarching you know, so apologies if you already know this: The only way to find a normal for an isometric surface like a fractal terrain after intersecting it using a raymarching algo, is to take samples right around the ray-intersection spot and find the gradient. You go one unit (size of your choice, which is the issue here) in the -X direction, take a sample, then go one unit in the +X direction, take a sample. Minus the results from each other. Now do the same in the Z direction: one unit in -Z, take sample, one unit in +Z, take sample, take the difference of the two. Y is not required because Y (the terrain height) pops out of the terrain function as a result of where the X and Z coordinates are located. So we use our epsilon and multiply the Y component of the normal vector times 2.0 because we went 1 unit in negative X and one unit in positive X, which is a total sample distance of 2.0 units, same thing for Z: we moved 2.0 units to get all the samples for that direction. Now the last step as you can see from the code is normalize (unit length of 1) the resulting normal vector. If I remember correctly, this is called the central differences method of finding gradient normals. I do the same thing for the water/ocean/lakes function.

If you find anything in the future please let me know! :)

[erichlof]

Hi again,
I updated the Terrain demo to switch the magic eps number between 0.2 on desktop (which you just reported looks better now) and 0.02 on mobile touch devices (which through trial and error, looks ok on my Samsung Galaxy phone). If you have a Chrome-enabled mobile device also, can you give it a try on that as well? Thanks!