Jeff Budsberg

I dug up my slides from when we implemented [dl.acm.org] vdbToSpheres to help explain what's going on. Here's one way to think about it:
* for all of the points inside a level set, choose the one furthest from the surface.
* That point is the center of a sphere, with radius equal to that distance (or optionally clamp the max sphere size).
* remove all other points that exist inside that sphere
* update the distances to all remaining points
* repeat (until desired number of spheres, reach a size threshold, etc)



If you change the levelset, the distribution of possible points would change. Since your base object is changing over the animation, the level set would change, hence the spheres change during animation.

In practice in production, artists often run vdbToSpheres on a reference frame (eg. first frame of the animation), then wrap deform the spheres to the animated/deforming mesh. The result is a temporally-coherent number & location of spheres.

In production, we get open surfaces from Modeling often. The common practice is to convert the mesh to an unsigned distance field prior to converting to a signed distance field.


I have an example in the Houdini example file https://www.openvdb.org/download/ [www.openvdb.org] Look for /obj/example_levelset/extruded_sdf

Another update is available today! Took a while (to make sure I didn't break anything), but I've scrubbed the file and swapped everything I could to native SOPs.

A few opensource nodes/workflows remain (demonstrating new or slightly-different functionality), but I've tried to create parallel native workflows when possible.