Introducing Antimony, free graph-based 3D CAD system

Introducing Antimony, free graph-based 3D CAD system

It seems that boxes and noodles are slowly taking over the world. Matt Keeter uses acyclic graphs in Antimony, a free/libre 3D CAD system streamlined for personal manufacturing.

With QCAD, LibreCAD, FreeCAD, BRL-CAD, and less known projects like ZCAD you'd think we are more or less settled with free/libre software for 2D/3D drafting and modeling. But most existing apps are built around concepts that we know from DXF: layers, blocks etc.

Antimony takes a different approach and relies on graph composition where nodes represent 2D/3D shapes and primitives, boolean and math operations, various transformations etc. That will certainly please a lot of people who are already used to node-based compositing in VFX software.

The project was launched by Matt Keeter who currently works as engineer at Formlabs, a popular 3D printer/accessories vendor.

Editing (or should we say compositing?) in Antimony doesn't rely on just using noodles to connect boxes. The 3D view window also provides basic editing features. You can move an object along an axis or scale it, and corresponding nodes will be automatically updated in the graph composition window. So far Antimony only exports heightmaps for 2.5D processes and STL files.

Matt demonstrated the basics of using Antimony in this great video:

He also kindly agreed to answer a few questions about design specifics of Antimony and his future plans.

What was your main problem with existing CAD tools? I gather it has something to do with "drafting tables", lack of innovation etc. :)

First of all, a brief disclaimer: though I’m competent with Solidworks and Blender, I’m not a practicing mechanical engineer, so take my thought with a grain of salt.

That being said, most sketch-based CAD tools are based on manipulating a big blob of global state (in the form of sketches or solid models); there’s more emphasis on stacking machining operations than encoding user design decisions and intent.

There’s also a discontinuity between the modeling system (in the form of constraint solving and geometry kernels) and user interaction.

Antimony pushes that discontinuity a bit farther from view: instead of “extrude” being an opaque operation that does something in the geometry kernel, it’s a script that you can open up and change.

How much pluggable is everything? I see that nodes definitely are. What about file loaders / savers?

Nodes are very pluggable — Antimony looks into a particular directory on startup and builds up menus from “.node” files that it finds there. Loading and saving of Antimony files is all hard-coded in C++; not much room for modification there.

Exporting is somewhere in between: Python scripts can declare that they want to export something, which calls back into C++ and sets up the UI for an export process, but defining new export formats requires changing the application core (rather than scripts).

Is this something you think might/should change in the future, for both importing and exporting?

Maybe, but the cost / benefit ratio is too high at the moment — it would require some architecture changes, and there isn’t enough demand for custom import/export pipelines to warrant it.

So far Antimony looks like a tool best suited for 3D manufacturing. Do you think it could grow into more directions like mechanical engineering (which means FEM and assembly among other things), architecture and BIM workflows, etc.? Would the app's architecture allow for that? Would it even be a good idea?

I’m definitely focused on personal-scale manufacturing at the moment, making tools for individuals and small teams that work with laser cutters, 3D printers, small mills, etc. This is mostly because of my background — when I was at CBA [MIT's Center for Bits & Atoms — LGW], I did a bunch of work with these smaller-scale tools.

Working with assemblies is a natural extension: once I add graph nesting, it will be very simple to create a top-level file that combines a bunch of parts. For bigger systems and architecture workflows, I’d start getting more concerned with evaluation and rendering speed. On the rendering side, there’s an interesting optimization of creating / caching meshes to save on f-rep re-evaluation when the camera angle changes.

The case of assemblies is particularly interesting, because it might mean huge graphs, and that might impact navigation (among other things). Have you tried creating really large graphs (how large?) and seeing how it works in terms of performance, usability etc.?

The largest stuff that I’ve seen is about ~100 nodes. If those graphs are building a small number of parts (rather than multi-part assemblies), rendering isn’t a huge concern. The bigger challenge is in editing the graph — it’s still responsive if you’re editing things downstream, but making a change to a far-upstream parameter causes a noticeable pause as every script re-evaluates itself.

I think that there’s a lot of low-hanging fruit for speeding up big graphs. For example, I’m not even taking the obvious step of saving compiled Python byte-code; every node is being evaluated as a string (even if the text hasn’t changed).

What's your current development focus?

Right now, I’m doing a bunch of polishing for the 0.8.0 tagged release. One of the big changes is to the library of nodes: a few different people have written nodes, all with different styles and using different ways to define shapes; I’m doing a pass over the library to make it consistent and to make sure that all of the shapes are available in the fab.shapes module.

There are also a bunch of small bug-fixes and polishing going into 0.8.0.

Beyond that point, an unordered list of bigger tasks that I’m considering:

  • Switching to a QML-based UI
  • Optimizing graph evaluation speed (caching, delayed parsing, etc)
  • Computing gradients exactly rather than approximately (for better shaded rendering)
  • GPU-accelerated rendering
  • Using meshes to make rotation in the 3D viewport faster
  • Nested / hierarchical graphs
  • Reviving and extending the (bit-rotted) test suite
  • Figuring out how to build / package for Windows (help appreciated!)
  • Rethinking drawing planes (right now, 2D shapes are always in the XY plane).

Currently Antimony is available in source code and DMG builds for OS X users.

Was it useful? There's more:

18 Responses. Comments closed for this entry.

  1. I find this is a genius approach to modelling. I’ll be trying this software very soon and provide as much feedback as possible.


  2. Graph , graph everywhere LOL :D

  3. You forgot to mention the well-known which uses a functional-style syntax instead of the graphic node editor.

  4. @Alessandro, I didn’t forget to mention it, I just didn’t do it :)

  5. graph everywhere :D

  6. Nice Software, but why a standalone software?
    Why not a plugin for FreeCAD or OpenSCAD ?

  7. Alexandre Prokoudine 01 June 2015 at 5:11 pm

    @nicolas, Because it requires rethinking the architecture of either FreeCAD or OpenSCAD?

  8. Wi version please :-)

  9. please also include this application tutorial

  10. Alexandre Prokoudine 02 June 2015 at 9:15 pm

    @Flo, nice! Although, maybe 32bit build too for the less fortunate? :)

  11. I could, but do not have 32bit system at hands right now.

    As I was asked at github how I made the package, I made
    where I described the process.

    Obviously, you will have to switch amd64 with i386 in Debian/control and package name.


    Thanks, Flo, but it doesn’t work for me.  This is what I did with a fresh Xubuntu 14.04 install in Virtualbox:


    $ sudo dpkg -i antimony_0.8.0-1~openArtist1_amd64.deb
    $ sudo apt-get install -f
    $ antimony
    /usr/bin/antimony: line 4: ./antimony: Permission denied
    $ cat /usr/bin/antimony
    export LD_LIBRARY_PATH=/opt/antimony/lib:$LD_LIBRARY_PATH
    cd /opt/antimony/bin

    $ sudo chmod 777 /opt/antimony/bin/antimony
    $ antimony
    ./antimony: /usr/lib/x86_64-linux-gnu/ version `CXXABI_1.3.8’ not found (required by ./antimony)


    Any ideas?  (Yes, I am a noob, but pretty good at Google.  :grin: )

  13. first problem: my fault, fixed.

    second problem:
    looks like I use already gcc 4.9 by default, you have 4.8;

    sudo add-apt-repository ppa:h-rayflood/gcc-upper

    will fix it.

  14. ok, I recompiled the program now with gcc 4.8

    I also fixed a problem in the package with missing lib/plugin libraries folder

  15. nice 3d cad system. I am looking for any app which can convert simple video to 3d. Top Photo Editing Apps

  16. Is this software fully developed or still in beta version? By the way, I like the “Graph Everywhere” pic, lol!

  17. It’s a good system for CAD, right? It could help us do a lot of things with our computers.