Level Set Volume Nodes Feedback and Testing

Hi, recently I’ve been working on a patch to expose OpenVDB level set grids into geometry nodes.

D12100: Geometry Nodes: Level Set Nodes (WIP)

The patch explains it a bit more, but basically they are a way of efficiently describing manifold surfaces as volumes, because they only store values for a narrow band of voxels on the surface. This has just been a personal project mainly, but I’d like to get some feedback, with a goal of maybe including some of this in 3.0, if there’s time.

The patch contains some more straightforward changes as well as well as some experimental nodes like “Level Set Morph”. For a full list of the changes, see the patch.

Basic useful feedback:

  • Is it useful for basic things like booleans or remeshing?
  • What are the biggest missing pieces for usability or functionality?
  • For naming, “Level Set” might not be the best term to expose to users, that can be discussed here. I will probably rename the nodes in the patch to “Surface Volume” soon.

Some more technical questions I’d like to answer:

  • What should the Join Geometry node do for volumes? Should it merge/union grids, or just add all of the grids in a list for the result volume?
  • How should volumes with multiple grids work in general? Implicitly use all grids in the volume?
  • Conceptually, can there be overlap between volume grids and attributes?

Features I’d like to add eventually, but aren’t contained in the patch:

  • A “Volume Advect” node with a field input
  • Mask inputs to some volume nodes that would use a mask grid to only change part of the grid.
  • Exposing the level set fracture function from the OpenVDB API.
  • Level set statistics like volume and surface area.
  • What else?

Builds are on the build bot as always, though I’m seeing some build errors on windows and problems with the ARM Mac builds


I am curious, what’s the difference between level sets and volumes? Looking at that page, to me, as a user, level sets seem to be synonymous with volumes, just hidden under a different name.

1 Like

OpenVDB has two types of volumes:

  • Fog volume for shapes with varying density and soft boundaries like clouds or fire. Each voxel has a density.
  • Level set volume for shapes with a sharp boundary defining what is inside/outside, like a mesh surface. Each voxel has a signed distance to the nearest point on the surface, where the sign indicates inside/outside.

Fog volumes can be used for both types of shapes, but level sets can encode mesh surfaces much more accurately at the same volume grid resolution.


Ye, so it’s basically an SDF. The reason I asked is that there are other DCCs out there, especially one that’s heavily based around procedural modeling, and most of them offer similar functionality, but none of them call it level sets.

My point is that the functionality is great, but the name is very confusing even to those relatively familiar with CG terminology, let alone those who aren’t.

Using terminology like Distance Volume vs Fog Volume, or Distance Field vs Volume, etc… would IMHO still be a win over something as cryptic as level sets. To an outsider or newbie, it sounds more like something related to layer management of game engine levels, and most people wound hardly connect it to volume based modeling.

So it’s great to have, I just think it needs better name :slight_smile: And I think just the name alone can make a difference in how many people will try out the experimental build.

When I saw this screenshot originally:

I felt like I have no idea what I am looking at, especially given that the level set nodes all feed into a Volume to Mesh node. As soon as I substitute the term “Level Set” on all the node labels to “Volume” (which it actually is), the whole portrayed node network starts to make sense instantly.


I am not sure if it belongs here. There is no topic for level-set’s. If I am wrong, please move my comment.

Trying level-set branch.
If I bool on a level-set output generated from mesh, I get artifacts.


If I only bool level-set primitives, I get a clean result.

The problem needs higher resolution volumes to show.

Houdini and Bifrost call them Level Sets, which are the DCCs I first think of for procedural modelling. Using something like “SDF Volume” or “Signed Distance Volume” or “Distance Volume” instead makes sense to me though. Maybe not “Signed Distance Field” or “Distance Field” to avoid confusion with the concept of this topic.


When I googled “Houdini level sets” I got almost no results except a few over decade old threads. The main mechanism of converting geometry to volume (VDB in case of Houdini) is a “VDB from Polygons” node, which has two options called “Distance VDB” and “Fog VDB” (They are not mutually exclusive though).

You’re right about Bifrost, they do indeed seem to call it level sets.

Anyway, all of the name suggestions you’ve mentioned sound good to me. As long as user doesn’t need any obscure in depth knowledge to figure out those nodes deal with volumes, it will be fine.


@brecht @HooglyBoogly i also got confused about the name, im familiar with sdf from houdini ( and no there’s no level set word in H ) i suggest the name ’ Surface volume ’

level set type seem very interresting
I’m just thinking here out loud:

Could all volume type (Level Set/ Volume Geometry/Textures) be all unified into a single volume type/workflow?

it seem logical to centralize all volumetric-like information together for the sake of flexibility isn’t it? (+ it would be easier to learn and use)


Interesting, could you elaborate more please? Do you mean a dedicated node editor or a single node with dropdowns?

could you elaborate more please?

Well, from a user standpoint here’s what we can observe on these three types:

  • blender procedural textures are volumetric information with color attribute with the particularity of having no boundaries
  • a volume geometry type is a volumetric information with density attribute, it just happened that it is visualized as smoke in the viewport, but it could be visualized as a “level set” if we choose a minimal density right?
  • as far as i understand, level-sets are volumetric information visualized as mesh, so the density or color attribute are ignored

So why not using all volume-like information in a single workflow?
it would be more easy to understand and use + more flexible than having a bunch of operators separated in multiple subcategories

I have no clue if it’s technically possible,
It’s just a vague thought really
When having a lot of different type, flexibility can be lost if there’s not enough bridge constructed between them and sometimes it seem to be the case

1 Like

Interesting way to understand textures. But I think they are different, procedural textures don’t really have VDB Grids I think, otherwise the grid would act as a resolution, but procedural textures don’t seem to have resolution.

I am not sure if that’s what level set is supposed to be. From what Brecht said,

The level set volume seems to be defined not by density, but a set boundry that the voxels would use as a reference for where they are in the space. Not sure if I get it right though.

I still don’t quite understand what you mean by “single workflow”, can you expand on that?

1 Like

SDF Volumes are different than Fog Volumes. The difference is the type of data stored in the voxels. Distance to nearest surface vs density of the fog.

That being said, I think that most nodes that do operation on the volumes, such as volume booleans, should simply detect the type of the volume and act accordingly. I think it would be much better than having separate sets of nodes that operate on SDF volumes, and separate set that operate on Fog volumes.

I can’t post screenshots/examples, but for example in H, it’s possible to use same VDBCombine (which does volume booleans among other things) node on both distance volumes and fog volumes, and the way it works remains the same.


I still don’t quite understand what you mean by “single workflow”, can you expand on that?

What i meant is exactly this
thanks @LudvikKoutny


But textures-data implementation in such volume workflow could lead to a lot of possibilities
for example :

  • generate volume cloud/mesh from a texture-data (with defined boundaries)
  • boolean operations between volume cloud/mesh and texture-data
  • using a texture-data to define voxels attributes…
  • ect…

Again, i have no clue about the technical aspect, these are just ideas :grin:


I imagine fields will also work for volumes eventually, to easily combine procedural textures and volume grids. There’s no reason for fields to be specific to surface attributes. Though there’s some design questions to figure out there. Surface attributes have an obvious finite domain, but for volumes there’s multiple possible domains to evaluate the field on depending on the use case.

Using the same nodes for fog and SDF volumes where possible makes sense to me. Though some of the operations having different parameters depending on the type of volume. Some other applications for that reason have both SDF and non-SDF nodes in some cases, or parameters that you have to select for the nodes to work correctly depending on the type of volume. Like you might have a single node for booleans, but still need to choose either Union and SDF Union.


@brecht Wouldn’t it make sense to work with this in the framework of isosurfaces? I think “Isosurface” is a good, unambiguous name for the objects created with this workflow. It could be somewhat analogous to the volume/remesh dichotomy: level set functions are to isosurfaces as volumes are to meshes.

Even more accurately, level set functions are the field equivalent to curve surface splines/control points. The blender-fu flow is:

  • Textures: Texture coordinates → [vector math to perturb the coordinate space] → texture
  • Geometry Nodes (fields): World space (euclidean) coordinates and vertex locations → [vector math] → mesh object → transforms
  • Level sets proposal: signed distance vectors in the metric space for the level set primitive → [vector math to perturb the level set coordinate space] → isosurface → transforms

Is this workable?

I don’t see the benefit of introducing more terminology for users to learn in this case. “Isosurface” is a correct term for a mesh created from an SDF volume, but I don’t see where using that term in the name of a node, socket or data type would help.


Thanks for splitting the thread Brecht. I added some details and questions to the first post. Here are the first few things I’ve found using these nodes:

  • It won’t be obvious for people to set the threshold to 0 in the volume to mesh node. This is an example of why it isn’t always best to combine nodes that deal with similar data.
  • Any time I use volume data with a different transform, performance gets much worse.
  • Points to Volume is much faster than Mesh to Volume.
  • The “multiple grids in a volume” is an important design question to solve.

I personally feels “isosurface” at least conveys there’s a surface, I mean if what we’re aiming for is clarity, isosurface at least gives some indication to the nature of the data. SDF or level set on the other hand, are not so obvious… at least from my poorly informed perspective

My understanding was that @Sam-Hirsch proposed using the term “isosurface” to refer to the surface after converting a level set or SDF volume to a mesh. Not as a replacement for the term “level set” or “SDF”, since an isosurface is a surface and not a volume.