Reconsidering OpenScad ExtensionsPosted: June 11, 2011
I have been putting quite a lot of work into OpenScad to get more interesting surfaces out of the thing. Why bother? At the current moment, the most common interchange format for hobby level 3D printers is .stl files. These are simply triangle based representations of objects. They are well understood, and easily turned into the appropriate tool paths needed by the 3D printer.
There are numerous tools available in the world which will allow you to do design, and export to .stl files. Most of the serious design tools, such as SolidWorks, cost many thousands of dollars, and have a multi-year learning curve to gain expertise. I recently purchased Alibre Software, which is only $99 to get started, but even that I find to be a challenge to get up and running with any sort of proficiency.
I know programming. For me, it’s much easier to construct a simple to medium complexity by writing a few lines of code, rather than trying to move triangles around on a mesh, and thus my interest in OpenScad. But, OpenScad has quite a few limitations as a language which make it very challenging, and downright difficult to get some easy things done. I find myself having to rethink how I do programming to fit within the confines of what it is capable of. One example is the lack of true variables within functions. Another is the fact that functions are not true expressions, but rather like macros which return a single value, and cannot have side effects.
Even so, I’ve done some work to create some new solids in OpenScad. I found myself wanting some ellipsoids, and toroids which OpenScad does not have natively. You can in fact create a toroid by simply rotating a circle around an axis, but it takes a couple lines of code, which I always forget. I want to be able to simply do this:
sor_torus(innerRadius = 15, size=[10,6]);
And generate the following picture:
That’s a toroid, with a cylinder unioned with it. In this case, the toroid has a cross section which is an ellipse, rathen than a circle. The Ellipse form is generalized, so it can be a straight circle if the two radii are the same.
This is good and usefule, and can be used in various designs for wheels, rings, bracelets, or what have you. It’s precise, non-confusing, and in actuality, you can control the number of facets used as well, to make it as smooth as you like.
Then there’s the Ellipsoid:
The ellipse is the more generalized form of a sphere. With an ellipse, you can specify two different radii to make that football shape. In OpenScad, this is achievable by using an intersection of two spheres properly placed. But, remembering how do do that intersection and doing it in such a way that you are sure you’ll get the exact dimensions you want might be a bit challenging for some. In this particular case, it was easy enough to use the following:
That’s very handy, and easy to remember.
These are known as surfaces of revolution. They are formed by taking some planar curve, or surface, and rotating it around an axis. I’ve created a library in OpenScad where I do a few surfaces of revolution. I call these revolids.scad. This reflects the fact that they are solids of revolution.
The cool shapes are not limited to toroids and ellipsoids. Since I did the Bezier library, I wanted to get them into the picture as well.
sor_bezier([[0,0,0], [0, 50,0], [20,10,0], [40, 0, 0]]);
The curve can be as fancy or as simple as you like. You can already do much of this using the built in rotation_extrude… that comes with OpenScad. It doesn’t support bezier curves though.
While doing these extensions has been fun, and made the things I can print much more interesting, I think it’s time to go in a different direction.
There is this new effort under way: http://www.rapcad.org In this case, the OpenScad language is being extended to include some basic features that are sorely needed. One is true variable support, and functions that are actually expressions, so can have full bodies. RapCad intends to add the Bezier functionality to its core as well, over time.
This is a good thing as it will further extend the capabilities of the text based design tools.
Another thing that is interesting is considering the interchange format in the first place. Using .stl files is great, because they’re easy to understand, and easy to turn into 3D shapes for a printer. The downside of them is that you lose core design information. If my machine knew I was trying to do a bezier surface, it might have a better way of commanding itself to render it than simply trying to trace out a tool path based on the triangle patches it got from the .stl file.
I believe it will be possible/desirable to send .scad to my machine directly. I believe I can create a .scad parser on the machine which can make much better decisions about tool paths that other forms of translation from .stl files.