I'm trying to understand this but I'm not sure I'm following.
As far as I understand as a complete beginner in 3D rendering:
Regular 3d models/meshes are just a collection of points/triangles in a 3d plane, along with some additional data like normal orientations. For rendering, the mesh is constructed and then rendered with some perspective/distance/occlusion settings etc. for each pixel painted on screen.
This format isn't a discrete collection of points but some data set where every point queried during 2d painting returns a distance (if it exists) based on some function or ML algorithm, basically returning a point cloud?
For every point in 3d space you can get the distance to the surface. So, if you have a camera you can shoot a ray into the scene and pick some points on it to ask if it is inside the model. if so you paint that pixel with the surface material of the model. Then it's just a matter of picking a good way of sampling points along the camera ray. usually this distance function is some basic math (distance to sphere or so). But here they take a 3d mesh and create a neural network that can answer the question of distance to it (since meshes are very slow at that).
Meshes are actually extremely fast for querying distance to a surface. Even in scenes with lots of geometry, using an acceleration structure like a BVH can be extremely fast. You can even do ray tracing in real time on a GPU now (at least for direct lighting, certainly not for global illumination).
By contrast, SDFs require you to do lots of expensive lookups as you slowly march along a ray until you happen to bump into a surface.
This is a bit confused. Current RT implementations are faster at intersecting the mesh along the ray direction than sphere tracing (which require the expensive lookups or evaluations).
The distance to the surface is independent of direction, it is only a function of position (as all SDFs are).
The depth map is the distance from ray origin to intersection only, not how close that ray came to the surface at any point along it's segment.
That's fair, my point is that if you only care about rendering something quickly then a mesh is your best bet.
Are there applications you have in mind where the distance to the nearest surface is actually useful, regardless of the surface representation? As in, when would knowing the distance to the nearest surface be helpful when you're working with meshes? It seems to me you only need to know the closest distance to a surface when you have an SDF and are trying to compute an intersection along a ray.
The nearest sort of application of this kind that I can think of is Walk on Spheres (cool recent paper https://www.cs.cmu.edu/~kmcrane/Projects/MonteCarloGeometryP...), but in that case the authors do a closest point query, not a distance to the nearest surface. There's a subtle difference here because you actually need the closest point (not just the distance) so that you can look up a boundary condition. It's not clear to me how you could make use of an SDF in this setting, although maybe there's an interesting research direction there.
>Are there applications you have in mind where the distance to the nearest surface is actually useful, regardless of the surface representation?
Distance fields are a subset of implicit functions (see wikipedia). The use of level curves (which can be interpreted as "distance" for SDFs) is broad. You can dynamically and trivially thicken or shrink objects by adding or subtracting to the distance. Functions defined on the level curves output of an SDF can be used to map a volume to another implicit function (see nTopology). With implicit functions, the non-zero level sets are really just as important, but most focus on the zero level set in rendering.
>There's a subtle difference here because you actually need the closest point (not just the distance) so that you can look up a boundary condition.
Vector to Closest Point (VCP) is subtle but different in important ways. It is unsigned, and cannot indicate whether a position is inside or outside the object. Implicit modeling is not generally concerned with parameterizing the surface, since we can use volumetric, 3D procedural textures.
Thanks for the insights! I come from a mostly rendering background, so my understanding is definitely biased from always thinking of SDFs in the context of surface rendering or reconstruction :-)
After skimming here is my (imperfect) summary. Comments encouraged!
Technique: "Neural Geometric LOD (level of detail)"
Summary: This technique provides a machine-learning approach to give more efficient representation for 3D surfaces at interactive rates.
Related Work: "Our work is most related to prior research on mesh simplification for level of detail (LOD), 3D neural shape representations, and implicit neural rendering."
Method: "Our goal is to design a representation which reconstructs detailed geometry and enables continuous level of detail, all whilst being able to render at interactive rates."
Experiments: "Across all [tested] datasets [(ShapeNet, Thingi10K, TurboSquid, Shadertoy)] and metrics, we achieve state-of-the-art results" relative to DeepSDF, Fourier Feature Networks, SIREN, and Neural Implicits (NI).
Generalization: "surface extraction mechanism can generalize to multiple shapes, even from being trained on a single shape."
I believe Occupancy Networks is using octrees for surface extraction (i.e. construct a voxel grid given your SDF). See figure 2 in the Occupancy Networks Paper.
On the other-hand, octrees are used in this paper to store variable resolution feature volumes (i.e. to improve the representation of the SDF). See figure 3 in Neural Geometric Detail Paper.
If I understand correctly, this is essentially using neural nets to compress the information representing a 3D mesh [1], similar to how neural nets can do image upscaling on 2D images?
Either way, the technology of Star Trek The Next Generation went through a period in the late 90s where it all seemed ridiculous, and now we’ve come full circle and it all seems plausible again.
More specifically: I’d love to see a generative adversarial network that can materialize 3D worlds in real time, like the holodeck. More and more the holodeck seems plausible as a system of nets upon nets upon nets. Nets for generating models, nets for generating stories...
1: In this case the meshes are not polygons, but rather signed distance fields. Metaballs are commonly made with this technique.
Edit: thanks for catching the spelling mistake. Metaballs misspelled as Meatballs is a plague that continues for over two decades. Usually I try to avoid the trap altogether and say Implicit Surfaces :)
I don't think the point is compression, SDFs even when represented with a neural net have a much larger memory footprint and are significantly more expensive to render.
The main benefit of a SDF are that you don't have topological issues to worry about, which makes them great for reconstruction problems where a surface is evolving over time.
I bet you could take advantage of the fact that the function generated with feedforward + relu is piecewise linear to mesh the resulting SDF really efficiently.
Presumably it takes less memory, letting a more complex scene be transferred to the GPU more quickly, at the tradeoff of time spent training the model?
Memory savings are the main potential gain, since you won't need as deep a tree. This is not the main issue with this tech atm.
Also, their distance output will be an estimate, it won't be exact, which will cause render time to underperform vs exact representations. Worse, the NN could return a value greater than actual distance, which will cause artifacts.
The interesting thing about this paper is that they replace the mathematical SDF with a neural net that computes SDF_NN(x,y,z) => -1/1 and use this as a compression system for mesh based inputs. This feels like a graphical version of the https://en.wikipedia.org/wiki/Hutter_Prize for NN-based text compression.
Seriously. I've never seen anyone who is simultaneously this fluent in applied mathematics while having this level of visual sensibility as an illustrator. Truly a polymath.
Seriously, start experimenting, you'd be surprised.
However, overall experience with math and various mathematical experiences help so much, as well as some kind of artistic experience -- even just talking to artists, seeing a few videos on theory of artistic composition, etc. I highly recommend going down this path.
EDIT> Thanks for the amazing video link! I've been coding CG on and off since 1987 and this just hits so many disparate things and brings them all together in a beautiful visual and mathematical presentation.
I've been meaning to model a simple 3d character for a game I want to reboot, and had been waffling between doing something procedural / parametric and either doing the art or hiring an artists. Now I know what I'm doing for the rest of the day. clears schedule. Woo!
As an aside, this page is great, I was able to watch the videos and see all the images without needing to enable javascript for half a dozen 3rd party URLs!
Does anyone have an impression of how it compares to Alex Evan's SDF engine[0] used in Dreams? Is it primarily a space compression? I've been looking out for anything outside of media molecule that can come close to it's detail-representation and performance
A big part of the secret sauce there seems to be what he called a Compute Shader of Doom used to optimize the brush strokes into the SDF - I'd love to know that shader works!
My understanding of this paper (please comment/correct based on your understanding):
* Instead of using a single latent feature per each implicit surface, the authors propose using a "volume" of latent features per each surface. This allows for the NNs to better capture the geometric detail while remaining relatively shallow. The result is a more accurate and faster to compute neural SDF. Contrary to the claim of another comment, the neural SDF alone is not the interesting part of this paper--the prior works points to at least three other papers that have explored the idea of representing an SDF with a neural net: Park et al.'s DeepSDF https://arxiv.org/pdf/1901.05103.pdf, Mescheder et al's Occupancy Networks http://www.cvlibs.net/publications/Mescheder2019CVPR.pdf, and Chen et al's Learning Implicit Fields https://arxiv.org/pdf/1812.02822.pdf All very interesting papers.
* When I say a "volume" of latent features I specifically mean a voxel-grid where the corners of each voxel are latent features and any position X has a corresponding feature Z which is simply the trilinear interpolation of the features on the corners of the voxel. As the authors mention, they try to keep this sparse by leaving any voxel that does not contain the surface "empty".
The authors use an octree to create L different feature volumes. As L becomes larger, the resolution of the feature volume increases which means that more fine grained details can be encoded as features.
Finally, the authors describe a rendering procedure that makes use of their LOD model (still need to read this part more thoroughly).
Some additional thoughts:
Why are SDFs useful at all?
One comment suggests this is a form of "compression" but meshes have a far smaller memory footprint and are computationally less expensive to render. Ray tracing is extremely fast, largely due to the fact that as a primitive operation in graphics so much time and energy has been invested into understanding how to make it faster with various acceleration structures, like BVHs.
So are SDFs actually useful?
Yes. Triangle or polygon meshes are great when you have them, but are terribly challenging to work with for reconstruction tasks. For instance, you effectively have to pause occasionally during reconstruction to fix your mesh up so that it isn't complete garbage (triangles with small angles, self-intersections, extremely lopsided side lengths, etc). SDFs support arbitrary topology painlessly, which is why they show up so much in reconstruction/computer vision.
So why do we need neural nets to represent them?
I think the primary reason you use a neural network to represent a signed distance function is because it's a more efficient representation than storing the SDF in some sort of grid structure (maybe someone else has more thoughts on this?). As a side benefit, it can simplify any sort of differentiable rendering since the surface itself already is represented in a manner that is naturally differentiable via back-propagation.
Meshes and bezier patches are boundary representations with no information of the volume they enclose. Imagine you'd like to cut an object out of smoke or clouds. SDFs enable you to cut out arbitrary volumes from any material. This is more realistic than skinning a mesh object with textures, especially with translucent objects.
> So why do we need neural nets to represent them?
You don't. I didn't notice render times, but "interactive frame rates" would be lacking.
Most SDF primitives and their compositions are not analytic (from use of abs, fract, etc). Differentiation by finite differences is most common. Few are using automatic differentiation. I don't quite follow how back prop would produce the surface gradient, but I doubt it would be faster than these methods.
> Meshes and bezier patches are boundary representations with no information of the volume they enclose
Pedantic on my part, but SDF is still just a surface/boundary representation at the end of the day. It may have additional benefits that you point out such as quickly computing if you're inside/outside or being able to more easily deform the shape (through any number of procedures including slicing), but you'd probably use a density grid instead of a SDF if you're dealing with anything volumetric, such as clouds or smoke.
> You don't. I didn't notice render times, but "interactive frame rates" would be lacking.
Yeah definitely, poor wording on my part.
> Most SDF primitives and their compositions are not analytic (from use of abs, fract, etc). Differentiation by finite differences is most common. Few are using automatic differentiation. I don't quite follow how back prop would produce the surface gradient, but I doubt it would be faster than these methods.
I don't think we're talking about the same thing, I'm not referring to the surface gradient when I say differentiable rendering.
Both differentiable rendering with an SDF (i.e. SDFDiff https://arxiv.org/pdf/1912.07109.pdf) and with a neural SDF(DIST http://b1ueber2y.me/projects/DIST-Renderer/) use automatic differentiation to compute the gradient of the rendering/image-generating process. Section 3.4 in the DIST paper discusses where back prop comes into all of this. Basically your surface is defined by the weights of some neural net (i.e. a neural SDF) and you need to know the gradient of your image with respect to those weights.
For a variety of reasons, these surface representations are easier to handle than triangle meshes which break certain desirable properties for differentiation and require extra care as a result (see edge sampling https://people.csail.mit.edu/tzumao/diffrt/ for an early example of the challenges of doing differentiable rendering with a triangle mesh).
>SDF is still just a surface/boundary representation
Meshes and Bezier patches are parametric representations (defined over R^2, evaluated with vec2, output vec3). Implicit functions are volumetric representations of surfaces (defined over R^3, evaluated with vec3, output float). This is a key difference between parametric modelers like AutoCad and implicit modelers like nTopology.
>density grid instead of a SDF if you're dealing with anything volumetric, such as clouds or smoke.
These functions of time change every frame. In the implicit paradigm, it's not necessary to evaluate the smoke ahead of time since sphere tracing can reduce to marching adaptively when we are within smoke. Image quality will not be bound to any resource resolution other than the screen (a low res smoke grid would appear blocky).
I agree with you that the current triangle-based RT implementations have faster alternatives that accomplish similar things on the surface.
Thanks again for the insights here and in the other thread!
> In the implicit paradigm, it's not necessary to evaluate the smoke ahead of time since sphere tracing can reduce to marching adaptively when we are within smoke.
Makes sense. The SDF is separate from the density grid for the cloud/smoke. We need both, one to detect the boundary (SDF) and another to actually render the volume (density grid).
In offline rendering we usually just have some primitive (sphere, cube etc) that acts as the boundary but that obviously isn't as adaptive and doesn't let you easily reveal arbitrary slices of a volume.
>In offline rendering we usually just have some primitive (sphere, cube etc) that acts as the boundary
Right, using a SDF as a boundary condition is to discretely check it as an indicator function (if negative do x else do y). You can use basically any SDF to bound your procedural medium, including a procedural boundary (via domain distortion).
You can also apply a continuous blend instead of the discrete check (smooth step the level curve). This is preferred since discrete checks will often result in popping.
38 comments
[ 4.4 ms ] story [ 81.0 ms ] threadAs far as I understand as a complete beginner in 3D rendering:
Regular 3d models/meshes are just a collection of points/triangles in a 3d plane, along with some additional data like normal orientations. For rendering, the mesh is constructed and then rendered with some perspective/distance/occlusion settings etc. for each pixel painted on screen.
This format isn't a discrete collection of points but some data set where every point queried during 2d painting returns a distance (if it exists) based on some function or ML algorithm, basically returning a point cloud?
float distance_to_surface_of_model(x, y, z);
For every point in 3d space you can get the distance to the surface. So, if you have a camera you can shoot a ray into the scene and pick some points on it to ask if it is inside the model. if so you paint that pixel with the surface material of the model. Then it's just a matter of picking a good way of sampling points along the camera ray. usually this distance function is some basic math (distance to sphere or so). But here they take a 3d mesh and create a neural network that can answer the question of distance to it (since meshes are very slow at that).
By contrast, SDFs require you to do lots of expensive lookups as you slowly march along a ray until you happen to bump into a surface.
The distance to the surface is independent of direction, it is only a function of position (as all SDFs are).
The depth map is the distance from ray origin to intersection only, not how close that ray came to the surface at any point along it's segment.
Are there applications you have in mind where the distance to the nearest surface is actually useful, regardless of the surface representation? As in, when would knowing the distance to the nearest surface be helpful when you're working with meshes? It seems to me you only need to know the closest distance to a surface when you have an SDF and are trying to compute an intersection along a ray.
The nearest sort of application of this kind that I can think of is Walk on Spheres (cool recent paper https://www.cs.cmu.edu/~kmcrane/Projects/MonteCarloGeometryP...), but in that case the authors do a closest point query, not a distance to the nearest surface. There's a subtle difference here because you actually need the closest point (not just the distance) so that you can look up a boundary condition. It's not clear to me how you could make use of an SDF in this setting, although maybe there's an interesting research direction there.
Distance fields are a subset of implicit functions (see wikipedia). The use of level curves (which can be interpreted as "distance" for SDFs) is broad. You can dynamically and trivially thicken or shrink objects by adding or subtracting to the distance. Functions defined on the level curves output of an SDF can be used to map a volume to another implicit function (see nTopology). With implicit functions, the non-zero level sets are really just as important, but most focus on the zero level set in rendering.
>There's a subtle difference here because you actually need the closest point (not just the distance) so that you can look up a boundary condition.
Vector to Closest Point (VCP) is subtle but different in important ways. It is unsigned, and cannot indicate whether a position is inside or outside the object. Implicit modeling is not generally concerned with parameterizing the surface, since we can use volumetric, 3D procedural textures.
To show why it is wrong: Change the mesh every frame.
Technique: "Neural Geometric LOD (level of detail)"
Summary: This technique provides a machine-learning approach to give more efficient representation for 3D surfaces at interactive rates.
Related Work: "Our work is most related to prior research on mesh simplification for level of detail (LOD), 3D neural shape representations, and implicit neural rendering."
Method: "Our goal is to design a representation which reconstructs detailed geometry and enables continuous level of detail, all whilst being able to render at interactive rates."
Experiments: "Across all [tested] datasets [(ShapeNet, Thingi10K, TurboSquid, Shadertoy)] and metrics, we achieve state-of-the-art results" relative to DeepSDF, Fourier Feature Networks, SIREN, and Neural Implicits (NI).
Generalization: "surface extraction mechanism can generalize to multiple shapes, even from being trained on a single shape."
On the other-hand, octrees are used in this paper to store variable resolution feature volumes (i.e. to improve the representation of the SDF). See figure 3 in Neural Geometric Detail Paper.
Either way, the technology of Star Trek The Next Generation went through a period in the late 90s where it all seemed ridiculous, and now we’ve come full circle and it all seems plausible again.
More specifically: I’d love to see a generative adversarial network that can materialize 3D worlds in real time, like the holodeck. More and more the holodeck seems plausible as a system of nets upon nets upon nets. Nets for generating models, nets for generating stories...
1: In this case the meshes are not polygons, but rather signed distance fields. Metaballs are commonly made with this technique.
Edit: thanks for catching the spelling mistake. Metaballs misspelled as Meatballs is a plague that continues for over two decades. Usually I try to avoid the trap altogether and say Implicit Surfaces :)
https://www.wunderparc.com/ https://www.prometheanai.com/
I haven't tried either one out; someone in my industry pointed them out to me recently.
The main benefit of a SDF are that you don't have topological issues to worry about, which makes them great for reconstruction problems where a surface is evolving over time.
Presumably it takes less memory, letting a more complex scene be transferred to the GPU more quickly, at the tradeoff of time spent training the model?
Also, their distance output will be an estimate, it won't be exact, which will cause render time to underperform vs exact representations. Worse, the NN could return a value greater than actual distance, which will cause artifacts.
The interesting thing about this paper is that they replace the mathematical SDF with a neural net that computes SDF_NN(x,y,z) => -1/1 and use this as a compression system for mesh based inputs. This feels like a graphical version of the https://en.wikipedia.org/wiki/Hutter_Prize for NN-based text compression.
Seriously, start experimenting, you'd be surprised.
However, overall experience with math and various mathematical experiences help so much, as well as some kind of artistic experience -- even just talking to artists, seeing a few videos on theory of artistic composition, etc. I highly recommend going down this path.
Any recommended materials? Most I found were made for photography and not for free form scene creation.
EDIT> Thanks for the amazing video link! I've been coding CG on and off since 1987 and this just hits so many disparate things and brings them all together in a beautiful visual and mathematical presentation.
I've been meaning to model a simple 3d character for a game I want to reboot, and had been waffling between doing something procedural / parametric and either doing the art or hiring an artists. Now I know what I'm doing for the rest of the day. clears schedule. Woo!
A big part of the secret sauce there seems to be what he called a Compute Shader of Doom used to optimize the brush strokes into the SDF - I'd love to know that shader works!
[0] https://www.youtube.com/watch?v=u9KNtnCZDMI&ab_channel=Media...
https://twitter.com/mmalex/status/1354455745924911107
* Instead of using a single latent feature per each implicit surface, the authors propose using a "volume" of latent features per each surface. This allows for the NNs to better capture the geometric detail while remaining relatively shallow. The result is a more accurate and faster to compute neural SDF. Contrary to the claim of another comment, the neural SDF alone is not the interesting part of this paper--the prior works points to at least three other papers that have explored the idea of representing an SDF with a neural net: Park et al.'s DeepSDF https://arxiv.org/pdf/1901.05103.pdf, Mescheder et al's Occupancy Networks http://www.cvlibs.net/publications/Mescheder2019CVPR.pdf, and Chen et al's Learning Implicit Fields https://arxiv.org/pdf/1812.02822.pdf All very interesting papers.
* When I say a "volume" of latent features I specifically mean a voxel-grid where the corners of each voxel are latent features and any position X has a corresponding feature Z which is simply the trilinear interpolation of the features on the corners of the voxel. As the authors mention, they try to keep this sparse by leaving any voxel that does not contain the surface "empty".
The authors use an octree to create L different feature volumes. As L becomes larger, the resolution of the feature volume increases which means that more fine grained details can be encoded as features.
Finally, the authors describe a rendering procedure that makes use of their LOD model (still need to read this part more thoroughly).
Some additional thoughts:
Why are SDFs useful at all?
One comment suggests this is a form of "compression" but meshes have a far smaller memory footprint and are computationally less expensive to render. Ray tracing is extremely fast, largely due to the fact that as a primitive operation in graphics so much time and energy has been invested into understanding how to make it faster with various acceleration structures, like BVHs.
So are SDFs actually useful?
Yes. Triangle or polygon meshes are great when you have them, but are terribly challenging to work with for reconstruction tasks. For instance, you effectively have to pause occasionally during reconstruction to fix your mesh up so that it isn't complete garbage (triangles with small angles, self-intersections, extremely lopsided side lengths, etc). SDFs support arbitrary topology painlessly, which is why they show up so much in reconstruction/computer vision.
So why do we need neural nets to represent them?
I think the primary reason you use a neural network to represent a signed distance function is because it's a more efficient representation than storing the SDF in some sort of grid structure (maybe someone else has more thoughts on this?). As a side benefit, it can simplify any sort of differentiable rendering since the surface itself already is represented in a manner that is naturally differentiable via back-propagation.
Meshes and bezier patches are boundary representations with no information of the volume they enclose. Imagine you'd like to cut an object out of smoke or clouds. SDFs enable you to cut out arbitrary volumes from any material. This is more realistic than skinning a mesh object with textures, especially with translucent objects.
> So why do we need neural nets to represent them?
You don't. I didn't notice render times, but "interactive frame rates" would be lacking.
Most SDF primitives and their compositions are not analytic (from use of abs, fract, etc). Differentiation by finite differences is most common. Few are using automatic differentiation. I don't quite follow how back prop would produce the surface gradient, but I doubt it would be faster than these methods.
Pedantic on my part, but SDF is still just a surface/boundary representation at the end of the day. It may have additional benefits that you point out such as quickly computing if you're inside/outside or being able to more easily deform the shape (through any number of procedures including slicing), but you'd probably use a density grid instead of a SDF if you're dealing with anything volumetric, such as clouds or smoke.
> You don't. I didn't notice render times, but "interactive frame rates" would be lacking.
Yeah definitely, poor wording on my part.
> Most SDF primitives and their compositions are not analytic (from use of abs, fract, etc). Differentiation by finite differences is most common. Few are using automatic differentiation. I don't quite follow how back prop would produce the surface gradient, but I doubt it would be faster than these methods.
I don't think we're talking about the same thing, I'm not referring to the surface gradient when I say differentiable rendering.
Both differentiable rendering with an SDF (i.e. SDFDiff https://arxiv.org/pdf/1912.07109.pdf) and with a neural SDF(DIST http://b1ueber2y.me/projects/DIST-Renderer/) use automatic differentiation to compute the gradient of the rendering/image-generating process. Section 3.4 in the DIST paper discusses where back prop comes into all of this. Basically your surface is defined by the weights of some neural net (i.e. a neural SDF) and you need to know the gradient of your image with respect to those weights.
For a variety of reasons, these surface representations are easier to handle than triangle meshes which break certain desirable properties for differentiation and require extra care as a result (see edge sampling https://people.csail.mit.edu/tzumao/diffrt/ for an early example of the challenges of doing differentiable rendering with a triangle mesh).
Meshes and Bezier patches are parametric representations (defined over R^2, evaluated with vec2, output vec3). Implicit functions are volumetric representations of surfaces (defined over R^3, evaluated with vec3, output float). This is a key difference between parametric modelers like AutoCad and implicit modelers like nTopology.
>density grid instead of a SDF if you're dealing with anything volumetric, such as clouds or smoke.
These functions of time change every frame. In the implicit paradigm, it's not necessary to evaluate the smoke ahead of time since sphere tracing can reduce to marching adaptively when we are within smoke. Image quality will not be bound to any resource resolution other than the screen (a low res smoke grid would appear blocky).
I agree with you that the current triangle-based RT implementations have faster alternatives that accomplish similar things on the surface.
Thanks for the links!
> In the implicit paradigm, it's not necessary to evaluate the smoke ahead of time since sphere tracing can reduce to marching adaptively when we are within smoke.
Makes sense. The SDF is separate from the density grid for the cloud/smoke. We need both, one to detect the boundary (SDF) and another to actually render the volume (density grid).
In offline rendering we usually just have some primitive (sphere, cube etc) that acts as the boundary but that obviously isn't as adaptive and doesn't let you easily reveal arbitrary slices of a volume.
Right, using a SDF as a boundary condition is to discretely check it as an indicator function (if negative do x else do y). You can use basically any SDF to bound your procedural medium, including a procedural boundary (via domain distortion).
You can also apply a continuous blend instead of the discrete check (smooth step the level curve). This is preferred since discrete checks will often result in popping.