Error creating the normals when editing mesh in an awkward way

[chaoticgood1]

I provided a gif below to describe the bug as it is hard to describe it. I am having a hard to time to debug it myself, where should I start to identify the error?

Here is the repo: https://github.com/Nickan/bevytest/tree/FastSurfaceNets

To run, just clone and do cargo run. Thanks

[bonsairobo]

Looks like a non-manifold mesh. This can happen with surface nets, so you may need to constrain your SDF.

[chaoticgood1]

Does that mean we have to be careful setting the SDF or have to modify how we create the quads in all axes?

[bonsairobo]

Does that mean we have to be careful setting the SDF or have to modify how we create the quads in all axes?

Yea there is a multitude of bad things that can happen if you just provide an SDF of random numbers. I don't know precisely how to describe these issues. You generally don't encounter problems if you sample from exact implicit SDFs with high enough sample rate, but it's pretty easy to discover configurations that produce a non-manifold vertex, at which point normal vector interpolation is guaranteed to break. You could work around this if you're willing to use flat shading. If you want perfect normals, you might even need to doctor the mesh itself. It's a complex issue.

Here's a similar old issue: https://github.com/bonsairobo/building-blocks/issues/31

A similar issue can occur in https://github.com/bonsairobo/octree_dual_contour. I made a band-aid fix for it here: https://github.com/bonsairobo/octree_dual_contour/blob/4cd54939cec6a0579ebe3bcfb4e94d7e69b99cb6/src/mesh.rs#L10

It's an issue I'm still investigating when I have time. This is one of those times when meshes are a pain in the ass.