Okay, thanks. I'll dig around a little bit, ask around.
Not quite what's going on here. Think of it more as pythonOCC as
bindings for python to OpenCASCADE (the kernel). Then, I'm considering
integrating OpenSCAD with pythonOCC so that it can spit out
information from the SCAD format to the internal OCC format so that it
can eventually be exported to STEP, IGES, brep, etc.
The documentation is absolutely terrible, that's why I was figuring a
prototype in python would be easier. But either way.
> As long as OpenCascade allows for building CSG trees out of polygonal
> manifold meshes, the worst case would be hooking up to the mesh class
> (PolySet) in OpenSCAD and use these as leaf nodes in the CSG tree. It's
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).
> always possible to dig deeper and get access to true primitives, given that
> operations like extrusions are allowed on such (2D) primitives in
> OpenCascade.
>
> Until the inner workings of OpenSCAD is a bit cleaner, this would involve
> some hacking, but I'd be happy to support such an endaevor at the OpenSCAD
> end of things.
>
> As I mentioned earlier, I don't know anything about OpenCascade, so I would
> be more comfortable about this if someone did a proof-of-concept by
> remodeling some representative OpenSCAD examples using OpenCascade data
> structures.
Just point me where in the SCAD source code.
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 is the
evaluated node tree, meaning that all variables and control constructs
are already resolved, while the primitives are not converted to
meshes...
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).