6 ms·

The world doesn't need Text-to-CAD. The world needs a fully capable open source parametric 3D geometric CAD kernel. Solidworks, Creo, AutoCAD, Fusion, etc., ca

The world doesn't need Text-to-CAD. The world needs a fully capable open source parametric 3D geometric CAD kernel. Solidworks, Creo, AutoCAD, Fusion, etc., can all take their bug ridden unoptimized single threaded rent-seeking monstrosities and stick em where the sun don't shine. Seriously - if anyone wants to create an absolutely world-changing piece of software, start working on a new CAD kernel that takes the last 50 years of computer science advances into account, because none of the entrenched industry standards have done so. Don't worry about having to provide customer service, because none of the entrenched industry standards worry about that either. And no - while openCascade and solvespace are impressive, they aren't fully capable, nor do they start from a modern foundation.

dymk 3y ago
https://www.fornjot.app/ https://www.fornjot.app/ is an attempt, and also good at showing what a large undertaking such a goal is
auggierose 3y ago
So what's so difficult about such a kernel? What does a modern foundation look like?
- dymk 3y ago
  The math is quite difficult to do right, and there's a billion corner cases to make a kernel useful for real world designs. Take a fillet: It needs to handle inside corners, outside corners, compound angles coming in from arbitrary numbers of directions, it probably needs the ability to vary along its distance, create more geometry when adjacent faces don't leave enough room, etc etc. That's just the start of a single feature type. Now you need a bunch more feature types, and they all need to interact well with each other. The kernel also needs some way of solving the topological naming problem to be useful (FreeCAD might get a basic version of this after a decade(?) of work). It's probably tantamount to writing a modern-day browser in terms of complexity.
  - auggierose 3y ago
    I've written some custom code for computational geometry (like computing the offset for a geometric object using Apple Metal). It was a lot of fun, but also quite hard, and a lot of edge cases I just didn't deal with because I had a particular use case and speed was paramount. Maybe the idea of a "kernel" is the problem here. A kernel the size of a browser is not a kernel. I think what's really needed is a full-blown integration with a theorem proving system (which has an easier to define kernel of its own).
    - pca006132 3y ago
      I doubt if it is possible to have a practical small kernel. Take mesh processing in https://github.com/elalish/manifold https://github.com/elalish/manifold for example, we encountered a lot of problems when trying to deal with inexact floating point arithmetic. Using exact arithmetic can probably result in much simpler code (doesn't make sense in our case because the point of the library is about dealing with inexact arithmetic), but exact means slow. Also, a lot of code is about fast-paths that occurs frequently, data structures and algorithms that cut down complexity but are difficult to implement. Can we remove those fast-paths and complex algorithms? Probably yes, but this will slow things down a lot.
      - auggierose 3y ago
        I completely agree. You want to be able to be fast and correct, where correct also depends on some assumptions you can make depending on what you apply your algorithm to. That's why I think a theorem prover kernel is needed, which connects the various algorithms, and the theory behind them that is needed to prove correctness. Until you get there, you will have various different algorithms that don't really fit together, and where it is not clear how to make them work together and still be confident about the result.
        pca006132 3y ago
        While this would be nice, I don't think enough people working on these algorithms are trained to use formal theorem proving tools.
pca006132 3y ago
I think the interesting thing about CAD kernel is that there are different representations and limitations to each representation. You have triangular (or polygonal) mesh, BREP which uses NURBS, SDF which is based on functional representation. I have experience working with triangular meshes and SDF so here are my opinions about them, please correct me if I am wrong: 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 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/Shapes.rst#signed-distance-fields 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).
jf___ 3y ago
It seems a bizarre statement to state that OpenCASCADE isn't fully capable. Its the only OS licensed kernel that'll read a STEP file. Also "modern foundation" is a misleading statement, any CAD kernel bearing any kind of relevance seems implying a codebase that's been around for a quarter century. Like it or not OpenCASCADE is the hand that was dealt. I've worked with the technology [1] extensively and it provided the underpinnings for a startup I've founded [2]. pythonocc is the bees knees, it allows you to develop a proper CAD app. I'd consider CGAL a modern kernel, but it doesn't cover CAD since there is no BRep support [4] Don't take my word for it, but see also the many publications that have built on the tech [3] [1] https://github.com/tpaviot/pythonocc-core https://github.com/tpaviot/pythonocc-core [2] odico.dk/ [3] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=pythonocc&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=pyth... [4] https://www.cgal.org/ https://www.cgal.org/
- pca006132 3y ago
  Wondering why no BRep support means it is not a CAD. It seems that OpenVSP doesn't use BRep but uses parametric surface [1]. I wonder if mesh-based modeling + some constraints solving will get you a CAD, or are there other requirements that I don't know? I only work on mesh processing library on my free-time and I don't know much about BRep. [1] https://github.com/elalish/manifold/discussions/549#discussioncomment-6908272 https://github.com/elalish/manifold/discussions/549#discussi...
- wizzledonker 3y ago
  It does seem a bit of a throwaway statement regarding OCCT - I also work with it every day and, for the most part, it has all the same eccentricities and limitations of any large heritage-listed C++ library. There's a lot it can do!
- RobotToaster 3y ago
  >Its the only OS licensed kernel that'll read a STEP file. BRL-CAD does that too.
- digdugdirk 3y ago
  To be clear - I do think OpenCascade is impressive. Incredibly so, once one becomes aware of the magnitude of the problem it is trying to solve. I will also admit I haven't used it in the past couple of years, but when I did it's limitations in filleting and chamfering alone were enough to make it a non-starter for industry use. My broader point was that there is a need to start from a new paradigm that leverages the possibilities of modern, highly parallel computing hardware. The hardware requirements for performant and reliable CAD software are incredibly high, and their reliance on high clock speed single core processors is quickly being left behind by modern processing hardware.
wizzledonker 3y ago
Have you worked with Open Cascade recently? As someone who works with it every day for developing a CAD application, it would be interesting to know what people see as its limitations. It's the only geometry kernel I've had access to, and it seems like an absolute gift
- Kosirich 3y ago
  Can you share what you do with it? What kind of projects or industry is your application targeting?
- westurner 3y ago
  cadquery wraps OCC (OpenCascades) but used to wrap freeCAD. Here's a LEGO interlocking block brick in cadquery: https://cadquery.readthedocs.io/en/latest/examples.html#lego-brick https://cadquery.readthedocs.io/en/latest/examples.html#lego... . awesome-cadquery: https://github.com/CadQuery/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 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) https://news.ycombinator.com/item?id=37576296 https://news.ycombinator.com/item?id=37576296 build123d docs > Tips & Best Practices: https://build123d.readthedocs.io/en/latest/tips.html https://build123d.readthedocs.io/en/latest/tips.html BREP: Boundary representation: https://en.wikipedia.org/wiki/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 https://github.com/ManimCommunity/manim/issues/3362 NURBS: Non-Uniform Rational B-Splines: https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline 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 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) https://github.com/compas-dev https://github.com/compas-dev compas_rhino, compas_blender, - [ ] compas_o3de Blender docs > Modeling Surfaces; NURBs implementation, limits, challenges: https://docs.blender.org/manual/en/latest/modeling/surfaces/introduction.html https://docs.blender.org/manual/en/latest/modeling/surfaces/... /? "NURBS" opencascade https://www.google.com/search?q=%22nurbs%22+%22opencascade%22 https://www.google.com/search?q=%22nurbs%22+%22opencascade%2... OCCT (OCC) Open Cascade Technology: https://en.wikipedia.org/wiki/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_geom___b_spline_curve.html 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_geom___b_spline_surface.html 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.html#cadquery.Shape.toSplines https://cadquery.readthedocs.io/en/latest/classreference.htm...
virtualritz 3y ago
I agree 100%. 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. [1] https://github.com/ricosjp/truck https://github.com/ricosjp/truck [2] https://github.com/hannobraun/fornjot https://github.com/hannobraun/fornjot
- amelius 3y ago
  The main problem I have with most CAD software is that I can't do: 1. create an object, e.g. a cube 2. perform lots of random transformations 3. perform the inverse of the above transformations 4. subtract the object from the original object 5. end up with exactly nothing How are modern approaches solving this (robustness), if at all?
  - abrouwers 3y ago
    As someone who does CAD work (product design) every day, I'm curious about the use case? Starting with Surfaces (in Creo, at least) can be provide such flexibility.
    - amelius 3y ago
      I don't have a practical usecase, it's just the fact that most CAD software is not mathematically correct that bothers me.
      - 3y ago
mhb 3y ago
Maybe there's some way to throw money at Rhino to get them into this space. Love Rhino and McNeel.
jessfraz 3y ago
Our kernel isnt open source but we have an API, and we rebuilt our own CAD engine to fully utilize GPUs https://kittycad.io/modeling-app https://kittycad.io/modeling-app https://kittycad.io/geometry-engine 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.
- digdugdirk 3y ago
  Very interesting. Do you have information/documentation on the engine itself? I'm not seeing anything technical that explains what it is/isn't capable of, or how it relates to existing CAD kernels. Super cool work either way! I'll be wishing you luck.

dymk 3y ago

https://www.fornjot.app/ https://www.fornjot.app/ is an attempt, and also good at showing what a large undertaking such a goal is

auggierose 3y ago

So what's so difficult about such a kernel? What does a modern foundation look like?

dymk 3y ago
The math is quite difficult to do right, and there's a billion corner cases to make a kernel useful for real world designs. Take a fillet: It needs to handle inside corners, outside corners, compound angles coming in from arbitrary numbers of directions, it probably needs the ability to vary along its distance, create more geometry when adjacent faces don't leave enough room, etc etc. That's just the start of a single feature type. Now you need a bunch more feature types, and they all need to interact well with each other. The kernel also needs some way of solving the topological naming problem to be useful (FreeCAD might get a basic version of this after a decade(?) of work). It's probably tantamount to writing a modern-day browser in terms of complexity.
- auggierose 3y ago
  I've written some custom code for computational geometry (like computing the offset for a geometric object using Apple Metal). It was a lot of fun, but also quite hard, and a lot of edge cases I just didn't deal with because I had a particular use case and speed was paramount. Maybe the idea of a "kernel" is the problem here. A kernel the size of a browser is not a kernel. I think what's really needed is a full-blown integration with a theorem proving system (which has an easier to define kernel of its own).
  - pca006132 3y ago
    I doubt if it is possible to have a practical small kernel. Take mesh processing in https://github.com/elalish/manifold https://github.com/elalish/manifold for example, we encountered a lot of problems when trying to deal with inexact floating point arithmetic. Using exact arithmetic can probably result in much simpler code (doesn't make sense in our case because the point of the library is about dealing with inexact arithmetic), but exact means slow. Also, a lot of code is about fast-paths that occurs frequently, data structures and algorithms that cut down complexity but are difficult to implement. Can we remove those fast-paths and complex algorithms? Probably yes, but this will slow things down a lot.
    - auggierose 3y ago
      I completely agree. You want to be able to be fast and correct, where correct also depends on some assumptions you can make depending on what you apply your algorithm to. That's why I think a theorem prover kernel is needed, which connects the various algorithms, and the theory behind them that is needed to prove correctness. Until you get there, you will have various different algorithms that don't really fit together, and where it is not clear how to make them work together and still be confident about the result.
      - pca006132 3y ago
        While this would be nice, I don't think enough people working on these algorithms are trained to use formal theorem proving tools.

pca006132 3y ago

I think the interesting thing about CAD kernel is that there are different representations and limitations to each representation. You have triangular (or polygonal) mesh, BREP which uses NURBS, SDF which is based on functional representation. I have experience working with triangular meshes and SDF so here are my opinions about them, please correct me if I am wrong: 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 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/Shapes.rst#signed-distance-fields 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).

jf___ 3y ago

It seems a bizarre statement to state that OpenCASCADE isn't fully capable. Its the only OS licensed kernel that'll read a STEP file. Also "modern foundation" is a misleading statement, any CAD kernel bearing any kind of relevance seems implying a codebase that's been around for a quarter century. Like it or not OpenCASCADE is the hand that was dealt. I've worked with the technology [1] extensively and it provided the underpinnings for a startup I've founded [2]. pythonocc is the bees knees, it allows you to develop a proper CAD app. I'd consider CGAL a modern kernel, but it doesn't cover CAD since there is no BRep support [4] Don't take my word for it, but see also the many publications that have built on the tech [3] [1] https://github.com/tpaviot/pythonocc-core https://github.com/tpaviot/pythonocc-core [2] odico.dk/ [3] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=pythonocc&btnG= https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=pyth... [4] https://www.cgal.org/ https://www.cgal.org/

pca006132 3y ago
Wondering why no BRep support means it is not a CAD. It seems that OpenVSP doesn't use BRep but uses parametric surface [1]. I wonder if mesh-based modeling + some constraints solving will get you a CAD, or are there other requirements that I don't know? I only work on mesh processing library on my free-time and I don't know much about BRep. [1] https://github.com/elalish/manifold/discussions/549#discussioncomment-6908272 https://github.com/elalish/manifold/discussions/549#discussi...
wizzledonker 3y ago
It does seem a bit of a throwaway statement regarding OCCT - I also work with it every day and, for the most part, it has all the same eccentricities and limitations of any large heritage-listed C++ library. There's a lot it can do!
RobotToaster 3y ago
>Its the only OS licensed kernel that'll read a STEP file. BRL-CAD does that too.
digdugdirk 3y ago
To be clear - I do think OpenCascade is impressive. Incredibly so, once one becomes aware of the magnitude of the problem it is trying to solve. I will also admit I haven't used it in the past couple of years, but when I did it's limitations in filleting and chamfering alone were enough to make it a non-starter for industry use. My broader point was that there is a need to start from a new paradigm that leverages the possibilities of modern, highly parallel computing hardware. The hardware requirements for performant and reliable CAD software are incredibly high, and their reliance on high clock speed single core processors is quickly being left behind by modern processing hardware.

wizzledonker 3y ago

Have you worked with Open Cascade recently? As someone who works with it every day for developing a CAD application, it would be interesting to know what people see as its limitations. It's the only geometry kernel I've had access to, and it seems like an absolute gift

Kosirich 3y ago
Can you share what you do with it? What kind of projects or industry is your application targeting?
westurner 3y ago
cadquery wraps OCC (OpenCascades) but used to wrap freeCAD. Here's a LEGO interlocking block brick in cadquery: https://cadquery.readthedocs.io/en/latest/examples.html#lego-brick https://cadquery.readthedocs.io/en/latest/examples.html#lego... . awesome-cadquery: https://github.com/CadQuery/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 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) https://news.ycombinator.com/item?id=37576296 https://news.ycombinator.com/item?id=37576296 build123d docs > Tips & Best Practices: https://build123d.readthedocs.io/en/latest/tips.html https://build123d.readthedocs.io/en/latest/tips.html BREP: Boundary representation: https://en.wikipedia.org/wiki/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 https://github.com/ManimCommunity/manim/issues/3362 NURBS: Non-Uniform Rational B-Splines: https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline 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 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) https://github.com/compas-dev https://github.com/compas-dev compas_rhino, compas_blender, - [ ] compas_o3de Blender docs > Modeling Surfaces; NURBs implementation, limits, challenges: https://docs.blender.org/manual/en/latest/modeling/surfaces/introduction.html https://docs.blender.org/manual/en/latest/modeling/surfaces/... /? "NURBS" opencascade https://www.google.com/search?q=%22nurbs%22+%22opencascade%22 https://www.google.com/search?q=%22nurbs%22+%22opencascade%2... OCCT (OCC) Open Cascade Technology: https://en.wikipedia.org/wiki/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_geom___b_spline_curve.html 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_geom___b_spline_surface.html 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.html#cadquery.Shape.toSplines https://cadquery.readthedocs.io/en/latest/classreference.htm...

virtualritz 3y ago

I agree 100%. 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. [1] https://github.com/ricosjp/truck https://github.com/ricosjp/truck [2] https://github.com/hannobraun/fornjot https://github.com/hannobraun/fornjot

amelius 3y ago
The main problem I have with most CAD software is that I can't do: 1. create an object, e.g. a cube 2. perform lots of random transformations 3. perform the inverse of the above transformations 4. subtract the object from the original object 5. end up with exactly nothing How are modern approaches solving this (robustness), if at all?
- abrouwers 3y ago
  As someone who does CAD work (product design) every day, I'm curious about the use case? Starting with Surfaces (in Creo, at least) can be provide such flexibility.
  - amelius 3y ago
    I don't have a practical usecase, it's just the fact that most CAD software is not mathematically correct that bothers me.
    - 3y ago

mhb 3y ago

Maybe there's some way to throw money at Rhino to get them into this space. Love Rhino and McNeel.

jessfraz 3y ago

Our kernel isnt open source but we have an API, and we rebuilt our own CAD engine to fully utilize GPUs https://kittycad.io/modeling-app https://kittycad.io/modeling-app https://kittycad.io/geometry-engine 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.

digdugdirk 3y ago
Very interesting. Do you have information/documentation on the engine itself? I'm not seeing anything technical that explains what it is/isn't capable of, or how it relates to existing CAD kernels. Super cool work either way! I'll be wishing you luck.