[OpenSCAD] Specification of CSG file format?
arnholm at arnholm.org
arnholm at arnholm.org
Mon May 18 05:04:34 EDT 2015
On 2015-05-18 09:56, Marius Kintel wrote:
> On May 17, 2015, at 18:11 PM, Carsten Arnholm <arnholm at arnholm.org>
>> I know other programs have made import filters for such files, but
>> then the only "contract" is OpenSCAD documentation, right?
> .csg export was added specifically to support some research being done
> in the RepRap project on inlining CSG operation with slicing for 3D
> Since then, people have started to use it as some sort of
> interoperability format (e.g. FreeCAD has a .csg parser for importing
> static OpenSCAD content).
> There has been discussions on changing some aspects of .csg output;
> replacing multmatrix with logical transformations, replacing import()
> with polygon()/polyhedron(), or even replacing more advanced built-in
> modules like hull() and minkowski() with their results, making it
> easier to read or import such files.
Thanks for the input!
It matches more or less what I thought. My personal recommendation would
be to keep multmatrix as is, this is by far the most general way of
handling transformations on this level. Similarly, I think it would
definitely make sense to optionally do
- expand import() with polygon()/polyhedron()
- expand hull() and minkowski() to basic primitives
- expand text() to basic 3d primitives
In summary, it would be very useful to optionally expand all high level
objects to their basic primitives when exporting to .csg. For
transformations, the basic primitive is the 4x4 matrix already
implemented as multmatrix, so I would keep that.
With such options, OpenSCAD models could be more easily exchanged with
e.g. FreeCAD. I tested FreeCAD .csg import yesterday and it failed on a
very simple model because I had used hull() in OpenSCAD.
The way I look at this is that OpenSCAD provides a "user interface"
language with some primitives (cube,cylinder etc.) and some high level
features (hull() and minkowski() are 2 examples). The high level
features are very useful "user interface" idioms, but not suitable for
reliable interoperability of model data between applications. To make
interoperability more reliable, it would make sense to (optionally!)
store *only basic model primitives* on the .csg file together with only
basic transformation primitives (i.e. multimatrix).
You could then change the language in any way you like, plus add more
primitives without compromising data exchange with other applications.
The contract would be the set of primitives only.
More information about the Discuss