3 ms·

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.

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 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.

cjbgkagh 4y ago
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.
- slavik81 4y ago
  Were you using OpenVDB? I'm not sure it solves that particular problem, but I found it to be a great library for dealing with this sort of data.
  - cjbgkagh 4y ago
    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.
TaylorAlexander 4y ago
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.
- traverseda 4y ago
  > 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 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.

cjbgkagh 4y ago

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.

slavik81 4y ago
Were you using OpenVDB? I'm not sure it solves that particular problem, but I found it to be a great library for dealing with this sort of data.
- cjbgkagh 4y ago
  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.

TaylorAlexander 4y ago

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.

traverseda 4y ago
> 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 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.