Triangular mesh is conceptually simple, but requires many faces to approximate curved surfaces with high precision (you may be able to use subdivision surface in some cases but intersection/union in those cases are more challenging). Also, for more complicated models, floating point errors really add up and you either have to use an exact representation (which is really slow) or try some other approaches which can be robust w.r.t. errors (e.g. https://github.com/elalish/manifold but it is really hard to get right). Another disadvantage comparing with BREP is the lack of constraint solving, which I will write about it below.
SDF is nice for mathematically defined objects. They are computationally intensive, so some sdf libraries use GPU to speedup the computation. There are approaches that can speed up the evaluation, but doesn't work well if the function is not really the distance (https://github.com/curv3d/curv/blob/master/docs/shapes/Shape...).
-----
Constraints solving: This is a big problem with mesh-based CAD. Traditional CAD usually allows you to have under-defined constraints, and users can iteratively set constraints until the model is fully defined. There is no such a thing (yet) with mesh-based CAD. Also, we don't really have nice ways to represent constraints relative to curved surfaces because there is no curved surface in our mesh...
Also, one particular challenge with text-based (or code-based) CAD is how to select the surfaces with an ergonomic API. GUI can solve this problem but writing a good GUI is a complicated task (that I am not willing to touch).
[1] https://github.com/tpaviot/pythonocc-core [2] odico.dk/ [3] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=pyth... [4] https://www.cgal.org/
[1] https://github.com/elalish/manifold/discussions/549#discussi...
Here's a LEGO interlocking block brick in cadquery: https://cadquery.readthedocs.io/en/latest/examples.html#lego... .
awesome-cadquery: https://github.com/CadQuery/awesome-cadquery
cadquery and thus also jupyter-cadquery now have support for build123d.
gumyr/build123d https://github.com/gumyr/build123d :
> Build123d is a python-based, parametric, boundary representation (BREP) modeling framework for 2D and 3D CAD. It's built on the Open Cascade geometric kernel and allows for the creation of complex models using a simple and intuitive python syntax. Build123d can be used to create models for 3D printing, CNC machining, laser cutting, and other manufacturing processes. Models can be exported to a wide variety of popular CAD tools such as FreeCAD and SolidWorks.
> Build123d could be considered as an evolution of CadQuery where the somewhat restrictive Fluent API (method chaining) is replaced with stateful context managers* - e.g. with blocks - thus enabling the full python toolbox: for loops, references to objects, object sorting and filtering, etc.*
"Build123d: A Python CAD programming library" (2023) >>37576296
build123d docs > Tips & Best Practices: https://build123d.readthedocs.io/en/latest/tips.html
BREP: Boundary representation: https://en.wikipedia.org/wiki/Boundary_representation
Manim, Blender, ipyblender, PhysX, o3de, [FEM, CFD, [thermal, fluidic,] engineering]: https://github.com/ManimCommunity/manim/issues/3362
NURBS: Non-Uniform Rational B-Splines: https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline
NURBS for COMPAS: test_curve.py, test_surface.py: https://github.com/gramaziokohler/compas_nurbs :
> This package is inspired by the NURBS-Python package, however uses a NumPy-based backend for better performance.
> Curve, and Surface are non-uniform non-rational B-Spline geometries (NUBS), RationalCurve, and RationalSurface are non-uniform rational B-Spline Geometries (NURBS). They all built upon the class BSpline. Coordinates have to be in 3D space (x, y, z)
compas_rhino, compas_blender,
- [ ] compas_o3de
Blender docs > Modeling Surfaces; NURBs implementation, limits, challenges: https://docs.blender.org/manual/en/latest/modeling/surfaces/...
/? "NURBS" opencascade https://www.google.com/search?q=%22nurbs%22+%22opencascade%2...
OCCT (OCC) Open Cascade Technology: https://en.wikipedia.org/wiki/Open_Cascade_Technology
OCCT > Standard Transient _ MMtg_TShared > Geom_Geometry > Geom_Curve > Geom_BoundedCurve > Geom_BSplineCurve https://dev.opencascade.org/doc/occt-6.9.1/refman/html/class...
OCC > Standard Transient _ MMtg_TShared > Geom_Geometry > Geom_Surface > Geom_BoundedSurface > Geom_BSplineSurface: https://dev.opencascade.org/doc/occt-6.9.1/refman/html/class...
Cadquery.Shape.toSplines(degree: int = 3, tolerance: float = 0.001, nurbs: bool = False)→ T https://cadquery.readthedocs.io/en/latest/classreference.htm...
digdugdirk has the right idea, and AFAIR, there is some work on that front (https://www.fornjot.app/).
Also the Fiat 500 goes 100km on about 4l of gas, while the Ford F150 uses 7l. No clue where the author gets the idea that the Fiat would get worse mileage, perhaps he's dividing by weight?
The rest, I don't even.
(yeah I hate it that Star Trek universe is not signing a deal with Lego)(I would much rather have a Enterprise than any Star Wars item)(https://xkcd.com/1563/)
Truck[1] and Fornjot[2] are recent attempts in the Rust space, both are WIP.
But both seem to be going the traditional way. I.e. B-Rep that can be converted to (trimmed) NURBS.
I think if one wanted to incorporate the last 50 years of computer science, particularly computer graphics, one needed to broaden the feature set considerably.
You need support for precision subdivision surface modeling with variable radius creases (either via reverse subdivision where you make sure the limit surface pass through given constraints or using an interpolating subivision scheme that but has the same perks as e.g. Catmull-Clark).
Then you need to have SDF modeling ofc.
Possibly point based representations. If only as inputs.
And traditional B-Rep.
Finally, the kernel should be able to go back and forth lossless between these representations wherever possible.
And everything must be node-based, like e.g. Houdini. Completely non-destructive.
Guns and other mechanical devices don't exist alone. A gun must interface with a bullet, a part of an aircraft must interface with other parts. So CAD AI must be able to understand the geometric context of the parts it is making.
That being said, I think AI will soon be capable of making mechanical devices. There has been some improvement in physical reasoning benchmarks like PHYRE[1]. Understanding physical reasoning and how multiple objects move with respect to each other is important in the synthesis of new mechanical devices.
SketchIt[0] demonstrated that by making reduced 2DoF description of how pairs of objects in a device may move with respect to each other, it's possible to synthesize a new device which performs the same function.
Solving PHYRE problems requires reasoning with larger degrees of freedom. The first example on the homepage has something like 5 objects which each have 3 positional DoF (translation and rotation). Even reasoning with 3DoF is quite difficult for approaches like those used in SketchIT.
Given that approaches like slotformer[2] already do somewhat well at solving these huge DoF problems, I don't think we're very far from AI being able to design complicated mechanical devices.
[0]https://dspace.mit.edu/bitstream/handle/1721.1/6773/AITR-157...
https://kittycad.io/modeling-app https://kittycad.io/geometry-engine
While we are not fully capable yet, that's the end goal by next year. Years from now we cannot still be using these single-threaded nightmares from 30 years ago.