Is there anything that can be done with GPUs being so fast to trade computer time for developer time? Like, would a point cloud or some other approximation be easier to work with?
Yes! You've pretty much hit the nail on the head with your point cloud description, that's what the signed-distance-functions I was talking about basically are. You build a mathematical function that says whether a given point is inside or outside of your object and then you sample it a bunch of times and build a mesh based on that.
Works quite well on modern CPUs, works very well on modern GPUs. The library I linked to uses numpy and numpy is fast on CPU, but a newer tool like jax would let you run pretty similar code on the GPU even faster. All this machine learning stuff actually makes python a very good choice for complicated numerical stuff like CAD.
When I say "works quite well on GPUs" I mean "runs in real-time on a shader in a web browser" https://www.shadertoy.com/playlist/43cXRl . Note that none of those objects are meshes, it's a shader rendering the objects directly based on a signed-distance-function, every single frame.
You still need to turn your SDF/point-cloud into a mesh, but that means you only need to implement one algorithm, something like marching cubes is good enough and dual contouring is a bit more complicated but also more precise.
To clarify, can this method be used as a fully functional replacement to BREP for a mechanical (machine design) CAD system?
I am a robotics engineer and 100% of my work is open source (see my profile). I understand that without fully open source CAD it is hard to make fully open source machines.
If we were somehow able to rally support around a single project to create an open source CAD kernel and associated interface (perhaps built in to blender or FreeCAD to avoid building a new UI), what approach would you recommend? How long would you estimate it would take for three full time senior developers to get a useful system out?
Any thoughts are appreciated. I am at the extremely early stages in my career where I hope to learn to raise money for open source non profit hardware projects. Open source CAD is a sort of linchpin and without it we cannot succeed in quite the way we would like.
> To clarify, can this method be used as a fully functional replacement to BREP for a mechanical (machine design) CAD system?
I think so, but there are some open problems. Also it depends on the senior people. Inigo Quilez is a world class expert in this domain, and for the most part we're copying his work, get him on board and you'll be golden.
Fundamentally it makes sense, BREP is about representing boundaries and you can definitely use SDFs to represent the area under a boundary (infinite SDFs are possible, although obviously you can't turn them in to a mesh). Enclose a volume with boundaries and you can mesh that out just fine. A bit different from CSG-based SDFs, but entirely plausible.
>what approach would you recommend?
If I was to do this I'd take the constraint solver from solvespace (same one used in this post) and start using it to generate SDFs. At that point you're already 80% of the way to your end goal.
I mean if I was personally to do this I'd start by making a system that implements everything openscad can do, try to get some funding going, and than add in a solvespace based workbench for doing 2D cad that you can import into an openscad-ish language. You can see my efforts here: https://github.com/traverseda/PySdfScad
That's tackling it from a different angle than BREP though. I think that openscad but better is a surprisingly viable thing though, especially if you use it to do things like generate the gears/screws/whatever you import into your BREP based CAD project. Use scriptable CAD as the underpinning for more advances CAD.
> How long would you estimate it would take for three full time senior developers to get a useful system out?
Well define "useful"? Honestly I think you can get 80% done in under a month. I built the first pysdfscad in a week or two and replicated 80% of openscad's features. Fogleman built the library I used for pysdfscad in under a month.
I'd expect something pretty good in under a year at that kind of rate. There would be some outstanding problems, like it would be a challenge to figure out how to apply a fillet/chamfer to an edge, but not an insurmountable challenge. Geometry import is another place where you're going to spend a lot of time/money but is very important.
So let's say two or three years with three very competent seniors working on it to get a pretty good CAD program, with a GUI.
Thank you for this. It is encouraging that something like this could be done for under $1 million. I’m just dreaming right now but I think open source mechanical CAD is one of the low level pieces that could touch billions of lives.
It would be cool to put together some kind of foundation, with a working group and some kind of RFC process, to build a concrete plan which could then be used for fundraising.
It definitely would, yeah. I think the SDF stuff will come to fruit eventually. There's also Matt Keeter's libfive-studio available and I saw a solvespace maintainer in this thread asking about it. I think the open source community is getting skilled up for it.
That’s a good point. I am planning on following up with them soon about another project I am working on. I will see if there is any room to ask about this.
When I tried marching cubes and dual contouring against SDFs I ended up with a ton of performance issues that I was unable to resolve in the time I had allotted for experimenting. To get the resolution I needed I ended up with way too many triangles which used a lot of memory. I could later simplify the meshes but given the high number of initial triangles that process was quite slow. What I would like to explore (and hope that someone else does before me) would be a SDF optimized meshing algorithm that would make use of the extra distance and normal information.
I did not, I'm away from my notes at the moment so I don't remember which libraries I used. I used a couple of different ones but not OpenVDB. Next time I try this task I'll try OpenVDB and see how far I get. Thanks for the recommendation.
