Werner's Miscellanea
Sign in or create your account | Project List | Help
Werner's Miscellanea Git Source Tree
Root/
Source at commit 2db4c1a3a80a5d22de58ed81b9932afe7ea15626 created 12 years 8 months ago. By Werner Almesberger, cad/test1/: experiment with Free scripted CAD systems (OpenSCAD and Cadmium) | |
---|---|
1 | Comparison of Free scripted 3D CAD systems |
2 | ========================================== |
3 | |
4 | Werner Almesberger <werner@almesberger.net> |
5 | |
6 | This is a brief evaluation of the scripted 3D CAD systems OpenSCAD |
7 | and Cadmium, comparing the workflow, resource consumption, and the |
8 | quality of the results. |
9 | |
10 | |
11 | Introduction |
12 | ============ |
13 | |
14 | This file and the sources of the models can be found in |
15 | http://projects.qi-hardware.com/index.php/p/wernermisc/source/tree/master/cad/test1/ |
16 | |
17 | |
18 | Objectives |
19 | ---------- |
20 | |
21 | This test aims to determine the general suitability of currently |
22 | available Free scripted 3D CAD system for the construction of |
23 | real-life objects. |
24 | |
25 | Aspects considered were the ease or difficulty of model development, |
26 | the clarity of the modeling language, resource consumption during |
27 | rendering, and the quality of the resulting mesh. |
28 | |
29 | A second objective was to evaluate the suitability of CSG as the only |
30 | means for constructing models suitable for large-scale industrial |
31 | production. |
32 | |
33 | |
34 | Object description |
35 | ------------------ |
36 | |
37 | The object to model is a simple button/key cap shape. The shape |
38 | consists of a top part shaped as a 10 x 15 mm rectangle with rounded |
39 | corners and at height of 1.5 mm. The top part rests on a base that's |
40 | 0.5 mm thin and has a border of 1 mm on each side. |
41 | |
42 | The corners of the rectangle are rounded with a radius of 2 mm. All |
43 | other external edges are rounded (chamfered) with a radius of 0.2 mm. |
44 | The edge where top and base meet is filleted with a radius of 0.4 mm. |
45 | |
46 | Note that a real button would typically have an internal cavity, |
47 | possibly some depression or other structure on its top, and on the |
48 | bottom side a pusher in the middle and possibly other support |
49 | elements. |
50 | |
51 | Also, if the design was to be used for injection molding, sidewalls |
52 | would be slightly tilted. |
53 | |
54 | The rounding of the bottom plate is not strictly necessary and was |
55 | added for visual appearance. |
56 | |
57 | |
58 | Candidate 1: OpenSCAD |
59 | --------------------- |
60 | |
61 | OpenSCAD [1] uses its own language, somewhat similar to POV-Ray's, to |
62 | describe 3D objects. It has an IDE with a quick preview capability |
63 | using OpenCSG [2]. |
64 | |
65 | High-quality rendering, e.g., to STL, is done with CGAL [3] and can |
66 | also be run non-interactively. |
67 | |
68 | OpenSCAD and OpenCSG are licensed under the GNU GPL v2. Parts of CGAL |
69 | are licensed under the GNU LGPL v2.1 while others are licensed under |
70 | the incompatible QPL. See [4] for details. |
71 | |
72 | The version tested was the openscad 2011.06-1+lucid1 Ubuntu package. |
73 | |
74 | |
75 | OpenSCAD front-ends |
76 | ------------------- |
77 | |
78 | There also a number of Python-based scripted front-ends for OpenSCAD, |
79 | namely OpenSCADpy [5], PyOpenSCAD [6], and pySCAD [7]. |
80 | |
81 | Furthermore, there is Mecha [8, 9] for Haskell. |
82 | |
83 | Cadmium (see below) appears to be on par or better in terms of syntax |
84 | clarity and tidiness than the OpenSCAD Python bindings. Therefore, |
85 | only pure OpenSCAD was considered for this comparison. |
86 | |
87 | |
88 | Candidate 2: Cadmium |
89 | -------------------- |
90 | |
91 | Cadmium [10] is similar in concept to OpenSCAD, but uses Python |
92 | instead of a homegrown language. Open CASCADE [11] (via pythonOCC |
93 | [12]) provides the 3D operations here. |
94 | |
95 | The respective licenses are GNU AGPL v3 for Cadmium, GNU LGPL v3 for |
96 | pythonOCC, and a homegrown "LGPL-like" license [13] for Open CASCADE. |
97 | |
98 | The Cadmium version tested was Sun Jul 10 16:04:07 2011 +0530 commit |
99 | d4ff63b150ee060a8179a74e369b5df3d0a4a3fc, with pythonOCC 0.5. |
100 | |
101 | |
102 | Results and observations |
103 | ======================== |
104 | |
105 | Model development was efficient with both systems, with most of the |
106 | difficulties coming from the task of making the model, not from |
107 | inadequacies of the tools. |
108 | |
109 | Both systems also also produced correct-looking meshes. |
110 | |
111 | Notable differences exist in the time the rendering takes, where |
112 | rough previews with OpenSCAD are instantaneous and proper rendering |
113 | takes minutes, while Cadmium has no preview and the rendering takes |
114 | hours. |
115 | |
116 | On the other hand, some small anomalies could be found in the mesh |
117 | generated by OpenSCAD while the Cadmium's mesh looks perfect. |
118 | |
119 | |
120 | Model development |
121 | ----------------- |
122 | |
123 | Both systems offer the same basic CSG primitives and operations, |
124 | which made the model development per se straightforward and the |
125 | porting from one system to the other effortless. |
126 | |
127 | The very quick preview of OpenSCAD is immensely helpful during |
128 | development. The usefulness of the preview is diminished by |
129 | differences only being shown as unions of the solids involved, with |
130 | color indicating their role. It was thus often necessary to isolate |
131 | and simplify elements before the resulting shape could be guessed, or |
132 | to render with slower CGAL. |
133 | |
134 | Given the slow rendering process, debugging non-trivial designs with |
135 | Cadmium is currently quite time-consuming. |
136 | |
137 | Development of the basic model (without chamfers and fillets) was |
138 | first done with Cadmium. I then switched to OpenSCAD to develop the |
139 | more advanced features, and finally ported them back to the Cadmium |
140 | model. |
141 | |
142 | Designing the model elements for filleting and chamfering was |
143 | somewhat awkward with only CSG and - without understanding the |
144 | entire construction process - it may not be easy to see what the |
145 | resulting code does. |
146 | |
147 | |
148 | Modeling language |
149 | ----------------- |
150 | |
151 | The limited programming language of OpenSCAD proved to be more than |
152 | adequate for this simple design. To ease comparison and to reduce the |
153 | porting effort, the Cadmium model has the same code structure as the |
154 | OpenSCAD model. |
155 | |
156 | It should be noted that some redundancy could be avoided in Cadmium |
157 | if all the "rbox_*" functions were placed in a common class whose |
158 | objects could then remember the box's geometry for reuse with the |
159 | fillet and chamfer functions/methods. |
160 | |
161 | One nuisance with OpenSCAD is that mistyped variable names merely |
162 | generate a warning but let rendering proceed - often with confusing |
163 | results. |
164 | |
165 | One difficulty encountered when making the Cadmium model was that |
166 | there appears to be no null value for the "union" operation, which |
167 | means functions that generate all their objects in a loop have to |
168 | special-case the first element, making them look a bit awkward (e.g., |
169 | rbox_chamfer_top_corners). It should be easy to remedy this |
170 | shortcoming. |
171 | |
172 | The Python language also introduces complications to Cadmium that |
173 | OpenSCAD can avoid, such as the Python parser's limited ability to |
174 | detect continuation lines, requiring continuations to be marked with |
175 | a backslash, and the need to pay attention to the mixing of |
176 | floating-point and integer numbers when using divisions. |
177 | |
178 | Cadmium's ability to use short operators instead of blocks generally |
179 | yielded only marginally more compact code, since many operations |
180 | ended up being longer than one line anyway. In fact, the code |
181 | structure often looks a bit tidier in OpenSCAD. |
182 | |
183 | The placement of transformations before creation of the object in |
184 | OpenSCAD e.g., |
185 | translate(...) rotate(...) cylinder(...); |
186 | is slightly less intuitive than the reverse order Cadmium uses, e.g., |
187 | Cylinder(...).rotate(...).translate(...) |
188 | |
189 | Furthermore, if each step is placed on a separate line, Cadmium's |
190 | syntax puts the object in a more prominent position than the list of |
191 | translations. |
192 | |
193 | |
194 | Bugs |
195 | ---- |
196 | |
197 | OpenSCAD got stuck allocating excessive amounts of memory when trying |
198 | to preview with OpenCSG from the IDE. |
199 | |
200 | Cadmium fails at line 113 of button.py if the "noise" parameter |
201 | introduced to work around this bug is absent or set to zero. |
202 | |
203 | The mesh generated by Open SCAD appears to have some small anomalies, |
204 | see section "Resulting mesh". |
205 | |
206 | |
207 | Execution |
208 | --------- |
209 | |
210 | On a lightly loaded Intel Q6600, the "high quality" rendering time |
211 | was as follows: |
212 | |
213 | real user sys |
214 | OpenSCAD 1m25.491s 1m24.990s 0m00.410s |
215 | Cadmium 81m44.408s 81m41.110s 0m01.540s |
216 | |
217 | This is consistent with the time the rendering of earlier stages of |
218 | the design took: OpenSCAD with CGAL was always much faster than |
219 | Cadmium with Open CASCADE. |
220 | |
221 | I didn't attempt to systematically search for costly operations, but |
222 | observed that the crossed cubes/boxes forming the core of the rounded |
223 | box took considerably longer than a run with one of them removed. |
224 | |
225 | |
226 | Resulting mesh |
227 | -------------- |
228 | |
229 | The rendering results are available at |
230 | http://downloads.qi-hardware.com/people/werner/cad/test1/ |
231 | |
232 | The STL files are scad.stl.bz2 and cadmium.stl.bz2 for OpenSCAD and |
233 | Cadmium, respectively. scad.png and cadmium.png show screenshots of |
234 | the meshes rendered with MeshLab 1.2.2, with double side lighting and |
235 | "flat" rendering. |
236 | |
237 | The two meshes are of similar size, as reported by MeshLab: |
238 | |
239 | Vertices Faces |
240 | OpenSCAD 3351 7798 |
241 | Cadmium 3183 8362 |
242 | |
243 | Note that the OpenSCAD model uses a slightly larger number of circle |
244 | segments (explicitly set with $fn) than the Cadmium model (which just |
245 | uses whatever is the default behaviour). |
246 | |
247 | At earlier stages of the design, the Cadmium mesh was found to be |
248 | significantly larger then the OpenSCAD mesh. |
249 | |
250 | Both meshes look clean and at a first glance show now major |
251 | distortions (*). |
252 | |
253 | (*) Note that the model already takes care of avoiding situations |
254 | where the subtraction of volumes could leave behind solids with |
255 | the thickness of a rounding error. |
256 | |
257 | When viewed with MeshLab 1.2.2, with smooth rendering and |
258 | "Fancy Lighting", some faces appear to be inverted. These faces are |
259 | shown in red in |
260 | http://downloads.qi-hardware.com/people/werner/cad/test1/scad-reversed.png |
261 | |
262 | A peek at the inside of the OpenSCAD-generated mesh reveals internal |
263 | structures left over from the construction process, as shown on |
264 | http://downloads.qi-hardware.com/people/werner/cad/test1/scad-inside.png |
265 | |
266 | No anomalies could be found in the mesh generated by Cadmium. |
267 | |
268 | |
269 | Conclusion |
270 | ========== |
271 | |
272 | In the conclusions, I first consider the relative performance of the |
273 | two CAD system and then reflect on the whether the CSG-only workflow |
274 | as such proved to be satisfactory. |
275 | |
276 | |
277 | OpenSCAD vs. Cadmium |
278 | -------------------- |
279 | |
280 | Both systems succeeded in handling the task. OpenSCAD impressed with |
281 | fast response allowing highly interactive development, while Cadmium |
282 | --------------------------------------------------------------------- |
283 | soon gets very slow. It is not clear whether this slowness is a |
284 | general shortcoming of Cadmium or whether it is a consequence of poor |
285 | choices made when making the model. |
286 | |
287 | The mesh generated by OpenSCAD shows some anomalies, but it's not |
288 | clear whether they would affect further processing steps, e.g., |
289 | conversion to toolpaths. |
290 | |
291 | In terms of resource consumption and stability, even this relatively |
292 | simple model exhausted both systems, with OpenSCAD exhibiting |
293 | stability issues and Cadmium requiring excessive processing time. |
294 | |
295 | Both modeling languages can be used in very similar ways and were |
296 | pleasant to use. Python-based Cadmium may be more suitable for tasks |
297 | requiring structured building blocks. |
298 | |
299 | |
300 | The CSG-only workflow |
301 | --------------------- |
302 | |
303 | With both systems, translating the mental models of the various |
304 | components into correct instructions was difficult where more |
305 | abstract operations were involved, requiring some amount of trial and |
306 | error. |
307 | |
308 | Also, the resulting code does not easily reveal its purpose and |
309 | textual comments are an unsatisfactory means of illustrating |
310 | geometrical properties. (As an example, consider the above section |
311 | "Object description".) |
312 | |
313 | A workflow that includes distinct steps with a visual representation |
314 | of intermediate results, e.g., instead of CSG, using extrusion with |
315 | shapes and paths generated by some 2D CAD system, may be less |
316 | demanding. |
317 | |
318 | Also, while generating the basic shape was very easy, most of the |
319 | work went into the addition of fillets and chamfers. Neither of the |
320 | two systems provides operations to automate such tasks. |
321 | |
322 | |
323 | References |
324 | ========== |
325 | |
326 | [1] http://www.openscad.org/ |
327 | [2] http://www.opencsg.org/ |
328 | [3] http://www.cgal.org/ |
329 | [4] http://www.cgal.org/license.html |
330 | [5] https://github.com/hmeyer/openscadpy |
331 | [6] https://github.com/etjones/MCAD/tree/master/PyOpenScad |
332 | [7] https://github.com/kevinmehall/pyscad |
333 | [8] http://hackage.haskell.org/package/mecha/ |
334 | [9] https://github.com/tomahawkins/mecha/blob/master/Language/Mecha/Examples/CSG.hs |
335 | [10] http://jayesh3.github.com/cadmium/ |
336 | [11] http://www.opencascade.org/ |
337 | [12] http://www.pythonocc.org/ |
338 | [13] http://www.opencascade.org/getocc/license/ |
339 | |
340 | --------------------------------------------------------------------- |
341 |
Branches:
master