Live data from Hacker News

Antimony – A fresh look at CAD software

mattkeeter.com

21–30 of 124 posts

Re: Antimony – A fresh look at CAD software

#21
> Antimony is a computer-aided design (CAD) tool from a parallel universe in which CAD software evolved from Lisp machines rather than drafting tables.

Funny, I'd be way more interested in the software engineering tools that are inspired by drafting tables than the mechanical engineering tools inspired by text editors.

If you spend some time with anyone proficient with the big CAD/CAE programs you will see how efficient they are. OpenSCAD and others are familiar to programmers so they are easier to learn, but if you learn CAD/CAE software they make text editors feel clumsy and slow. For an added bonus, use one of the input controllers specifically built for CAD/CAE, it opens a whole other world.

Re: Antimony – A fresh look at CAD software

#22
I like the interface, and being a Blender3D user, I like nodes. However, I am long AutoCad / Inventor user, and I don't see what's new. You could do CSG modeling in AutoCad with union, difference, and intersection, and in Inventor you have that and sketch-based parametric modeling; update the sketch, and the model changes. Go back in the history, and change a value, and the model changes. In AutoCad you could use AutoLisp and later VBA. So aside from the look of the interface, and nodes vs. a history hierarchy what distinguishes it from decades-old parametric modelers?

Re: Antimony – A fresh look at CAD software

#23
post #19

Having used OpenSCAD, Solidworks and NX fairly extensively, I can say that "code-based" solid modelling systems are good for some specific things - anything that is highly parametric, for example: * Gears and sprockets * Fasteners (nuts & bolts) * Electrical components (ICs, etc) For anything else they aren't at all suitable. It's just a million times easier to be able to click on dimensions on the actual sketch and…

> The main reason they exist is that it is much (like 100 times) easier to write a code-drive CAD system than a GUI-driven one. The reason they exist is because they are very well suited for making changes on the model ... on shallow and deep level. It might be easer to "click on dimensions on the actual sketch and change them" for a few elements, but try making a fundamental change without code. GUI vs. code/config…

Solidworks is parametric, too. You don't need code for that.

Re: Antimony – A fresh look at CAD software

#24
post #19

Having used OpenSCAD, Solidworks and NX fairly extensively, I can say that "code-based" solid modelling systems are good for some specific things - anything that is highly parametric, for example: * Gears and sprockets * Fasteners (nuts & bolts) * Electrical components (ICs, etc) For anything else they aren't at all suitable. It's just a million times easier to be able to click on dimensions on the actual sketch and…

> The main reason they exist is that it is much (like 100 times) easier to write a code-drive CAD system than a GUI-driven one. The reason they exist is because they are very well suited for making changes on the model ... on shallow and deep level. It might be easer to "click on dimensions on the actual sketch and change them" for a few elements, but try making a fundamental change without code. GUI vs. code/config…

A parametric modeler, i.e. every major CAD system in use since 1995, allows you to specify your dimensions based on formulas that use relationships between components. If you look at Solidworks or CATIA and think "man it must be slow to point and click to set dimensions" you are missing how it is actually used in professional practice.

The difference between point and clicking dimensions in those tools and how they are supposed to be used is greater than the difference between pecking in Notepad and being a power user in Emacs/Vim.

Re: Antimony – A fresh look at CAD software

#25
post #19

Earlier quoted context omitted.

> The main reason they exist is that it is much (like 100 times) easier to write a code-drive CAD system than a GUI-driven one. The reason they exist is because they are very well suited for making changes on the model ... on shallow and deep level. It might be easer to "click on dimensions on the actual sketch and change them" for a few elements, but try making a fundamental change without code. GUI vs. code/config…

A parametric modeler, i.e. every major CAD system in use since 1995, allows you to specify your dimensions based on formulas that use relationships between components. If you look at Solidworks or CATIA and think "man it must be slow to point and click to set dimensions" you are missing how it is actually used in professional practice. The difference between point and clicking dimensions in those tools and how they a…

Exactly my point. "Based on formulas that use relationships between components" means that they have internal language which if used well helps enormously.

Re: Antimony – A fresh look at CAD software

#26
post #22

I like the interface, and being a Blender3D user, I like nodes. However, I am long AutoCad / Inventor user, and I don't see what's new. You could do CSG modeling in AutoCad with union, difference, and intersection, and in Inventor you have that and sketch-based parametric modeling; update the sketch, and the model changes. Go back in the history, and change a value, and the model changes. In AutoCad you could use Aut…

Compared to AutoCad/Inventor, cost and licensing are two huge differences. Antimony is open source: https://github.com/mkeeter/antimony/blob/develop/README.md

Re: Antimony – A fresh look at CAD software

#27
Okay, I'm a CAD software developer instead of an actual CAD engineer, so my perspective may be a bit biased. But this CSG (constructive solid geometry) idea is not in any way new. The reason it's kind of obscure now is that spline-based boundary representation systems (B-reps) took over the market decades ago. If you think about, say, the latest car designs, those free-flowing shapes are pretty easy to do in B-rep, and quite hard in CSG. [1]

I've worked in CAD translators for the last two decades. Though both the IGES and STEP file formats include CSG modeling features, I have never implemented them. To the best of my recollection, I've never even had a request from a customer to do so. A pity, I think they'd be fun to try to implement... and most of the thorny bugs would officially be the B-rep geometry kernel's, not mine. :)

[1] http://en.wikipedia.org/wiki/Boundary_representation

Re: Antimony – A fresh look at CAD software

#28
post #6

To add a bit of historical perspective, AutoCad could be extended through Lisp (AutoLisp), back in the day. So I posit that this approach is nothing new and unlikely to be what the customers of CAD packages don't already have.

AutoCad can still be extended using AutoLisp. However, AutoLisp is one of several scripting API's rather than a "first class value" in the drawing database. AutoLisp also lacks a macro facility.

Re: Antimony – A fresh look at CAD software

#29
post #11

First off, great work! Looks promising. Does it use a geometric modeling kernel? e.g open source Open CASCADE ( http://en.wikipedia.org/wiki/Open_Cascade_Technology ) ? Two other open source CAD come to my mind that use Python as primary scritping language: FreeCAD and the unmaintained HeeksCAD: http://en.wikipedia.org/wiki/FreeCAD , http://en.wikipedia.org/wiki/HeeksCAD

It uses a homebrew kernel based on functional representations (http://en.wikipedia.org/wiki/Function_representation). Any function that comes out the end of the graph is rendered (as a bitmap) and blitted to the screen.

Re: Antimony – A fresh look at CAD software

#30
post #7

Looks nice. I have been working ten years professionally developing a CAD program, and if I could time travel and give my ten years younger self a single tip it would be to use a proper geometrical kernel (like CGAL) rather than doing anything with floating point. The tree rep is very cool. It could probably render implicitly using distance fields without even needing triangulation. http://iquilezles.org/www/articles…

Yes -- the images being drawn in the "3D" viewport are actually 2D bitmaps rendered directly from the f-rep then blitted to the screen (with a pixel shader that does proper depth culling on a per-pixel basis).
Post reply on HN