6 ms·

I'm interested in the future of CAD. Here's a link to implicitCAD[0], a constraint-solving CAD written in Haskell. There's interesting discussion; apparently wh

by delish 11y ago

I'm interested in the future of CAD. Here's a link to implicitCAD[0], a constraint-solving CAD written in Haskell. There's interesting discussion; apparently what the author was trying to was proven by academic research to be Very Hard. Research he hadn't yet read! I've never done CAD, so I have nothing to contribute. I enjoyed the article! [0] https://news.ycombinator.com/item?id=9248174 https://news.ycombinator.com/item?id=9248174

ddingus 11y ago
Constraint solvers and geometry kernels are big, very expensive, beasts of software. They have grown over the decades, bit by bit, research yielding new approaches, as well as empirical, "Hey, I couldn't make this." use cases contributing to a very smart body of code with millions of man hours in it. Setting this tech aside, I would still classify CAD as an unsolved problem space. Even advanced kernels can and do fail, or generate erroneous geometry on what one would think is a common, or simple use case. That said, we are getting really good at basic geometry now. Those basic cases are much fewer and far between with most users just seeing robust operation now. It's taken many years for this to happen, marking time at the dawn of affordable solid modeling CAD in the mid 90's. Now, it's about getting computers to do what people can do, and that's infer intent as we do with our minds eye and analytic skill. It's also continuing to be about feature create, and that's all about how to boil down the UX of shape and intent description to the system. Also quite challenging. This kind of thing, as a branch in the "what's possible with CAD?" tree is pretty damn exciting! There are going to be a whole class of great use cases for this in the near future. Bear in mind, old feature create means and methods almost never die. They get sidelined, used less, whatever, but they continue to exist because there continue to be use cases they are excellent for. A lot of people think, "replace" when the real questions should be, "Add to, and what new things can we do?"
- jpfr 11y ago
  Big systems growing over decades are usually easy targets for drastic simplifications by building upon better abstractions. There's a great talk by Alan Kay titled 'Is it really "Complex"? Or did we just make it "Complicated"?' [1]. He shows for example the Nile system where they replaced several 10k of vector-graphics rendering code with 450 lines. An example from a different context is the miniKanren / microKanren approach to logic programming. It's basically Prolog fitting on a single page [2]. If a similar simplification and unification could be accomplished for representations of (solid) 3D objects, that would be a great great result. [1] https://www.youtube.com/watch?v=ubaX1Smg6pY https://www.youtube.com/watch?v=ubaX1Smg6pY [2] http://minikanren.org/ http://minikanren.org/
  - ddingus 11y ago
    Over very long time periods, we may see progress here, but inertia is huge. Take Parasolid. It's a very good kernel. Between it, Granite and the Dassault kernel, we have most of the world's geometry being handled on those kernels. Probably billions of man hours at this point. Interoperability is basically terrible. If it were me, I would see efforts to interoperable and infer intent, features, etc... as the most productive task. Those kernels aren't going anywhere, nor are the geometry use cases getting easier. A refactoring of all that is a very seriously expensive, time consuming task and still that body of data, intent, automation, etc... is there to deal with. It's hard to even think about an economically viable case. There are some trying with primitive, open kernels, and various takes on forks of the established ones. One vendor is dividing the kernel into well defined pieces do that other software can operate in those gaps and do so efficiently.
- brudgers 11y ago
  CAD will never be a solved problem space because ultimately it's the wrong problem space. The name of the blog shows why. The CAD problem space is an extension of "lines" as the design medium. It's implicitly premised on humans in the loop and creating human interpretible as a precursor to the artifact. There's an intermediate step that isn't strictly necessary and the CAD problem lives in that intermediate step. To put it another way, if I want a widget and I have the GCode and a 3D printer I'm pretty much done. I've bypassed the CAD space and more importantly it doesn't matter whether the GCode was generated via a DWG at some point or a computer program generated it directly without human intervention after searching through a million images from the internet. That kind of approach, however, is a problem for companies like Autodesk because without humans in the loop their product lines are obsolescent and Wall Street unhappy with management. The CAD industry depends on continuous rather than quantum change, because the obvious quantum change eliminates seats and with it per seat revenue models.
  - grp 11y ago
    True. And the fact that (from context space), non-CAD colleagues doesn't really know what CAD do, so you must do CAD otherwise it seems that you do not do your job, like pre- and post-CAD things...
    - ddingus 11y ago
      Great progress is being made on this. Basic CAD features are now on phones, and we are now able to do things electronically too. This has been a very long and expensive effort. Before we really see CAD marginalized in any real way, we will see it in everyday use first, and it will be easier. It already is. Kids can do it now on phones.
      - brudgers 11y ago
        It's not progress in any technical sense. I ran Autocad on an 8mhz 8088 PC with 1 megabyte of RAM. It was more capable than anything that runs on a phone these days. It could be automated with Lisp and command scripts. The interface could be altered with menu files. That's the CAD market, it's surface features not deep capability.
grp 11y ago
So you might be interested by the blog of Matt Keeter [1]. It's thesis is worth a read too [2]. [1] http://www.mattkeeter.com/projects/ http://www.mattkeeter.com/projects/ [2] http://www.mattkeeter.com/research/thesis.pdf http://www.mattkeeter.com/research/thesis.pdf
- mkeeter 11y ago
  Hi! Most of my recent work has gone into a CAD tool called Antimony, with documentation at http://mattkeeter.com/projects/antimony http://mattkeeter.com/projects/antimony
  - grp 11y ago
    Yep! But I forget that one cause it is not exactly what I want.. (btw, I plan to contact you when I have finished a prototype).

by delish 11y ago

ddingus 11y ago

Constraint solvers and geometry kernels are big, very expensive, beasts of software. They have grown over the decades, bit by bit, research yielding new approaches, as well as empirical, "Hey, I couldn't make this." use cases contributing to a very smart body of code with millions of man hours in it. Setting this tech aside, I would still classify CAD as an unsolved problem space. Even advanced kernels can and do fail, or generate erroneous geometry on what one would think is a common, or simple use case. That said, we are getting really good at basic geometry now. Those basic cases are much fewer and far between with most users just seeing robust operation now. It's taken many years for this to happen, marking time at the dawn of affordable solid modeling CAD in the mid 90's. Now, it's about getting computers to do what people can do, and that's infer intent as we do with our minds eye and analytic skill. It's also continuing to be about feature create, and that's all about how to boil down the UX of shape and intent description to the system. Also quite challenging. This kind of thing, as a branch in the "what's possible with CAD?" tree is pretty damn exciting! There are going to be a whole class of great use cases for this in the near future. Bear in mind, old feature create means and methods almost never die. They get sidelined, used less, whatever, but they continue to exist because there continue to be use cases they are excellent for. A lot of people think, "replace" when the real questions should be, "Add to, and what new things can we do?"

jpfr 11y ago
Big systems growing over decades are usually easy targets for drastic simplifications by building upon better abstractions. There's a great talk by Alan Kay titled 'Is it really "Complex"? Or did we just make it "Complicated"?' [1]. He shows for example the Nile system where they replaced several 10k of vector-graphics rendering code with 450 lines. An example from a different context is the miniKanren / microKanren approach to logic programming. It's basically Prolog fitting on a single page [2]. If a similar simplification and unification could be accomplished for representations of (solid) 3D objects, that would be a great great result. [1] https://www.youtube.com/watch?v=ubaX1Smg6pY https://www.youtube.com/watch?v=ubaX1Smg6pY [2] http://minikanren.org/ http://minikanren.org/
- ddingus 11y ago
  Over very long time periods, we may see progress here, but inertia is huge. Take Parasolid. It's a very good kernel. Between it, Granite and the Dassault kernel, we have most of the world's geometry being handled on those kernels. Probably billions of man hours at this point. Interoperability is basically terrible. If it were me, I would see efforts to interoperable and infer intent, features, etc... as the most productive task. Those kernels aren't going anywhere, nor are the geometry use cases getting easier. A refactoring of all that is a very seriously expensive, time consuming task and still that body of data, intent, automation, etc... is there to deal with. It's hard to even think about an economically viable case. There are some trying with primitive, open kernels, and various takes on forks of the established ones. One vendor is dividing the kernel into well defined pieces do that other software can operate in those gaps and do so efficiently.
brudgers 11y ago
CAD will never be a solved problem space because ultimately it's the wrong problem space. The name of the blog shows why. The CAD problem space is an extension of "lines" as the design medium. It's implicitly premised on humans in the loop and creating human interpretible as a precursor to the artifact. There's an intermediate step that isn't strictly necessary and the CAD problem lives in that intermediate step. To put it another way, if I want a widget and I have the GCode and a 3D printer I'm pretty much done. I've bypassed the CAD space and more importantly it doesn't matter whether the GCode was generated via a DWG at some point or a computer program generated it directly without human intervention after searching through a million images from the internet. That kind of approach, however, is a problem for companies like Autodesk because without humans in the loop their product lines are obsolescent and Wall Street unhappy with management. The CAD industry depends on continuous rather than quantum change, because the obvious quantum change eliminates seats and with it per seat revenue models.
- grp 11y ago
  True. And the fact that (from context space), non-CAD colleagues doesn't really know what CAD do, so you must do CAD otherwise it seems that you do not do your job, like pre- and post-CAD things...
  - ddingus 11y ago
    Great progress is being made on this. Basic CAD features are now on phones, and we are now able to do things electronically too. This has been a very long and expensive effort. Before we really see CAD marginalized in any real way, we will see it in everyday use first, and it will be easier. It already is. Kids can do it now on phones.
    - brudgers 11y ago
      It's not progress in any technical sense. I ran Autocad on an 8mhz 8088 PC with 1 megabyte of RAM. It was more capable than anything that runs on a phone these days. It could be automated with Lisp and command scripts. The interface could be altered with menu files. That's the CAD market, it's surface features not deep capability.

grp 11y ago

So you might be interested by the blog of Matt Keeter [1]. It's thesis is worth a read too [2]. [1] http://www.mattkeeter.com/projects/ http://www.mattkeeter.com/projects/ [2] http://www.mattkeeter.com/research/thesis.pdf http://www.mattkeeter.com/research/thesis.pdf

mkeeter 11y ago
Hi! Most of my recent work has gone into a CAD tool called Antimony, with documentation at http://mattkeeter.com/projects/antimony http://mattkeeter.com/projects/antimony
- grp 11y ago
  Yep! But I forget that one cause it is not exactly what I want.. (btw, I plan to contact you when I have finished a prototype).