Fast booleans are not a trivial problem, regardless of what shape
representation you use.

Also, keep in mind that any data structure or algorithm you code in
OpenSCAD can be reproduced in C++ where it will run a thousand times
faster, and you can get even higher performance by rendering on the GPU
instead of on the CPU.

On 7 February 2018 at 21:33, NateTG nate-openscadforum@pedantic.org wrote:

A thousand times faster? I don't understand that. Given that OpenSCAD is
written in C++, it seems to me that it will take only a little more time --
the time to read the OpenSCAD source code and to parse them. The time to do
the actual operation will be exactly the same.

Frank

On Fri, Feb 9, 2018 at 2:27 AM, doug moen doug@moens.org wrote:

OpenSCAD is an interpreted language, and the interpreter is not very fast.
If OpenSCAD programs were compiled into machine code using the back end of
a C++ compiler, then run times would be similar to C++, but they are not.
The factor of 1000x is based on some informal benchmarks that I have run
comparing speed of the two languages. Javascript interpreters are much
faster: they typically use JIT compilers that compile some parts of the
program into machine code. This is why you can't expect to match the
performance of openjscad (or C++ mesh libraries) by implementing mesh
primitives in openscad.

On 8 February 2018 at 12:30, Frank van der Hulst drifter.frank@gmail.com
wrote:

Where is library subdivision.scad found?

2018-02-08 0:33 GMT-02:00 NateTG nate-openscadforum@pedantic.org:

Ok, I have found it but the function triangulate_poly3d() called by
octree.scad is missing.

2018-02-08 18:04 GMT-02:00 Ronaldo Persiano rcmpersiano@gmail.com:

On Thu, 8 Feb 2018 13:08:26 -0500
doug moen doug@moens.org wrote:

Try profiling it and you'll see the interpreter isn't a problem.

They would but that would be almost the same speed as it is now.

You really need to spend some time actually profiling it. The interpreter
speed is basically irrelevant for OpenSCAD because each operation is
dominated by the 3D model manipulation time which is all in C++ already.
If it takes 0.1 milliseconds longer to interpret than be compiled when
executing an operation that takes CGAL's C++ code 15 seconds it's kind of
irrelevant whether you interpret it or not.

It spends all its time doing CGAL stuff in highly inefficient number
representations and quite possibly also wrong algorithms for the task.
Add to the fact it doesn't multi-thread properly and yeah - it's slow.

For many things ImplicitCad is much faster, but not always and it can
do things well that OpenSCAD can't but also lacks things OpenSCAD has.

If CGAL could be rebuilt into 64bit fixed point, made multiprocessor
aware, and some of the interesting problems around the significance of
mathematical errors at joins dealth with then it probably could be 1000
times faster - but it's got zero to do with the interpreter.

Alan

Right. But when I do a difference of two complex meshes, something less
than a millisecond will be spent on interpreting the code, and 10 minutes
on doing the operation. If I could compile OpenScad code (perhaps via C++)
or wrote an entire C++ program to do that operation,  it would still take
10 minutes to execute. Unless there is some faster difference() function
available. In which case we should link that faster library into OpenScad.

On Friday, February 9, 2018, doug moen doug@moens.org wrote:

frankv wrote

Here's a github issue from 2014 where people are taking about that.

https://github.com/openscad/openscad/issues/630

--
Sent from: http://forum.openscad.org/

Alan Cox wrote

That's not always the case.  My (admittedly somewhat demented) userland
voxel geometry stuff spends almost all of its time in the interpreter.  If
the interpreter were more computationally capable, it would be a much more
interesting thing in terms of applications.

--
Sent from: http://forum.openscad.org/