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.
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 And I think just the name alone can make a difference in how many people will try out the experimental build.
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.
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.
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
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?
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 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
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.
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 @anon88686743 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.