[OpenSCAD] eval( ) ???

G. Wade Johnson gwadej at anomaly.org
Sat May 16 13:33:01 EDT 2015


Is there a {beta,alpha,prototype} version of OpenSCAD2 somewhere for
people to play with? Is there a spec to read?

I, for one, would like to see anything you are willing to share on this.

G. Wade

On Sat, 16 May 2015 12:44:38 -0400
doug moen <doug at moens.org> wrote:

> Carsten said:
> Personally, I use modules in OpenSCAD extensively, but I would be even
> happier with a class concept with both member functions and data
> members. A 3d hierarchy can be expressed also that way.
> ... Perhaps one could keep the OpenSCAD language limited and use it
> as an intermediate representation generated by the kind of object
> oriented language I am dreaming of :-)
> 
> The OpenSCAD2 design that I am working on will have a very simple
> object model. Consider a typical OpenSCAD script: it has some named
> numeric parameters at the top, then some function and module
> definitions, then some top level geometry statements that render the
> model based on the parameters. So that's an object. An object is a
> set of top level definitions (name/value pairs), plus a list of
> values (which are normally geometric shapes). OpenSCAD2 has a syntax
> for referencing an external library file as an object, and a syntax
> for object literals (just an OpenSCAD script, surrounded by braces).
> Given an object, you can reference its named components using dot
> notation (object.name), or you can reference the object in a
> geometric context (as an argument to a geometric transformation, or
> at the top level of a script), in which case the object behaves like
> its geometry.
> 
> There are a few more details, but that's the basic idea. Note that
> this is much simpler than object oriented programming. There are no
> mutable objects, no classes or user defined types, no support for
> encapsulation or data abstraction. But, as I mentioned, objects do
> have "member functions and data members", so it may go part way
> towards satisfying Carsten's requirements. Objects will also satisfy
> Runsun's requirement for associative arrays. I also think that
> constructing a 3D model as a tree of objects will give us a better
> (more declarative) way to support bill-of-materials.
> 
> We want to preserve the simple and declarative nature of OpenSCAD. I
> believe that this very simple object model will address some of the
> main pain points in doing geometric modelling with OpenSCAD, without
> turning it into a complex OOP language.
> 
> On 14 May 2015 at 12:58, Carsten Arnholm <arnholm at arnholm.org> wrote:
> 
> > Hi Marius!
> >
> > On 2015-05-14 16:22, Marius Kintel wrote:
> >
> >> OpenSCAD aim to directly describe a 3D design hierarchy, not merely
> >> execute code to spit out 3D objects.
> >>
> >
> > I do understand, and any language chosen would obviously have to
> > support the design hierarchy. As far as I can tell, many languages
> > should be able to do it. Personally, I use modules in OpenSCAD
> > extensively, but I would be even happier with a class concept with
> > both member functions and data members. A 3d hierarchy can be
> > expressed also that way.
> >
> > Anyway, this was just my thoughts. OpenSCAD has made decisions long
> > ago, which I respect. Perhaps one could keep the OpenSCAD language
> > limited and use it as an intermediate representation generated by
> > the kind of object oriented language I am dreaming of :-)
> >
> >  Using a faster and more powerful CAD kernel is indeed on the radar.
> >>
> > > Sadly, the world of Open Source CAD kernels is severely limited.
> >
> >> If we manage to get sufficient contributions or funding, working
> >>
> > > towards such a kernel would be doable. If you have any spare
> > > time, this would be a good place to start:
> >
> >>
> >> https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms
> >>
> >> ..or if someone has the experience to do so: Evaluate OpenCascade
> >> as an option. Most people I’ve talked to who’ve ever used that has
> >> strongly recommended me never to touch it though. ..but FreeCAD
> >> somehow manages.
> >>
> >
> > The funny thing is, I evaluated CAS.CADE (as it was known at the
> > time) in about 1994-1995 for the work previously mentioned. It was
> > marketed by Matra Datavision in France and I even went to see them
> > a couple of times. They had what we thought was a curious idea of
> > their own home-grown language (CDL) encapsulating the C++ kernel.
> > Nowadays it looks like some finally agree with our thoughts at the
> > time :
> > http://dev.opencascade.org/doc/overview/html/occt_dev_guides__cdl.html
> >
> > "Please note that CDL is considered as obsolete and is to be
> > removed in one of future releases of OCCT."   :-)
> >
> > CAS.CADE was closed source and extremely expensive back then, but
> > we still struggled very hard to make use of it. The end result for
> > us was that it was dropped and replaced it with ACIS. Only a few
> > years ago, I discovered CAS.CADE had become quasi open source as
> > OpenCascade (OCCT). I also found there is now something called OCE
> > - Open CASCADE Community Edition https://github.com/tpaviot/oce/
> > I had the idea of trying OCE, but frankly not enough incentive and
> > power to do it, and my work is different now. OCE may probably be
> > something to be considered for OpenSCAD CAD kernel, I suspect
> > OpenCascade has come a long way since I saw it.
> >
> > Sidenote: One thing that has struck me is that the compilation in
> > OpenSCAD is quite fast, but the rendering (F6) is extremely slow. I
> > was wondering if the generation of triangles for STL really needs
> > the graphical rendering to be completed first? If not, one could
> > imagine a function to export the compiled model to STL and use an
> > external viewer to speed things up when iterating on a complex
> > design that takes forever to render.
> >
> > Carsten Arnholm
> >
> >
> >
> >
> > _______________________________________________
> > OpenSCAD mailing list
> > Discuss at lists.openscad.org
> > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> >
> >


-- 
Controlling complexity is the essence of computer programming
                                                  -- Brian Kernighan




More information about the Discuss mailing list