First off, having implemented the core CSG algorithm years ago and then bailed out on trying to do GUI around it, I can say that none of this project is easy. It’s an impressive piece of work.
This is one of the few cases where I read the HN comment thread, because it actually had a mix of architects, mechanical engineers, and CAD-software implementors talking about some subtle points I’d never thought about. It was comparatively free of invective and I do suggest reading it if that interests you, but I’ll give in to temptation and summarize what I got from it anyway. :)
Representations of 3D objects can be broken down into “brep” (“boundary”) data structures, and “frep” (“form”) ones. Breps include the triangle-soup thing that anyone familiar with game implementation knows, but there’s a generalization of them to parametric splines that’s apparently widely used in mechanical engineering especially. Freps include constructive solid geometry, and I assume also include implicit surfaces defined by a function that tests for point-containment, but CSG is what this tool does.
It turns out that CAD users have strong opinions on this topic. Apparently the very high-end tools allow mixing of breps and freps within a single document, which sounds very difficult to implement since both their performance characteristics and their editing affordances are very different from each other. This seems to be because breps with splines are the most useful for designing things with visual appeal.
There was a very interesting discussion, that got conflated with the brep/frep thing but feels orthgonal to it to me, about a tension between defining objects by reference to a mathematical or procedural model, vs. defining them by data alone, and how they each allow editing in different ways, and neither is convenient for every situation. Apparently the existing compromise is to use a constraint-logic solver, so that what you really have is data that knows the steps by which it was defined, and can retrace those steps in light of changes made downstream. CLP algorithms are hard to get right, so it’s impressive that they do this.
I can’t decide if I feel like this is an ultimately-best compromise, or just one that’s good enough for now, but my instinct is to want to come up with UI that visualizes the model atop the output, to the extent that its parameters are spatial… the trick would be finding a way to do this without an enormous amount of one-off code.
Of course one can also look at Antimony from the lens of it being a visual-programming framework; the HN audience didn’t touch on that at all. The graph-of-transformations model is fairly widely used at this point, especially in audio software, but Apple has a thing that uses it for graphics filters, and I’ve seen it in miscellaneous other contexts. This looks like a solid implementation of it; without playing with the software, I can’t speak as to the UI particulars, but the choice of nodes looks like a nice vocabulary to work with. It’s definitely pleasant that new node types are easy to define; that’s generally extremely difficult in these systems. (Feel free to read the VST and AudioUnit APIs if you want to see what I mean. :))
I’m a bit curious at the author’s motivation for using visual programming here - is it meant to make the tool accessible to an audience not used to thinking about imperative software? If so, that’s a reasonable choice but suggests to me as an aspiring language designer that we need better ways to visualize and edit DSLs. :) The primitives here are genuinely declarative, not imperative, so visualizing them doesn’t run into the impedance mismatch that one sees when trying to use the graph model to describe, say, stateful behavior over time (ugh, that one USB button-remapping tool I tried to use last year… never mind). But the model involves, to my mind, a distasteful amount of clicking and screen space for something I think of as relatively simple. Not this author’s fault, just a topic I’d love to have a better answer for…
Thank you for your excellent overview! I wonder if a Scratch/Snap-like nested-blocks interface would improve the visual density of the dataflow graph, for the parts that are actually tree-shaped rather than more general graphs?
(It would also be nice to have a little mini-visualization of the output of each node; I wonder if it’s possible to provide that efficiently? CATIA doesn’t do that, which suggests that with NURBS it may not be…)
I think Apple’s thing is Quartz Composer, which I’ve seen some remarkable work in.
one nice point about visual programming in this context is that it’s a good way to work with a feedback loop - it’s a nice smooth workflow to change one node and expect the displayed object to change in response, more so than editing a piece of text and running into potential syntactic/structural issues as well.
Having worked on commercial CAD software it’s hard not to point out all the reasons this won’t catch on with traditional CAD users.
I guess the most important part to keep in mind about Antimony is down at the bottom: “Antimony grew out of my work on powerful personal-scale CAD/CAM workflows…” I’m sure it works okay for “personal-scale”, but it will have a hard time beyond that without a lot more features.
Yes. Well, that was the point the HN thread couldn’t get past. :) They were convincing and I’m sure it’s true, but I feel bad for the author having to deal with people wanting the software to be something it’s not intended to!
First off, having implemented the core CSG algorithm years ago and then bailed out on trying to do GUI around it, I can say that none of this project is easy. It’s an impressive piece of work.
This is one of the few cases where I read the HN comment thread, because it actually had a mix of architects, mechanical engineers, and CAD-software implementors talking about some subtle points I’d never thought about. It was comparatively free of invective and I do suggest reading it if that interests you, but I’ll give in to temptation and summarize what I got from it anyway. :)
Representations of 3D objects can be broken down into “brep” (“boundary”) data structures, and “frep” (“form”) ones. Breps include the triangle-soup thing that anyone familiar with game implementation knows, but there’s a generalization of them to parametric splines that’s apparently widely used in mechanical engineering especially. Freps include constructive solid geometry, and I assume also include implicit surfaces defined by a function that tests for point-containment, but CSG is what this tool does.
It turns out that CAD users have strong opinions on this topic. Apparently the very high-end tools allow mixing of breps and freps within a single document, which sounds very difficult to implement since both their performance characteristics and their editing affordances are very different from each other. This seems to be because breps with splines are the most useful for designing things with visual appeal.
There was a very interesting discussion, that got conflated with the brep/frep thing but feels orthgonal to it to me, about a tension between defining objects by reference to a mathematical or procedural model, vs. defining them by data alone, and how they each allow editing in different ways, and neither is convenient for every situation. Apparently the existing compromise is to use a constraint-logic solver, so that what you really have is data that knows the steps by which it was defined, and can retrace those steps in light of changes made downstream. CLP algorithms are hard to get right, so it’s impressive that they do this.
I can’t decide if I feel like this is an ultimately-best compromise, or just one that’s good enough for now, but my instinct is to want to come up with UI that visualizes the model atop the output, to the extent that its parameters are spatial… the trick would be finding a way to do this without an enormous amount of one-off code.
Of course one can also look at Antimony from the lens of it being a visual-programming framework; the HN audience didn’t touch on that at all. The graph-of-transformations model is fairly widely used at this point, especially in audio software, but Apple has a thing that uses it for graphics filters, and I’ve seen it in miscellaneous other contexts. This looks like a solid implementation of it; without playing with the software, I can’t speak as to the UI particulars, but the choice of nodes looks like a nice vocabulary to work with. It’s definitely pleasant that new node types are easy to define; that’s generally extremely difficult in these systems. (Feel free to read the VST and AudioUnit APIs if you want to see what I mean. :))
I’m a bit curious at the author’s motivation for using visual programming here - is it meant to make the tool accessible to an audience not used to thinking about imperative software? If so, that’s a reasonable choice but suggests to me as an aspiring language designer that we need better ways to visualize and edit DSLs. :) The primitives here are genuinely declarative, not imperative, so visualizing them doesn’t run into the impedance mismatch that one sees when trying to use the graph model to describe, say, stateful behavior over time (ugh, that one USB button-remapping tool I tried to use last year… never mind). But the model involves, to my mind, a distasteful amount of clicking and screen space for something I think of as relatively simple. Not this author’s fault, just a topic I’d love to have a better answer for…
Thank you for your excellent overview! I wonder if a Scratch/Snap-like nested-blocks interface would improve the visual density of the dataflow graph, for the parts that are actually tree-shaped rather than more general graphs?
(It would also be nice to have a little mini-visualization of the output of each node; I wonder if it’s possible to provide that efficiently? CATIA doesn’t do that, which suggests that with NURBS it may not be…)
I think Apple’s thing is Quartz Composer, which I’ve seen some remarkable work in.
Nesting them when it makes sense to does seem helpful!
Yes, I was thinking of Quartz Composer there.
thanks for the summary!
one nice point about visual programming in this context is that it’s a good way to work with a feedback loop - it’s a nice smooth workflow to change one node and expect the displayed object to change in response, more so than editing a piece of text and running into potential syntactic/structural issues as well.
Yes, agreed. The UI of the blocks pretty much continues producing some form of output however you manipulate it. It’s a big plus.
I think something for Lego’s robotics kits uses something like that (LabView?) and I know UnrealScript used to have a visual editor like this.
This looks so cool! Seems a bit more beginner/experimentation-friendly than OpenSCAD!
HN thread. I’m looking forward to trying this out; it looks great :)
Having worked on commercial CAD software it’s hard not to point out all the reasons this won’t catch on with traditional CAD users.
I guess the most important part to keep in mind about Antimony is down at the bottom: “Antimony grew out of my work on powerful personal-scale CAD/CAM workflows…” I’m sure it works okay for “personal-scale”, but it will have a hard time beyond that without a lot more features.
Yes. Well, that was the point the HN thread couldn’t get past. :) They were convincing and I’m sure it’s true, but I feel bad for the author having to deal with people wanting the software to be something it’s not intended to!