<div dir="ltr">Carsten said:<div><span style="font-size:12.8000001907349px">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.</span><br style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">... 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 :-)</span><span class="im" style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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 (<a href="http://object.name">object.name</a>), 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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">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.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 May 2015 at 12:58, Carsten Arnholm <span dir="ltr"><<a href="mailto:arnholm@arnholm.org" target="_blank">arnholm@arnholm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Marius!<span class=""><br>
<br>
On 2015-05-14 16:22, Marius Kintel wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OpenSCAD aim to directly describe a 3D design hierarchy, not merely<br>
execute code to spit out 3D objects.<br>
</blockquote>
<br></span>
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.<br>
<br>
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 :-)<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Using a faster and more powerful CAD kernel is indeed on the radar.<br>
</blockquote>
> Sadly, the world of Open Source CAD kernels is severely limited.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If we manage to get sufficient contributions or funding, working<br>
</blockquote>
> towards such a kernel would be doable. If you have any spare<br>
> time, this would be a good place to start:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms" target="_blank">https://github.com/openscad/openscad/wiki/Project%3A-Survey-of-CSG-algorithms</a><br>
<br>
..or if someone has the experience to do so: Evaluate OpenCascade as an<br>
option. Most people I’ve talked to who’ve ever used that has strongly<br>
recommended me never to touch it though. ..but FreeCAD somehow manages.<br>
</blockquote>
<br></span>
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 :<br>
<a href="http://dev.opencascade.org/doc/overview/html/occt_dev_guides__cdl.html" target="_blank">http://dev.opencascade.org/doc/overview/html/occt_dev_guides__cdl.html</a><br>
<br>
"Please note that CDL is considered as obsolete and is to be removed in one of future releases of OCCT."   :-)<br>
<br>
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 <a href="https://github.com/tpaviot/oce/" target="_blank">https://github.com/tpaviot/oce/</a><br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Carsten Arnholm</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org" target="_blank">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" target="_blank">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a><br>
<br>
</div></div></blockquote></div><br></div>