A fast and cross-platform Signed Distance Function (SDF) Viewer App using three-d

[Yeicor]

I finally released version 1.0.0 of my SDF Viewer App! It allows designing 3D models through code, which the app renders and customizes in real time, refreshing as fast as possible after changes to the code. I use it to design objects for 3D printing, but it can be used for any 3D modeling task. Three-D (and egui) made the graphics easy, thanks @asny.

The main features are high-performance rendering, cross-platform support (including web), and straightforward integration with any language/library that can be compiled to WebAssembly (with integrations already written for Rust and Go). You can read more about it on the link above. The app demos are:

I hope this is useful for others. Feel free to leave suggestions here on how to use more Three-D features for the app, or open a new issue/discussion in the repository for anything else.

[asny]

Super cool! 🚀 Even works perfectly on my phone 😮

I just have one suggestion and I don't really expect you to implement it 🙂 It would be super cool to be able to write an SDF in the UI. Could be in Go or whatever, just a text field where you write your SDF code and then it is displayed when it is valid.

[asny]

I think that all makes sense 🙂 It's not super simple to set up but highly efficient to iterate once you have done so. How do you export the result?

[Yeicor]

SDFs are usually exported by creating a triangle mesh using one of the several algorithms available. This should be implemented in some way by the SDF library used. For example, SDFX provides both marching cubes and dual contouring for obtaining meshes from 3D SDFs.

It would be nice to add several meshing algorithms to SDF Viewer, as it has all the necessary data to build a mesh (it could even write basic colors/materials), and any algorithm would be available for all integrated libraries.

Exporting as a traditional mesh is compatible with most tools, but it is also lossy as round corners become lots of small triangles that approximate the curve. Alternatively, the wasm file itself would contain the exact representation and can also be easily shared if this is enough: it can be rendered on any computer just by clicking a link, and it could be exported to a mesh later with the preferred algorithm and level of detail if the second paragraph is implemented.

[asny]

In my opinion, making the input/output easy would be a great improvement because it would make for an easy integration into a workflow. However, I'm not sure what the use cases are exactly, so I might be wrong 🙏

Also, I realise that is much easier said than done 😆 It will require a lot of effort which would have been too much to implement for a first version, so the reason I'm asking is just to hear about the plan going forward. Just to make it absolutely sure, I think it looks really cool and makes me want to play around with constructing SDFs 👍

[Yeicor]

I just released v1.1.0 with support for exporting triangle meshes! 🚀

I did this with the help of isosurface which implements several algorithms for isosurface reconstruction. It even works on web browsers (freezing the renderer while generating the mesh 😅) forcing a download of the generated model file.

The release also adds all subcommands to the UI (like the server and the meshing algorithms) for ease of use. This is done automagically from the CLI code (thanks to klask), so almost no change was necessary for integrating it with the UI. It also provides access to all the CLI documentation from the UI for ease of use.

[asny]

Oh wow, that was fast 😄 super nice work 💪

[Yeicor]

I also have a few questions for you @asny, seeing how you know much more about graphics than me 😅.
They are both related to my shader code (based on your isosurface_material.frag).

• I tried different values for the gl_FragDepth variable at line 155, but I can't seem to get it right. This would be nice to add other objects to the scene and show them along the SDF model, e.g., a grid to show the scale of the object.
• I don't know why unpackColor (which converts one float into three lower-precision floats) extracts a different color than the one packColor encodes (when the CPU test of the same code gives me the same colors). It looks like a precision issue, but I was already using very few bits. Can you help me figure it out?

These are nice-to-have features but are not required functionality for the app, so don't rack your brain over this. If you can't think of a solution off the top of your head feel free to ignore them. Thanks!

[asny]

No problem 🙂 I think the problem is that the rayPos variable is not in world space. For debug purposes, try to use pos. That should result in a depth matching the surrounding cube. Not what you want, but then we can see if that is the problem. You can also try to multiply rayPos with the model matrix before the BVP matrix.

If you stored your data in several separate 3D textures, then you could have one for color which could be RgbU8 and you would have automatic hardware accelerated interpolation. So it would be simpler code and I think it would be faster. The problem with packing bytes into a float is that you are not sure how many bytes is in a float, you usually do it the other way around, pack floating point values into byte representation.

[Yeicor]

No matter what I try, I always get the SDF rendered on top of the other object. Even if I set gl_FragDepth to always be 1 or 999999, so I probably messed up something configuring the materials.

At least your using multiple textures suggestion worked perfectly! I thought that sampling multiple textures with hardware interpolations would be slow, but I guess GPUs (even integrated ones) are fast 😄.

[asny]

Arh, ok then something is probably completely wrong, probably you created a window without a depth buffer because that's how the eframe example did it. I fixed that recently in the example, see emilk/egui@3eccd34 . I also improved that example in other ways recently, so might be worth revisiting 🙂 also, the glFragDepth value should be in the 0-1 range.

Nice that multiple textures are working. It can be difficult to predict the performance and it of course also depends on hardware but should be as fast as a single texture since it is the same amount of data you need to fetch. And should make the code more simple 🙂

[Yeicor]

Thanks for the help, depth is finally working! I also reviewed and made changes based on your updates to the example. I released v1.2.0 with these changes and a shader rewrite.

demo.mp4

Maybe I misconfigured something else, but when rendering the example above:

• This code does not render the SDF.

let objects_vec = self.objects.iter().map(|e| &**e).collect::<Vec<_>>();
let objects_slice = objects_vec.as_slice(); // <includes the cube and the SDF>
let lights_vec = self.lights.iter().map(|e| &**e).collect::<Vec<_>>();
let lights_slice = lights_vec.as_slice();
target.render_partially(frame_input.scissor_box, &self.camera.camera, objects_slice, lights_slice);

• But this one works perfectly.

let objects_vec = self.objects.iter().map(|e| &**e).collect::<Vec<_>>();
let objects_slice = objects_vec.as_slice(); // <includes only the cube>
let lights_vec = self.lights.iter().map(|e| &**e).collect::<Vec<_>>();
let lights_slice = lights_vec.as_slice();
self.sdf_viewer.volume.render(&self.camera.camera, lights_slice); // <renders the SDF manually>
target.render_partially(frame_input.scissor_box, &self.camera.camera, objects_slice, lights_slice);

I feel like both should do the same thing. After some debugging, I think the first one does not receive the Texture3D updates that I send to the material via the fill call, while the second one receives these updates.

[asny]

Wow, it looks super great 🎉 Nice you the depths to work!

About the question, the render_partially method calls the render function, so there shouldn't be any difference. However, it also does frustum culling (and sort objects based on optimal render order, but that shouldn't make a difference either) so if your sdf volume doesn't have a correct bounding box specified, then it might be culled (if you return AxisAlignedBoundingBox::INFINITE it will never get culled). Also check that the sdf volume actually is in the objects_slice 🙂