I hope somebody will continue this project. It's a few months away to be a serious alternative to Blender / FreeCAD for certain use cases, with a much softer learning curve.
----
Be aware that since it fundamentally works with SDFs, it is a somewhat different modeling experience (and stores different data) than traditional meshes with triangles, verts, etc.
Transforming it from SDFs into meshes could be done with marching cubes or similar, but you'd likely need to "clean up" such data afterwards in a Blender-style app anyway.
SDFs are great though, if your renderer is SDF-based, too (most are not).
[sorry if you knew this already, wasn't sure]
Thanks for reminding me that one of the best SDF renderers in the industry is stuck behind Sony, deemed a failure because Sony didn't want to publish it to PC (where all the dev scene is).
No disrespect to the author, it's impressive, but Blender gives you extreme control over mesh topology and this doesn't.
You still have to get decent topology out of the modelling package, and marching cubes aren't going to give you that. If you have to retopologize your sculpted model by hand to make it viable for use in a rendering pipeline you might as well have just started with good topology in the first place and save yourself the time.
But I don’t think it’s true. Why do you say SDFs don’t have finite resolution? There are no infinite precision SDF implementations. Meshes as a concept have no resolution limits either, you could in theory store verts in infinite precision, but in practice people usually use floats. It is the same with SDFs. In practice, the resolution limits are identical - it’s whatever you can store in a 32 bit float. It’s extremely common with SDF ray marchers to have a much higher threshold than the smallest fp32 delta, so I would say in practice, meshes probably have higher resolution than SDFs most of the time. And whatever, because it never matters. Nobody is pushing either SDFs or meshes to their resolution limits, and nobody wants that because you get visible quantization artifacts with both meshes and SDFs when you come anywhere close to the resolution limits.
But it's relatively trivial to make one. SDFs are technically polymorphic over the concrete number type used. They are intrinsically infinitely scalable and of infinite resolution, and you then compute an approximation that can be rendered according to the output constraints/requirements.
Meshes on the other hand are intrinsically finite. You've already baked in a finite precision at design time. If you're outputting a mesh, you're throwing away information.
It's like the difference between vector and raster graphics. Vector graphics clearly have superior properties when it comes to scaling and other transformations. Raster images still find more use, but vector graphics are starting to see more use for good reasons.
> whatever, because it never matters.
It's starting to matter more, particularly in CAD modelling where model reuse, parameterization by finite element analysis and other physics models, etc. are starting to align better with SDF.
I won't pretend to know as much about games or CGI in film, but I expect as the tools mature, it will just make sense to start adopting them there too.
> It’s like the difference between vector and raster graphics.
I get what you’re trying to say, but this analogy isn’t great. The difference between vector and raster is more like the difference between an SDF and a voxel grid. A mesh is really, literally, a type of 3d vector graphics, and so is an SDF. The difference between meshes and SDFs is the difference between vector graphics with line segments and vector graphics with CSG and round shapes. There is no inherent quantization of space with either meshes or SDFs like there is with raster images or voxel grids.
SDFs are not intrinsically infinitely scalable any more than meshes are. If you write an SDF to disk, the numbers representing the locations and sizes of it’s components will be rounded to fp32 just like the verts of a mesh typically are.
Meshes are not intrinsically finite, no information is being thrown away during the output process. The implementation of a mesh modeler does usually use floats, and so precision does have limits, but there is nothing about the concept of a mesh that requires using floats. Just think about it: one can, if one wishes, use infinite precision numbers to represent a mesh, there is nothing about the idea of a mesh that precludes infinite precision. The very same is true of SDFs. One can use infinite precision, but it in fact has never yet happened, all SDF implementations so far have used finite precision numbers (both to represent and to render SDFs).
> It’s starting to matter more
You started talking there about something unrelated to my point, and aren’t responding directly to what I said. I wasn’t arguing about the usefulness of SDFs at all, and SDFs having finite resolution doesn’t compromise their utility. SDFs aren’t useful because they have higher resolution, they are useful because they are a different kind of primitive with different properties, they have tradeoffs and so can meet certain goals better than other primitives.
How do you rig an SDF for animation (eg. skeletal, for a humanoid figure)?
Shame that NURBS never really took off in the gaming scene. I get it from a hardware standpoint (GPUs like triangles, and we can cut quads into triangles), but NURBs solve so many problems that trianglular meshes just hack their way around.
>How do you rig an SDF for animation
I imagine with the most unholy mathematical models imaginable. Dreams did it, so it's not impossible. But the results seen definitely don't measure up to a AAA standard (at least in Dreams).
I appreciate all the tangential discussions, but the two key points im trying to make are:
1) SDF's are not likely to supplant detailed hand modelled/cleaned up meshes any time soon, but will continue to be used alongside and in conjunction for all kinds of other cool stuff (soft shadows, ambient occlusion, fonts etc as seen in UE4/UE5)
2) ergo, a modeller based around SDF's is not going to replace mesh based modellers like Blender, Maya etc anytime soon, even to a small degree.
I don't think anyone fundamentally disagrees with you, but an author making a toy 3d modeler in a week usually doesn't have the goal to disrupt an entire industry. It's a nice place to consider on a fundamental level what tools like these could and couldn't do that current work flows cannot.
In the case animation, parameterize it by a global clock, and each frame the objects are in slightly different positions dictated by a rough physics model (like a person's skeleton).