[OpenSCAD] Pointers on writing an OpenSCAD extension

[Marius Kintel]

On Feb 11, 2010, at 03:15 , Bryan Bishop wrote:

> I don't think we should use the meshes. Let's instead just look at the
> actual objects (circles, spheres, etc.) and conver those to the same
> objects used in OCC (i.e.,
> OCC.BRepBuilderAPI.BRepBuilderAPI_MakeSphere).
>
I agree - I just don't know the capabilities of OpenCascade in this  
respect.

> Just point me where in the SCAD source code.
>

What I would look at first is to write code for converting from  
OpenSCAD Node tree to the equivalent/mappable concept in OpenCascade.  
This means writing something which sits next to F5 (Compile), which  
creates a CSG tree for OpenCSG rendering, and F6 (Compile and Render  
(CGAL)), which renders to a concrete CGAL polyhedron. These tasks are  
performed by MainWindow::actionCompile() and  
MainWindow::actionRenderCGAL() respectively.

The method MainWindow::compile() will result in MainWindow:root_node  
to be set to the model root after evaluation. Note that this is the  
evaluated node tree, meaning that all variables and control constructs  
are already resolved, while the primitives are not converted to  
meshes. I would recommend going here first and when we can represent  
an unparametrized tree in OpenCascade, move on to parametrized trees  
as mentioned below.

Alternatively, you could dig one step deeper and hook up to after the  
parser (parse() global function). This will set  
MainWindow::root_module, which is the root node of the (unevaluated)  
module tree (includes module definitions and module instantiations).  
This is more work as you need to rewrite the resolving logic (look at  
the context handling).

Some tips:
o This code needs refactoring so it might be a little confusing to read
o Look at the PDF's in the doc/ directory. I drew those diagrams when  
reading through the code the first time around to help getting the  
overview


~/= Marius

--
We are Elektropeople for a better living.