[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> 
> wrote:
> 
>> 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
> printing.
> 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.

Carsten Arnholm






More information about the Discuss mailing list