Add SDFGeometryGenerator addon.

[santi-grau]

New Addon

Description

Creates a THREE.BufferGeometry from an SDF.
Added example and documentation

[gkjohnson]

Just a couple thoughts while passing through -

• It looks like this is implementing SDF to geometry functionality with "Surface Nets" which is basically a Marching Cubes alternative. It would be nice to align the API with the current MarchingCubes object implementation since in theory surface nets should be a drop in replacement if I'm understanding right. Though the current MarchingCubes class is structured a bit oddly extending from Mesh so maybe this can be figured out later.
• It looks like a lot of the code is copy-pasted from this library file here in another repo. It might make most sense to drop that file (modified to support exports) in the jsm/libs directory with the other library files along with a date of copy / version number so it's easier to keep track of.

Overall surface nets look cool, though - I hadn't heard of them before!

[santi-grau]

@gkjohnson thanks for your input.
Regarding moving this to use Marching Cubes, I'm afraid is a bit beyond my skills :( that's why I used Mikola's isosurface.
Are there any docs on how a file at libs should be included? Or just remove from SDFGeometryGenerator.js and copy at jsm/libs?

ty!

[gkjohnson]

Regarding moving this to use Marching Cubes

I didn't intend to suggest using MarchingCubes - just that the APIs between the two classes should (some day) be the same since they aim to solve the same problem. I think that can be skipped in this PR.

Or just remove from SDFGeometryGenerator.js and copy at jsm/libs?

This one. Ideally the code is formatted the same as the original source so it's easy to diff and update if needed. It will also need to be adjusted to support js exports.

[santi-grau]

@gkjohnson moved the surfaceNets script onto jsm/libs

[Mugen87]

@santi-grau I've went over the code to improve the code style and to simplify the example at a few places. The most important thing for me was to avoid custom material shaders in webgl_geometry_sdf. So the meshes are now rendered with built-in materials. This will make it easier to port the example to WebGPU at a later point.

[Mugen87]

@santi-grau The PR looks in general good to me. The only thing that might be a problem is that the example relies on custom GLSL code. This dependency will make it harder to migrate the demo to WebGPURenderer at some point since the GLSL needs to be migrated to TSL to work with both WebGPU and WebGL.

Would you be okay to add just the Mandelbrot shader and remove the two others? The head and Suzanne shader are so large that rewriting the code to something else will be quite time-consuming.

[santi-grau]

Sure, will update!

[santi-grau]

Updated the example removing those two shaders.

[Mugen87]

@santi-grau While improving the example, I have noticed SDFGeometryGenerator makes no use of dispose() methods which means the component creates memory leaks. I have refactored the code a bit to fix this issue. You can easily see the effect when inspecting the renderer.info debug object after generating some geometries.

[Mugen87]

I've realized the rendering performance of computeSDF() could be noticeably improved by using instanced rendering because the geometry (the plane) is the same for each draw call and only the tileNum uniform is different. If tileNum and the position of the plane would be instanced attributes, computeSDF() would only require a single draw call, no matter how many tiles are configured.

Would you be willing to give this implementation a try?

Further changes are requried.

[santi-grau]

@santi-grau While improving the example, I have noticed SDFGeometryGenerator makes no use of dispose() methods which means the component creates memory leaks. I have refactored the code a bit to fix this issue. You can easily see the effect when inspecting the renderer.info debug object after generating some geometries.

Didn't know we had to manually dispose. Thanks for adding!

[santi-grau]

I've realized the rendering performance of computeSDF() could be noticeably improved by using instanced rendering because the geometry (the plane) is the same for each draw call and only the tileNum uniform is different. If tileNum and the position of the plane would be instanced attributes, computeSDF() would only require a single draw call, no matter how many tiles are configured.

Would you be willing to give this implementation a try?

The reason why I'm using 'tile rendering' is to prevent crashes in case the SDF function gets too complex ( e.g. fbm ). This way, no matter what, we are just computing a specific tile size. If you still think that instance rendering will still be safe and more efficient I can try to implement it.

[Mugen87]

The reason why I'm using 'tile rendering' is to prevent crashes in case the SDF function gets too complex

I see. In this case, I think it's okay to start with the current implemented approach. If users report performance issues, we can revisit this topic (and maybe think about different rendering modes).