Ao is a tool for programmatic computer-aided design using Scheme | Hacker News Reader

Ao is a tool for programmatic computer-aided design using Scheme

mattkeeter.com

148 pointsamirouche43 comments

This is a CAD tool truly worthy of the association with scheme. And I'm not just saying that: It provides minimal primitives for maximum power and flexibility. That's scheme in a nutshell.

It's also, not by coincedence, really, really cool.

Ao's author here – I'd be glad to answer questions.

Having looked through some of your other projects there is some really amazing work you have done. I was wondering the graph node code you wrote. What does it use for library to render them to the screen?

I assume you're talking about Antimony. Its graph UI is done in Qt, using the QGraphicsView framework. That section of the code is at https://github.com/mkeeter/antimony/tree/develop/app/canvas

What separates this from Antimony? Would you use one over the other in certain contexts? Why?

Antimony [1] is stable and user-friendly. You can get started without knowing about the underpinnings, just by connecting predefined shape nodes into a graph – basic modeling is possible with just the mouse, as shapes can define handles in the UI. Using Python for scripts is also a bit more accessible than Scheme. The downside is that hacking raw shapes is less pleasant, because they're defined as strings implementing a DSL. Developing on Antimony is also slower – much of the code is UI and glue to attach the geometry + graph engines.

Ao is more experimental and unstable. It's much lower-impedance for folks that want to work directly with f-reps, but doesn't have a click-and-drag UI with which to get started. The geometry kernel is also newer than Antimony's, and has slightly better performance. From a development perspective, I can play more easily with new algorithms without a cumbersome UI.

For folks that aren't as comfortable with coding, Antimony is the right choice. For f-rep development, Ao is the right choice. Otherwise, it's a matter of personal preference.

[1] https://github.com/mkeeter/antimony

I wouldn't say Python is more accessible. Considering this will be used by first time programmers who just want to design to print, and given that Scheme has less semantic baggage than Python, I'd wager that it's a better choice. Also, the data-driven nature of things is more natural to manage in a Lisp dialect.

I think it'd be killer if you could combine the user interface of Antimony with the same inspectability Ao. What would it take to achieve an Antimony-like UI on top of Ao?

I'm currently writing a toy library to play with hierarchical graphs – if Ao is a minimal implementation of Antimony's CAD, this will be a minimal implementation of the graph engine.

Beyond that, it's a small matter of programming – I'd want to find a UI paradigm / library that's less cumbersome that Antimony's, as the UI programming adds a lot of impedance to development.

Your projects are really impressive! Can you tell us a little bit about your background, and how you developed a proficiency with graphics programming?

I started this kind of tool-building in grad school, where I implemented a bunch of algorithms from the research literature and combined them together in interesting ways.

Implementing interesting algorithms is a good way to get a feel for the problem space, and it drags a bunch of the UI/UX considerations along with it – once you've created the crux of a particular tool, how do you expose it to a user (or just yourself while testing) in a way that makes sense?

What about it is impressive? Could you elaborate?

Do you have plans on creating tutorials for walking people through modeling basic things?

I've wanted to get into doing some ME stuff but I can never get past how "made by engineers, for engineers" CAD software is.

I am writing another comment here since I just had a play with Antimony and boy do I have to say my mind has been blown.

Please please please tell me that you intend on either keeping that project alive or moving it's features into Ao. This is the first CAD software I can understand.

It not only combines the logical ordering I have grown to love as a programmer but the instant feedback of playing with legos. It's the only way I can describe it.

You've blown my mind completely tonight. I've stayed up 5hr after when I like to hit the hay just to play around with this software and am I amazed.

Really hope to hear back on this.

Glad to hear that you're enjoying Antimony!

I'm planning to keep either Antimony or something similar alive into the future. Antimony is approaching convergence, so development has slowed down – not sure whether major new features will land there or in a successor (because I'm not sure what the next big features should be).

The trajectory may be to use Ao's kernel plus a new graph engine to make an Antimony successor. Ao is a powerful system, but I'd like to keep providing a tool with a friendlier UI and lower barrier to entry.

I've been a programmer for a very large portion of my life and have to say that I, personally, don't feel that code is an appropriate way to express 3d shapes. This is in my opinion of course.

For you, given your obviously gifted talent for this sort of thing, it might actually be much much easier just to have a software interface. I don't thing most of the population is like this.

I'd say for most a visual graph display is more natural a conversion of our ideas to shapes then text is. That combined with the live updating models and you've got yourself a winner.

For the more technically inclined you also get to play around with ADDING blocks (via the script block) which is a perfect bridge between the technical side and the conceptional side.

As for features, I'd like to suggest a few things that might be helpful.

For the node graph system, I'd say take some ideas from Unreal's UDK.

  1. Comment Blocks that can be dropped around large block groups
  2. Ability to rout "cables" the way you'd like (Snap to a "junction" then to where you'd like to take it)
  3. Select colors of wires.
  4. The ability to collapse and expand XYZ from floats to a Point object (making it a single value) for nicer routing.
  5. Variable declaration

Outside of that, something that would be interesting for larger scale design, it would be nice to be able to load multiple "mini-projects" into one larger project. When designing an engine for a car it would be nice to be able to make every complex shape it's own project. From that state you could import it into a larger complex project to fit all the parts together how it should look in the end.

That alone would be a massive undertaking. But my begging hand is still out: I'd like to be able to "simulate" what will happen. Adding this feature takes your project from simply being one of the best open source CAD projects I've ever seen to being one of the best cad projects I've ever seen. For me rivaling the usefulness of Fusion 360, Autodesk, Creo, the likes.

Aside from that, maybe add a more traditional interface in which I can right click on the model and say "3d->extrude>cylinder" and visually in the model edit the project while also changing the node graph.

I've got to say this if no one else has told you this yet: you're on to something big with this software and I DO hope you keep it up. You're building something that will bring engineering into the hands of us mere mortals. Coming from CS it's crazy to find the huge lack of open source tools and documentation in this space that you are seemingly fixing single-handedly.

Keep up the good work! Well, I should say the amazing work!

Second on mind being blown. Great work you have done here!

Long time 3D/CAD Schemer/Lisper here. I've tried OpenSCAD, programming FreeCAD in Python, Blender3D, and others. AutoLISP was OK as long as you had AutoCAD. Creating parametric shapes in Blender3D in the mid-2000s was cool.

I had used SDRC's IDEAS and AutoDesk Inventor for work, but I was always looking for a more programmatic way of doing things, since sometimes the concepts were more 'organic'. Tools like Rhino at the time were grabbing some of that market, and they had scripting. I dug into Open Cascade a bit, but I am not as skilled as you are, and I got lost in their link to analysis tooling too.

I think the term computational design is a good one. The same way I think computational intelligence is better than the artificial intelligence moniker.

This project, Rosetta, seemed interesting in using Racket to bring a general CAD programming language to work as a Front end for various CAD systems - Rhino, AutoCAD and future ones [1] [2 PDF].

I will be following you closely, since I think your other projects are cool too!

[1] http://web.ist.utl.pt/antonio.menezes.leitao/Rosetta/tutoria...

[2 PDF] http://papers.cumincad.org/data/works/att/acadia11_196.conte...

I've been foaming at the mouth to try Ao. Are you ever planning to make a Unix or Windows release?

Folks are building it on Linux already, generally with success (and failure to build on Linux is considered a bug, so raise a Github issue if that happens).

Windows is less likely, as Guile (an FSF project) doesn't have an officially supported build. It looks like people have made it work [1], but there would be a lot more messing around involved.

[1] https://github.com/Madsy/guile-automatic-build

Add in a REPL server so that I can make cool designs from Emacs and I'm sold. I'm a big Guile fan so this is a very exciting project for me.

This was on guile-user and no one seemed interested.

http://lists.gnu.org/archive/html/guile-user/2016-06/msg0004...

Github repository: https://github.com/mkeeter/ao

I was just about to ask where the download button is :)

Does Ao compute a mesh from scheme instructionz? or it is a trick? Basically can you dump the code that generates the things in a format that is efficient for a real time application?

Oh! And thanks for using GNU Guile Scheme :)

The Scheme functions go through a JIT-ish pass into a representation that's efficient for rendering.

Details are at http://www.mattkeeter.com/projects/ao/jit.html

Rendering is done with pixel-perfect rasterization of the function. Models are only gets converted into a mesh when you're exporting.

This may change in the future, as it's much easier to spin around a mesh – the right strategy is probably a low-res mesh for interactivity, which gets replaced with a pixel-perfect rendering (running in the background until complete).

I wonder if using a generic procedure would work better than redefining + outright. If you opened up Ao and typed (+ 1 1) at the REPL, would you see 2 as the result or a token object?

The redefined + only behaves differently when one or more of its arguments is a token object, so normal math works fine.

Generic procedures may be a cleaner way to do this, but I only discovered GOOPS after this implementation was already working.

>The redefined + only behaves differently when one or more of its arguments is a token object, so normal math works fine.

Ah yes, I'm just blind and missed the implementation in your article. Thanks for explaining!

Again:

http://lists.gnu.org/archive/html/guile-user/2016-06/msg0002...

Nobody ever listens to me:

https://news.ycombinator.com/item?id=12033059

I don't get it, has he given up on Guile or not:

http://lists.gnu.org/archive/html/guile-user/2016-06/msg0002...

I got Ao to a working state a few months before that exchange on the guile-users mailing list.

Guile works fine for Ao – it's clean and simple, plays nice with C FFI, and has a good REPL.

Racket was lower-impedance for the project discussed in that thread (and certainly has better documentation), but seems a bit heavy-weight for embedded use.

Racket always seemed a bit heavyweight to me in general. I'm more of a CHICKEN fan myself, though. You clearly are on the other side of that particular fight (r6rs vs. r4/5/7rs) though. Which is fine.

Finally something that looks like it could replace the horribleness that is openscad.

What's so bad about openscad? I haven't really worked with it, so I'm kind of curious.

As far as I remember, the language was severely limited, and it's yet-another-syntax to learn for no discernible benefit.

Ah. Yeah, I can identify. This is exactly the reason I prefer Guix to Nix.

Shameless self promotion, but you might be interested in scad-clj [0]: a DSL to write OpenSCAD with Clojure. You can get a decent interactive environment combining an editor with an OpenSCAD window set to only show the render [1].

[0] https://github.com/farrellm/scad-clj

[1] https://adereth.github.io/blog/2014/04/09/3d-printing-with-c...

You might also check out ImplicitCAD. Haskell-based. http://www.implicitcad.org/faq

If you are interested in this kind of thing you might want to check out OpenSCAD [0].

It's a similar idea: scripting behind cad.

[0] - http://www.openscad.org/

The references section in the github repository is short but very good: https://github.com/mkeeter/ao/blob/master/doc/references.md

Apropos of nothing, whenever I see blue and red fonts close together, as in the first image or my recent Spacemacs configuration, my brain tries to interpret it as a 3-D image.

It's been years since I've seen a blue/red 3-D image, but the effect is still there. Is it just me?

Are you using a quadtree-like algorithm or filling curve? to create the mesh or you can compute edges from the math tree of operations? or it some of both? Otherwise said how does it approximate the final 3D.

This is really cool! Next time I need CAD software I know where to look. Maybe I'll actually buy a 3d printer and start playing around now that there's a good modeling software option.

Reply on news.ycombinator.com