I wrote

Not seeing an appreciable difference between the basic cube and the hulled version, even after adding that command.
Doesn't seem to make a difference:
Original hulled version:
Rendering Polygon Mesh using CGAL...Geometries in cache: 11Geometry cache size in bytes: 13048CGAL Polyhedrons in cache: 3CGAL cache size in bytes: 77296Total rendering time: 0:00:00.618 Top level object is a 3D object: Simple: yes Vertices: 8 Halfedges: 24 Edges: 12 Halffacets: 12 Facets: 6 Volumes: 2Rendering finished.
After adding the render() command:
Parsing design (AST generation)...Saved backup file: C:/Users/willa/OneDrive/Documents/OpenSCAD/backups/cube test -backup-HEciKFYI.scadCompiling design (CSG Tree generation)...Rendering Polygon Mesh using CGAL...Geometries in cache: 11Geometry cache size in bytes: 13048CGAL Polyhedrons in cache: 4CGAL cache size in bytes: 88640Total rendering time: 0:00:00.034 Top level object is a 3D object: Simple: yes Vertices: 8 Halfedges: 24 Edges: 12 Halffacets: 12 Facets: 6 Volumes: 2Rendering finished.
William

MichaelAtOz wrote:

I'm not disputing this is a complex way to make things and results in a complex representation internally --- it's just that that internal representation is not optimal --- wouldn't having a way (or integrating a mechanism) to optimize the internal representation be a good idea? --- if every time an object is carved into it gets more complex doesn't that limit the ultimate possible complexity?
If there could be an optimization/simplification of the geometric representation, then the program could run faster, right?
William

Well, the problem is OpenSCAD uses two libraries.

OpenCSG for preview, which for want of a complex description, 'simulates' geometry without actually
calculating real 3D objects.

CGAL, which actually calculates real CSG points, and is complex and slow.

That is the OpenSCAD model, quick preview, then slow real geometry rendering.

Both are maintained by other, non-OpenSCAD, agencies.

So OpenSCAD developers cannot do what you want.

OpenSCAD is what it is. If it doesn't support your method of use, there is little that can be done.

From: Discuss [mailto:discuss-bounces@lists.openscad.org] On Behalf Of William F. Adams via Discuss
Sent: Mon, 7 Sep 2020 22:38
To: discuss@lists.openscad.org
Cc: William F. Adams
Subject: Re: [OpenSCAD] Efficiencies and difficulties of creating files

MichaelAtOz wrote:

I'm not disputing this is a complex way to make things and results in a complex representation
internally --- it's just that that internal representation is not optimal --- wouldn't having a way
(or integrating a mechanism) to optimize the internal representation be a good idea? --- if every
time an object is carved into it gets more complex doesn't that limit the ultimate possible
complexity?

If there could be an optimization/simplification of the geometric representation, then the program
could run faster, right?

William

--
This email has been checked for viruses by AVG.
https://www.avg.com

On 07.09.20 15:02, MichaelAtOz wrote:

I would not call it impossible, it might be an interesting
challenge as it could be beneficial to make it a pass through
operation for preview.
Remeshing in general (and both directions, simplify and
subdivide) should be doable. CGAL even supports (according to
the documentation) mesh processing for fixing geometry, so
that would fall into the same category of operations.

ciao,
Torsten.

OK, well, perhaps, I could suggest, without criticism, given other activity, it would not be
something that one could expect to happen, in the near future.

--
This email has been checked for viruses by AVG.
https://www.avg.com

On 07.09.20 16:08, MichaelAtOz wrote:

That's certainly true. But there's always a chance someone
coming along taking on that specific challenge. It does
actually happen, like with the very nice Jump-to-Source
feature which was implemented by someone who contributed
that as first OpenSCAD change.

ciao,
Torsten.

On Mon, Sep 7, 2020, at 8:37 AM, William F. Adams via Discuss wrote:

Yes, an optimization pass could speed things up, at least for some special cases. There already is some limited optimization: a stack of affine transformations is converted to a single transformation matrix. This alone won't make OpenSCAD fast.

The main reason that OpenSCAD is slow is that it converts each geometric primitive to a triangle mesh as early as possible, then it performs CSG operations (like union, intersection, difference) directly on these triangle meshes. This is extremely expensive, especially if you are representing curved surfaces that require a large number of triangles for a smooth approximation. The slowness is caused by the large number of triangles that must be processed by the CSG operations.

The way to render these models quickly is to defer mesh generation as long as possible. Ideally, you would build the CSG tree, optimize it, then directly convert the CSG tree to a triangle mesh. The trick is to convert the CSG tree to an intermediate representation from which you can quickly generate triangles.

A number of people have built OpenSCAD-like systems that use signed distance fields in the intermediate representation of the CSG tree (although there is a lot of variation in these intermediate representations, and it's an active area of research). It's not hard to build a system that renders at a million triangles per second (using an algorithm that runs on the CPU). My system, Curv, is about this fast. If you could run your rendering algorithm on the GPU, then mesh generation would be a 100 times faster.

One major barrier to changing OpenSCAD to use this kind of fast rendering technology is backward compatibility. OpenSCAD programs are tightly coupled to the current rendering algorithm. The idiomatic way to make a regular polygon or prism is circle and cylinder, because everybody knows that circles and cylinders are converted to polygons and prisms as early as possible.

On 07.09.20 16:28, Doug Moen wrote:

I totally disagree with that. The only barrier I see is that
there's not enough people working on it.

There's not much limitation in the language that would
prevent doing SDF rendering. It's possible to convert code
without hull/minkowski to a GPU shader. There's even existing
code doing that based on the implicitcad implementation.

The core structure of OpenSCAD to generate an object tree
first and do the mesh rendering in the second step does
work for using different rendering processes (as proven
by the preview / render separation).

Sure there's likely some devil in the details, but if people
would work together on solving the problems, I believe it's
totally doable. If we don't manage to spark the interest of
more developers, it might not happen ever.

Yes, it makes some things more complicated when working in
a team on some existing project, but it also has a number
of huge benefits in the long term. Like we will hopefully
have a 3 month project working on documentation again. This
time with focus on free and open education/course material.

ciao,
Torsten.

There's no way to create an SDF renderer that is a plug in replacement for the existing CGAL renderer.

• There aren't SDF implementations of hull and minkowski, as you mention.
• The meshes that are generated would be completely different. The unit tests would break, and projects that rely on precise control over the triangles that are generated to STL would likely break.

So this would have to be an optional 3rd rendering path that doesn't support the entire OpenSCAD language.

One of the attractive features of SDF modelling is the availability of additional CSG operators like blending and replication, and non-affine transformations like bend and twist. If these were made available in OpenSCAD, they wouldn't work in the OpenCSG previewer or the CGAL renderer. So this is one thing that would lead to OpenSCAD being split into two incompatible dialects, depending on which renderer you are using. Another thing is that when you optimize your code to speed up rendering, you use different tricks depending on which renderer you are using.

Curv and Libfive allow you to define new shape primitives by directly defining signed distance functions. It's the analog of extending OpenSCAD to support splines and sweeps using polyhedron. It's a feature I can't live without; I use it in about half my projects. In Curv and Libfive at least, this feature depends on the treatment of functions and shapes as first class values. An SDF shape operator is a function that takes shapes and other arguments and returns a structure containing a function that maps a point onto a distance, and the OpenSCAD language won't let you do this. If this capability were added to OpenSCAD, it would only work in the SDF dialect of OpenSCAD, because SDFs can't be rendered by OpenCSG or CGAL.

You mention the possibility of previewing a model by converting it to a GPU fragment shader (an approach that works in OpenGL 2). I've implemented this in Curv, but it has performance cliffs when you try to union together a large number of objects.. Limitations of this approach are also why I don't have the text and polyhedron primitives. As a result, you can't just transliterate an arbitrary OpenSCAD program into Curv and expect the previewer to work. You often have to write the code differently. To eliminate these performance cliffs, I am researching alternative previewing technologies based on how high performance 3D rendering engines work in video games, and I hope to use these in the successor to Curv. But these techniques require compute shaders (OpenGL 4.3 or later, a version of OpenGL that isn't supported by MacOS) and other modern APIs. So the successor to Curv will use Vulkan, Metal, DX12, not OpenGL. By contrast, OpenSCAD currently runs on any Windows, MacOS or Linux system with a GPU, since it only requires OpenGL 2.

On Mon, Sep 7, 2020, at 10:54 AM, Torsten Paul wrote:

I see more barriers than this. I'm surprised you think this is a viable approach for OpenSCAD, given what I think the challenges are.