Re: Pointers on writing an OpenSCAD extension

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

Bryan Bishop
On Wed, Feb 10, 2010 at 7:03 PM, Vitaly Mankevich <[hidden email]> wrote:
> I've downloaded and played with OpenSCAD examples and I liked the
> simplicity and elegance of coding in geometry. I haven't seen the
> source so I don't know where to look for integrating this with
> pythonOCC.

Okay, thanks. I'll dig around a little bit, ask around.

- Bryan
http://heybryan.org/
1 512 203 0507

Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

kintel
Administrator
On Feb 11, 2010, at 02:06 , Bryan Bishop wrote:

> On Wed, Feb 10, 2010 at 7:03 PM, Vitaly Mankevich <[hidden email]
> > wrote:
>> I've downloaded and played with OpenSCAD examples and I liked the
>> simplicity and elegance of coding in geometry. I haven't seen the
>> source so I don't know where to look for integrating this with
>> pythonOCC.
>
> Okay, thanks. I'll dig around a little bit, ask around.
>

 From earlier mailing list discussions, I get the impression that  
pythonOCC is a superset of OpenSCAD, where OpenSCAD is lighter on the  
programming skills than pythonOCC.
If this is not the case, I'd be very interested in an evaluation of  
what the differences between OpenSCAD and pythonOCC really are. Since  
OCC is a full-fledged CAD kernel, I guess that boils down to an  
evaluation of where using OpenSCAD could be an advantage.

~/= Marius

--
We are Elektropeople for a better living.





Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

Bryan Bishop
On Wed, Feb 10, 2010 at 7:48 PM, Marius Kintel wrote:

> On Feb 11, 2010, at 02:06 , Bryan Bishop wrote:
>> On Wed, Feb 10, 2010 at 7:03 PM, Vitaly Mankevich wrote:
>>> I've downloaded and played with OpenSCAD examples and I liked the
>>> simplicity and elegance of coding in geometry. I haven't seen the
>>> source so I don't know where to look for integrating this with
>>> pythonOCC.
>>
>> Okay, thanks. I'll dig around a little bit, ask around.
>
> From earlier mailing list discussions, I get the impression that pythonOCC
> is a superset of OpenSCAD, where OpenSCAD is lighter on the programming
> skills than pythonOCC.
> If this is not the case, I'd be very interested in an evaluation of what the
> differences between OpenSCAD and pythonOCC really are. Since OCC is a
> full-fledged CAD kernel, I guess that boils down to an evaluation of where
> using OpenSCAD could be an advantage.

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.

- Bryan
http://heybryan.org/
1 512 203 0507

Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

kintel
Administrator
On Feb 11, 2010, at 02:50 , Bryan Bishop wrote:

> 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.
>

I see. In that case, and since OpenCascade is a C++ library, I would  
guess it's easier to hook up an OpenCascade exporter into OpenSCAD  
using the normal C++ API.
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 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.

~/= Marius

--
We are Elektropeople for a better living.





Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

Bryan Bishop
On Wed, Feb 10, 2010 at 8:09 PM, Marius Kintel wrote:

> On Feb 11, 2010, at 02:50 , Bryan Bishop wrote:
>> 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.
>>
>
> I see. In that case, and since OpenCascade is a C++ library, I would guess
> it's easier to hook up an OpenCascade exporter into OpenSCAD using the
> normal C++ API.

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.

- Bryan
http://heybryan.org/
1 512 203 0507

Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

kintel
Administrator
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.





Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

Leo Dearden


On 11 February 2010 12:04, Marius Kintel <[hidden email]> wrote:
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).

Whichever level you work at, doing this with FreeCAD instead of OpenCASCADE is probably a good idea. FreeCAD is built on OpenCASCADE and it provides a much more complete design environment. You could interface at the C++ level, but the original suggestions of Python might be better. There is already a clean pythonOCC based interface for building geometry, and using it would make OpenSCAD plug in as another workbench, in parallel with conventional part design, or 2D drafting, or whatever. This would open up workflows that use geometry code for some parts of the the design and conventional CAD for others. 

I'm going to do some work on FreeCAD over the next couple of months and I'd be happy to share what I learn if you're interested.

Cheers,

Leo
Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

kintel
Administrator
On Feb 11, 2010, at 19:52 , Leo Dearden wrote:
>
> I'm going to do some work on FreeCAD over the next couple of months  
> and I'd be happy to share what I learn if you're interested.
>
Definitely!
FreeCAD, just looking at the underlying libraries, looks like a winner.
Developing extensive GUI's cross-platform is a major task though, so I  
don't expect to see a stable FreeCAD for anything except Windows  
anytime soon.

~/= Marius

--
We are Elektropeople for a better living.





Reply | Threaded
Open this post in threaded view
|

Re: Pointers on writing an OpenSCAD extension

Leo Dearden
On 11 February 2010 21:16, Marius Kintel <[hidden email]> wrote:
On Feb 11, 2010, at 19:52 , Leo Dearden wrote:
>
> I'm going to do some work on FreeCAD over the next couple of months
> and I'd be happy to share what I learn if you're interested.
>
Definitely!

Cool. I'll post on the OM and OSCAD lists when I have something worth sharing.

FreeCAD, just looking at the underlying libraries, looks like a winner.
Developing extensive GUI's cross-platform is a major task though...

For sure!
 
...so I
don't expect to see a stable FreeCAD for anything except Windows
anytime soon.

It builds and seems to run fine on Ubuntu 9.10. It passes the self test suite and I made and rotated a cylinder. Admittedly this isn't a deep test :-), but it's promising. I think a lot of the hard portability work has been done by the QT and Python developers.

Cheers,

Leo