3 ms·

This is fascinating. Can someone help me understand why SDF-only techniques are valuable (aside from being interesting in their own right)? I know very little

This is fascinating. Can someone help me understand why SDF-only techniques are valuable (aside from being interesting in their own right)? I know very little gfx but so far I mostly saw SDFs used for accomplishing stuff in fragment shader that would otherwise be done with geometry, kind of as a workaround for limitation of shadertoy environment

frabert 5y ago
I believe the reason is because they allow for efficient raytracing via a technique called raymarching, which requires a way for it to tell what's the minimum distance from a surface given any arbitrary point, hence the need for a SDF. Quilez has many examples of this technique on his site
- anentropic 5y ago
  Ah, thank you!
  - whizzter 5y ago
    To elaborate(and just slightly correct on this point). The problem that classic primitive raytracing has had was that it never scaled well for complex primitives since you needed to solve the equations that could have many intersection points for a ray. A plane (and triangle) has 0 or 1 intersection point, this is quite trivial to solve. Insert the ray equation ( x'=x0+dxt, y'=y0+dyt, z'=z0+dzt) into the plane equation ( Ax+By+Cz = D) and solve for [t] that is the intersection distance as seen from the ray origin [x0,y0,z0] in delta units. A sphere has 0, 1 or 2 intersections. You again insert a ray equation into a sphere equations and after solving you end up with a classic second degree equation with a square root. A donut can have 0, 1, 2, 3 or 4 intersections. All these are fairly trivial shapes, but you see how the code complexity goes up very quickly even here with more intersection cases to handle even for these fairly simple shapes. Raytracing was used with triangle-meshes (with acceleration structures) in offline renderers since it still allowed for better lighting models with free-er ray sampling than normal rendering (and now RTX has put this ability in hardware for triangle soups) Now, for something simple as a sphere and plane, raytracing is faster than raymarching. The difference however is that since distance field raymarching only relies on a single value (the distance to the nearest surface) and SDF functions are trivially composable there really isn't any bounds on how complex shapes you can render with the technique, as long as the combination and core distance functions are at least somewhat conservatively "correct" in producing a single distance value (raymarching is can be forgiving for inaccuracies as long as they don't over-shoot). So while raymarching isn't really super-fast, it's fast enough that most GPU's eats them up, since it can all be run in parallel without almost any data bandwidth. (and the fact that raymarching often converges on "big" surfaces within a few iterations only needing more iteration in areas like borders that only take a small bit of the screen estate)
    - jb1991 5y ago
      Nontrivial renderers always make use of acceleration structures, and that’s actually much harder to implement with SDFs. At least with polygons, you can very precisely divide up your space or your objects and know exactly in which region what it is you’re hitting. You don’t get that benefit so easily with complex SDFs and thus many optimizations are not available.
      - whizzter 5y ago
        There was a really interesting paper here on HN a few months back, basically if your SDF was data based you could do a low resolution pruning pre-pass over the screen and remove the datapoints of the SDF that didn't contribute anything in that screenspace region. Other than that you can actually re-use many simpler SDF's to work as bounding spheres,etc. For example I did a kind of skinned character rendering that kinda started turning expensive and a simple way to accelerate it was to first do a sphere calculation that bounded it, if the sphere calc was producing a large enough value it was output directly instead of the "detail" value of the actual character. Now for a GPU that isn't ideal if one of the "threads" enters the character, but I think most GPU's do triangles one-tile-at-a-time so these threads will most of the time have converging calculations within each tile.
- jb1991 5y ago
  Raytracing with SDFs is actually not that efficient compared to all the optimizations available for raytracing polygons. And raymarching in particular can be quite slow due to the constant iterative nature of that process.
tiborsaas 5y ago
One huge benefit is the way you describe them. It's very concise. // This is a sphere length(p) - size; There are no polygons, just surfaces described with math. You can do operations with them, like addition, subtraction, deformation quite easily, which is also much more complex with polygon based 3D models. https://iquilezles.untergrund.net/www/articles/distfunctions/distfunctions.htm https://iquilezles.untergrund.net/www/articles/distfunctions...
pasabagi 5y ago
If you want to generate textures which you then read at runtime, this kind of technique is very useful - for instance, imagine you want to create the normal map of a cloud, or create a height map to displace vertices with (for a procedural landscape).
- anentropic 5y ago
  But using noise to generate textures isn't directly related to SDF (I think?) from other replies I think the point here is there are no "vertices", i.e. no mesh geometry
  - pasabagi 5y ago
    Well yeah, but you can obviously use signed distance functions to create a texture (that's what a shader is doing) that can be used at runtime. Imagine you want to make the normal map for a bubbly surface, for example, but you also want the bubbles to be animated. One way of doing this would be to render the normals from a bunch of sdf spheres onto a 3d texture, which would then be used later. I don't use this a work - it's just an approach that I've had some success with at home. On my machine, complex fragment shaders are always slow - so maybe this kind of sdf-based approach works in realtime for other people.
SonOfLilit 5y ago
It's an easy to use and general mathematical language for describing geometry. It lends itself easily to parametrization for things like procedural generation of infinite variations or for animation. And it is very "local" so requires O(1) memory to evaluate. For a nonstandard use of the idea, see font rendering on the GPU with signed distance field textures: https://aras-p.info/blog/2017/02/15/Font-Rendering-is-Getting-Interesting/ https://aras-p.info/blog/2017/02/15/Font-Rendering-is-Gettin...
enriquto 5y ago
> Can someone help me understand why SDF-only techniques are valuable Out of computer graphics, I have used them a lot for modeling the evolution of curves and surfaces in a topologically-oblivious way. The terminology is slightly different (they go by silly names like "implicit snakes"), but it is the same thing. If you have ever used an "adaptive select" or "intelligent scissors" tool of a drawing program, it was probably implemented using this technique.
agys 5y ago
MagicaCSG is a graphical signed distance field editor (by the author of Magica Voxel). The example video and images demonstrate how SDFs can be used for complex modelling! https://ephtracy.github.io/index.html?page=magicacsg https://ephtracy.github.io/index.html?page=magicacsg

frabert 5y ago

I believe the reason is because they allow for efficient raytracing via a technique called raymarching, which requires a way for it to tell what's the minimum distance from a surface given any arbitrary point, hence the need for a SDF. Quilez has many examples of this technique on his site

anentropic 5y ago
Ah, thank you!
- whizzter 5y ago
  To elaborate(and just slightly correct on this point). The problem that classic primitive raytracing has had was that it never scaled well for complex primitives since you needed to solve the equations that could have many intersection points for a ray. A plane (and triangle) has 0 or 1 intersection point, this is quite trivial to solve. Insert the ray equation ( x'=x0+dxt, y'=y0+dyt, z'=z0+dzt) into the plane equation ( Ax+By+Cz = D) and solve for [t] that is the intersection distance as seen from the ray origin [x0,y0,z0] in delta units. A sphere has 0, 1 or 2 intersections. You again insert a ray equation into a sphere equations and after solving you end up with a classic second degree equation with a square root. A donut can have 0, 1, 2, 3 or 4 intersections. All these are fairly trivial shapes, but you see how the code complexity goes up very quickly even here with more intersection cases to handle even for these fairly simple shapes. Raytracing was used with triangle-meshes (with acceleration structures) in offline renderers since it still allowed for better lighting models with free-er ray sampling than normal rendering (and now RTX has put this ability in hardware for triangle soups) Now, for something simple as a sphere and plane, raytracing is faster than raymarching. The difference however is that since distance field raymarching only relies on a single value (the distance to the nearest surface) and SDF functions are trivially composable there really isn't any bounds on how complex shapes you can render with the technique, as long as the combination and core distance functions are at least somewhat conservatively "correct" in producing a single distance value (raymarching is can be forgiving for inaccuracies as long as they don't over-shoot). So while raymarching isn't really super-fast, it's fast enough that most GPU's eats them up, since it can all be run in parallel without almost any data bandwidth. (and the fact that raymarching often converges on "big" surfaces within a few iterations only needing more iteration in areas like borders that only take a small bit of the screen estate)
  - jb1991 5y ago
    Nontrivial renderers always make use of acceleration structures, and that’s actually much harder to implement with SDFs. At least with polygons, you can very precisely divide up your space or your objects and know exactly in which region what it is you’re hitting. You don’t get that benefit so easily with complex SDFs and thus many optimizations are not available.
    - whizzter 5y ago
      There was a really interesting paper here on HN a few months back, basically if your SDF was data based you could do a low resolution pruning pre-pass over the screen and remove the datapoints of the SDF that didn't contribute anything in that screenspace region. Other than that you can actually re-use many simpler SDF's to work as bounding spheres,etc. For example I did a kind of skinned character rendering that kinda started turning expensive and a simple way to accelerate it was to first do a sphere calculation that bounded it, if the sphere calc was producing a large enough value it was output directly instead of the "detail" value of the actual character. Now for a GPU that isn't ideal if one of the "threads" enters the character, but I think most GPU's do triangles one-tile-at-a-time so these threads will most of the time have converging calculations within each tile.
jb1991 5y ago
Raytracing with SDFs is actually not that efficient compared to all the optimizations available for raytracing polygons. And raymarching in particular can be quite slow due to the constant iterative nature of that process.

tiborsaas 5y ago

One huge benefit is the way you describe them. It's very concise. // This is a sphere length(p) - size; There are no polygons, just surfaces described with math. You can do operations with them, like addition, subtraction, deformation quite easily, which is also much more complex with polygon based 3D models. https://iquilezles.untergrund.net/www/articles/distfunctions/distfunctions.htm https://iquilezles.untergrund.net/www/articles/distfunctions...

pasabagi 5y ago

If you want to generate textures which you then read at runtime, this kind of technique is very useful - for instance, imagine you want to create the normal map of a cloud, or create a height map to displace vertices with (for a procedural landscape).

anentropic 5y ago
But using noise to generate textures isn't directly related to SDF (I think?) from other replies I think the point here is there are no "vertices", i.e. no mesh geometry
- pasabagi 5y ago
  Well yeah, but you can obviously use signed distance functions to create a texture (that's what a shader is doing) that can be used at runtime. Imagine you want to make the normal map for a bubbly surface, for example, but you also want the bubbles to be animated. One way of doing this would be to render the normals from a bunch of sdf spheres onto a 3d texture, which would then be used later. I don't use this a work - it's just an approach that I've had some success with at home. On my machine, complex fragment shaders are always slow - so maybe this kind of sdf-based approach works in realtime for other people.

SonOfLilit 5y ago

It's an easy to use and general mathematical language for describing geometry. It lends itself easily to parametrization for things like procedural generation of infinite variations or for animation. And it is very "local" so requires O(1) memory to evaluate. For a nonstandard use of the idea, see font rendering on the GPU with signed distance field textures: https://aras-p.info/blog/2017/02/15/Font-Rendering-is-Getting-Interesting/ https://aras-p.info/blog/2017/02/15/Font-Rendering-is-Gettin...

enriquto 5y ago

> Can someone help me understand why SDF-only techniques are valuable Out of computer graphics, I have used them a lot for modeling the evolution of curves and surfaces in a topologically-oblivious way. The terminology is slightly different (they go by silly names like "implicit snakes"), but it is the same thing. If you have ever used an "adaptive select" or "intelligent scissors" tool of a drawing program, it was probably implemented using this technique.

agys 5y ago

MagicaCSG is a graphical signed distance field editor (by the author of Magica Voxel). The example video and images demonstrate how SDFs can be used for complex modelling! https://ephtracy.github.io/index.html?page=magicacsg https://ephtracy.github.io/index.html?page=magicacsg