Marius makes a good point that "native" plugins (using a C/C++ API) would
fragment the community, as most authors would not have the resources to
produce mac, windows and linux versions of their plugins.

My personal preference is to extend the OpenSCAD language so that it is
expressive enough to program advanced geometric shapes and operations, like
the generalized non-affine transform discussed earlier.

I have a roadmap for this, and it does include a more powerful language for
writing user defined functions, and direct access to the mesh.

On 22 November 2015 at 12:17, Parkinbot rudolf@parkinbot.com wrote:

There is already direct access to the mesh with polyhedron. I.e. you
specify the mesh, not query it, as with everything in OpenSCAD. You use
maths to describe geometry, not the other way around.

Adding the ability to mix in other languages will be very fragmenting
because in order to use other people's code you will need to install and be
fluent in random computer languages. As it stands you only need to install
OpenSCAD and be fluent in that very simple language and maths to be able to
create any geometry.
On Nov 22, 2015 7:52 PM, "doug moen" doug@moens.org wrote:

Allowing mix-ins like that is indeed scary. My “plug-in” I was mostly thinking about ways of extending OpenSCAD by installing components exposing some API to the OpenSCAD language, keeping those two universes separated.

-Marius

On Sun, 22 Nov 2015 14:51:55 -0500
doug moen doug@moens.org wrote:

Blender exports a python API. It allows a very low level access to the
data structures and meshes but being python is portable if you are
sensible.

Python is obviously rather slower than C but given the costs in OpenSCAD
are all elsewhere it's hardly going to matter for performance.

At that point though there is also pyscad which does things the other way
up and which is probably the right approach as it doesn't break the
functional nature of OpenSCAD or the parallising opportunities.

Alan

doug.moen wrote

Can you elaborate on that?

kintel wrote

this would be more or less what I meant and already a large step towards
interop.

tp3 wrote

You name it.
I'm afraid that branching out own experimental versions of OpenSCAD just to
test a new feature, is a bit too involving - especially if there is a lack
of documentation. A plug-in interface is much more charming.

nophead wrote

If it was like this, I wouldn't discuss.

Rudolf

--
View this message in context: http://forum.openscad.org/feature-request-plug-ins-tp14663p14705.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

On 11/22/2015 11:04 PM, Parkinbot wrote:

Well, a plug-in documentation will also not write itself. And first
the plug-in API has to be designed and written too :-).

Hmm, still, maybe the "How to extend OpenSCAD" documentation could
use an external python call as example...

ciao,
Torsten.

"Python is obviously rather slower than C but given the costs in OpenSCAD
are all elsewhere it's hardly going to matter for performance."

Let's think about the performance issues more carefully.

Consider that, in the current architecture, this plugin API would need to
be invoked both during script evaluation, and also during CGAL rendering,
and I guess also preview. The generalized non-affine transformation
operator would have to be invoked during rendering, because only then is
the mesh available.

If we use Python, then we are invoking Python code in the middle of CGAL
rendering. We have to convert CGAL numeric objects (which are dynamically
allocated rational numbers) into Python numeric objects, run the plugin
code, then convert the Python numbers back into CGAL numbers. This isn't
cheap, as I suspect that operations on CGAL numbers are the bulk of the
cost of rendering.

We haven't implemented any of our ideas yet for speeding up rendering by
using multiple cores, or by using the GPU, although that has been discussed
a lot. If part of the rendering code is written in Python, this becomes
much more difficult.

On 22 November 2015 at 16:19, Alan Cox alan@lxorguk.ukuu.org.uk wrote:

At Parkinbot's request, here are some thoughts about the road ahead for
OpenSCAD:

1. Make the core language more expressive and powerful. My current
   proposal for this is OpenSCAD2 https://github.com/doug-moen/openscad2.
2. Make rendering much faster, so that it is as fast as preview. There
   are lots of things we can do, for example:
   • Replace CGAL with a faster and more memory efficient geometry
     engine that uses 64 bit floating point numbers, instead of
     variable-length
     rationals.
   • Exploit multi-core parallelism.
   • Exploit the FPU, eg by using OpenCL or the new Vulkan API.
3. Make the graphics primitives more powerful, by permitting the mesh to
   be queried. Script evaluation and rendering are now interleaved. Trygon's
   transform() operator can now be written in OpenSCAD.
4. At this point, the performance choke points have changed, and we are
   now motivated to speed up the core language. A good approach is to use LLVM
   as our back end, which lets us compile OpenSCAD into optimized machine
   code. If Vulkan is now available on all platforms, then we can also use
   LLVM to generate optimized GPU code.

I think that OpenSCAD can be evolved into a much more powerful language for
3D solid modelling, without ruining the characteristics that our users find
valuable, such as simple, declarative semantics and convenient syntax.
OpenSCAD can be extended to become a better "plugin" language for writing
advanced solid modelling libraries than Python or some other general
purpose language.

In the long run, there are clear advantages to having a single language
that supports both simple and advanced solid modelling. You don't need to
jump the chasm from OpenSCAD to Python to start using more advanced
techniques in your models.

On 22 November 2015 at 17:04, Parkinbot rudolf@parkinbot.com wrote:

Now go measure how much of the CPU wall clock time is spent in the depths
of intersections unions and friends.

If you implement a complex operator in python it'll suck yes. Ditto with
Blender btw. But if you need a fundmanetal mathematical operation the
chances are it should be in the core anyway.

The Blender examples are interesting in that to put it bluntly Blender
shows it works for real world problems.

And if you want OpenSCAD to every run at useful speed for larger objects
you'll have to either remove CGAL or replace the numbers implementation
you select with a fixed point integer one which also fixes that.

Yes, but not half as difficult as debugging crashes caused by scribbles
from non parallel safe C++ code. The number of people who can write good
parallel C++ code is rather smaller than you'd want, not helped by the
fact that computer science as often taught if anything damages rather
than enhances those skills.

Alan