Check out my first novel, midnight's simulacra!
OpenSCAD: Difference between revisions
Line 10: | Line 10: | ||
==<tt>use</tt> vs <tt>include</tt>== | ==<tt>use</tt> vs <tt>include</tt>== | ||
A SCAD file can include other SCAD files with either the <tt>include</tt> or <tt>use</tt> keywords. <tt>include</tt> statements are replaced with the body of the <tt>include</tt>d file (any <tt>include</tt>s or <tt>use</tt>s within the file are expanded). <tt>use</tt> only lifts <tt>module</tt>s and <tt>function</tt>s, and only affects the current file (i.e. recursive <tt>use</tt>s do not escape beyond the file that <tt>use</tt>s them). | A SCAD file can include other SCAD files with either the <tt>include</tt> or <tt>use</tt> keywords. <tt>include</tt> statements are replaced with the body of the <tt>include</tt>d file (any <tt>include</tt>s or <tt>use</tt>s within the file are expanded). <tt>use</tt> only lifts <tt>module</tt>s and <tt>function</tt>s, and only affects the current file (i.e. recursive <tt>use</tt>s do not escape beyond the file that <tt>use</tt>s them). These cannot be used within a <tt>module</tt> or <tt>function</tt>. | ||
It's useful to have a file draw its various modules, so that running it at the top level generates examples etc. Such a file can be imported with <tt>use</tt>, and these examples won't be drawn. The downside is that any variables declared in a <tt>use</tt>d file are unavailable, so you might want to wrap them in <tt>function</tt> accessors. | It's useful to have a file draw its various modules, so that running it at the top level generates examples etc. Such a file can be imported with <tt>use</tt>, and these examples won't be drawn. The downside is that any variables declared in a <tt>use</tt>d file are unavailable, so you might want to wrap them in <tt>function</tt> accessors. | ||
Generally, in each project I'll have a common file in which my base objects (and their geometry) are declared. Then I build up structures from these objects, relating them using the declared geometries. Be sure to declare the geometries of these structures as their own variables (composed from substructure properties). Then, for each print job, I have a file which <tt>include</tt>s this common file, and calls those <tt>module</tt>s to be printed. There shouldn't be any composition in these files, just any <tt>translate</tt>s, <tt>rotate</tt>s, and <tt>mirror</tt>s necessary to distribute the objects optimally on a print tray. Ensure they're distinct, so that slicing software can treat them as different objects (necessary for e.g. multimaterial printing). Finally, I have a file which assembles all the pieces together as they're expected to be assembled, serving as a check on the objects; neither this file nor the common file are exported to STL. |
Revision as of 08:12, 2 October 2024
OpenSCAD is a declarative 3d modeling program. Objects are defined in terms of basic 2D and 3D shapes, and a set of operators is provided to manipulate these objects. It can generate STL files from the command line.
Basic shapes
- square (rectangle), circle, polygon
- cube (rectangular prism), sphere, cylinder, polyhedron
circle and cylinder are approximated using the fn system variable. Low values of fn can be used to generate regular polygons. A cylinder can have different radii at its top and bottom. A right pentagonal frustrum, for instance, can be generated with cylinder using fn=5.
A 2D shape can be converted into a 3D one using linear_extrude or rotate_extrude().
use vs include
A SCAD file can include other SCAD files with either the include or use keywords. include statements are replaced with the body of the included file (any includes or uses within the file are expanded). use only lifts modules and functions, and only affects the current file (i.e. recursive uses do not escape beyond the file that uses them). These cannot be used within a module or function.
It's useful to have a file draw its various modules, so that running it at the top level generates examples etc. Such a file can be imported with use, and these examples won't be drawn. The downside is that any variables declared in a used file are unavailable, so you might want to wrap them in function accessors.
Generally, in each project I'll have a common file in which my base objects (and their geometry) are declared. Then I build up structures from these objects, relating them using the declared geometries. Be sure to declare the geometries of these structures as their own variables (composed from substructure properties). Then, for each print job, I have a file which includes this common file, and calls those modules to be printed. There shouldn't be any composition in these files, just any translates, rotates, and mirrors necessary to distribute the objects optimally on a print tray. Ensure they're distinct, so that slicing software can treat them as different objects (necessary for e.g. multimaterial printing). Finally, I have a file which assembles all the pieces together as they're expected to be assembled, serving as a check on the objects; neither this file nor the common file are exported to STL.