brl-cad and python

brl-cad is a full-featured cad package. All the power is there that you could need. It's almost 20 years old and has had extensive use by American military folks developing entire mechanical systems. It's also still under active development under a free license. They're working on the interface, I'm told, but it's usable right now.

If you don't like their interface, you can describe your object in Python. I wrote a quick brlcad class. You feed it python statements and it returns objects that output brlcad commands. You can pull these commands into brlcad using the 'source' command. All the primitive shapes are there, and you can do the usual CSG stuff.

So here it is, along with a simple example that shows how this might be used to easily build up parts from parts from parts. There's even a simple Makefile if you're so inclined (you'll have to edit the path in it):

It's tagged in svn as brlcad-0.2 at/users/vasile/tags/python_brlcad-0.2. I suppose this belongs in /tags, but I didn't feel comfortable writing outside my sandbox. It's also attached as a tarball to this post.

If you want to improve the code, the live repo is in svn at:
/users/vasile/brl-cad/brlcad.py
/users/vasile/brl-cad/primitive.py

It's GPLv3. Patches welcome.

Nice.

I don't know that this will really be easier to use than the BRL-CAD interface (it's still using text to define visual objects, which always takes creative thinking), but I wonder if this could be used as the basis for a BRL-CAD GUI written in Python. Python is easier to code than C, which I assume is what the majority of BRL-CAD packages are in.

Cool! How about some tutorials on how to get the python to work and a nice users manual and "how to" tutorials that won't horrify newbies?

It seems worth note that a good chunk of the BRL-CAD stuff is written in TCL - in fact, what you've written here is translating from Python to TCL, because mged's commands /are/ TCL, as is their ascii representation for databases, etc...

On the matter of a new GUI - if you like TK, you can load that straight from mged as it stands and make whatever extensions you want... although I can understand wanting to use python, even if I don't really see the draw of it over a Lisp.

It also just makes me very happy to have even just a for loop in my cad program's interface, and I've plenty more than that

I considered lisp for all of this. Python had a few advantages:
(1) it's easy to learn
(2) most people are afraid of lisp or don't know it
(3) writing Python classes is very fast

I agree that lisp is theoretically preferable but in actual wide application, Python it is for now. Of course, if there are a bunch of lispers hiding in the fab world, that would be different...

Lisp has the advantage of being used by AutoCad. I don't know much about it, but if using lisp would gain access to a library of AutoCad parts, that might be a compelling feature. But I've never used AutoCad, so I wouldn't know.

At any rate, if somebody wants this to go forward as a lisp package, code up something equivalent to what I've just done in Python and we'll go from there.

I suppose what I'm really not clear on is what this gets you; it feels like python for the sake of having python syntax to me. Using mged already is programming the part; I've attached the preliminary source for the rotor part of the 'turbine' command I'm working on ('generate a turbine fitted to the head and flow rate of this stream'). All that's needed to use it is to source the file in mged (or from another file run to mged), and run something like

rotor 10 -45 10 3 5

for a rotor with an angle at the outer edge of 10 degrees, an angle at the inner edge of the blades of -45 degrees, a radius of 10 units (whichever the rest of the program is using), a blade depth of 3 units, and five blades. (the math doesn't take into account several things it should, but it's not done yet either. Also, apologies for the lack of commenting, but it's short at least...).

As it happens, I'm discovering tcl to be quite comfortably lispy - they're even working on getting continuations, which not even all lisps have.

I could understand better if this were a binding for libged (admittedly in progress) for python, but it's not; it's just layering python over the top of tcl.

In terms of the autocad lisp, from what I've read it's a somewhat arcane and old variant, but it's fairly straightforward most of the time to translate - I'd not expect more than a few 'autocad macros' to be needed.

Yep, Python syntax is what you get. Defining objects as objects and all that. i never liked TCL. And I never found it lispy. Scheme, now that's lispy.

Consistent, simple syntax (although more explicit than most lisps), a facility equivalent to real macros, proper tail recursion and first-class continuations on the way... seems lispy to me. True that it doesn't appear to be writing a tree of operations directly, but I never said it /was/ a Lisp... and given that Scheme is one of the two dominant dialects of Lisp, I'd hope it's lispy - and it drives me up a wall to not have first-class continuations in CL, even though I generally prefer it.

That said, is there a reason you aren't using something like ctypes and libwdb for this? If you're just doing compile-style generation of geometry, that's exactly what libwdb is for, and that'd keep you from needing to do anything with TCL or mged at all, and make it easier to add libged's functionality when it gets that far. Looking at ctypes, that should be close to trivial, and certainly easier than mucking about generating input for mged.

Nope, no reason. Just sat down and pushed out the code in a weekend, so not much planning went into it. I imagine if I add functionality to it, libwdb will be on the list of things to do.

C is the second most popular language, it means a plenty of programmers prefer it-let it continue to rule brlcad's code!