Thank you. But I’m sure the normals are correct. I have done the same surface with R, in the same way, and the result is nice:

At least the gradient (which defines the normals) is correct, I have compared with a numerical derivation of the gradient in R. I have tried to negate the normals and to change the order of the vertices of the triangles, but no way, the gaps are always there.

Thanks, I didn’t know that. I have tried VertexNormalHelper but there are >300000 triangles, so we don’t clearly see. I will try to reduce the resolution of the marching cubes…

Well seen, thanks. I have realized something. The role of the NaN’s in the function f is to clip the surface by a ball. If I don’t put these NaN, I get no issue, there’s no gap. So these NaN cause a problem in the marching cubes algorithm. Oddly, the NaN’s does not cause any problem in R and Haskell, with the same algorithm. I have also compared with R the number of triangles, and there are less triangles in the Javascript version, when the NaN’s are here (same number when there are no NaN).
So I have to investigate the algorithm when it deals with some NaN’s.
Thanks for your help!

There were some vertices [NaN,NaN,NaN] in the output of the marching cubes algorithm, and three.js does not like that. Now the algorithm deletes all triangles containing such a vertex.