Just pushed up an update of the Open(Python)SCAD library I've been working on where I've enabled a first workable pass at previewing arbitrary G-code files. The update was necessary because my initial approach had the program unioning each object to the previous construction --- which obviously resulted in an ever-deeper nesting of CGAL union commands, necessitating a re-write which instead presents an essentially flat structure. However, processing a CGAL command can take a while, and seems to be memory intensive --- a file with 7,156 lines generated successfully, but that same file essentially doubled was crashing previous versions, while the most recent build has been stuck at "Rendering Polygon Mesh using CGAL..." for a very long while now. How complex/long a CGAL structure should OpenSCAD be able to manage with reasonable performance? William -- Sphinx of black quartz, judge my vow. https://designinto3d.com/

Issue with openSCAD geometry evaluator is that it builds hierarchy in memory as deep as the generated AST symbol tree. Of course that could be fixed, by hanging that to a non-hierarchical algorithm but that's probably a bigger task and not sure if the yield/effort ratio is a good one. Best solution for all *SCAD is not to build deep trees. PythonSCAD can do that with lists, OpenSCAD can just output the shapes plain() which is efficient too. On Mon, Jul 14, 2025 at 4:13 AM William F. Adams via Discuss < discuss@lists.openscad.org> wrote: > Just pushed up an update of the Open(Python)SCAD library I've been working > on where I've enabled a first workable pass at previewing arbitrary G-code > files. > > The update was necessary because my initial approach had the program > unioning each object to the previous construction --- which obviously > resulted in an ever-deeper nesting of CGAL union commands, necessitating a > re-write which instead presents an essentially flat structure. > > However, processing a CGAL command can take a while, and seems to be > memory intensive --- a file with 7,156 lines generated successfully, but > that same file essentially doubled was crashing previous versions, while > the most recent build has been stuck at "Rendering Polygon Mesh using > CGAL..." for a very long while now. > > How complex/long a CGAL structure should OpenSCAD be able to manage with > reasonable performance? > > William > > -- > Sphinx of black quartz, judge my vow. > https://designinto3d.com/ > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

Why not use Manifold instead of CGAL? On Mon, 14 Jul 2025 at 07:39, Guenther Sohler via Discuss < discuss@lists.openscad.org> wrote: > Issue with openSCAD geometry evaluator is that it builds hierarchy in > memory as deep as the generated AST > symbol tree. > Of course that could be fixed, by hanging that to a non-hierarchical > algorithm > but that's probably a bigger task and not sure if the yield/effort ratio > is a good one. > > Best solution for all *SCAD is not to build deep trees. PythonSCAD can do > that with lists, OpenSCAD can just output the shapes plain() which is > efficient too. > > > > On Mon, Jul 14, 2025 at 4:13 AM William F. Adams via Discuss < > discuss@lists.openscad.org> wrote: > >> Just pushed up an update of the Open(Python)SCAD library I've been >> working on where I've enabled a first workable pass at previewing arbitrary >> G-code files. >> >> The update was necessary because my initial approach had the program >> unioning each object to the previous construction --- which obviously >> resulted in an ever-deeper nesting of CGAL union commands, necessitating a >> re-write which instead presents an essentially flat structure. >> >> However, processing a CGAL command can take a while, and seems to be >> memory intensive --- a file with 7,156 lines generated successfully, but >> that same file essentially doubled was crashing previous versions, while >> the most recent build has been stuck at "Rendering Polygon Mesh using >> CGAL..." for a very long while now. >> >> How complex/long a CGAL structure should OpenSCAD be able to manage with >> reasonable performance? >> >> William >> >> -- >> Sphinx of black quartz, judge my vow. >> https://designinto3d.com/ >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

I wrote/asked: >> How complex/long a CGAL structure should OpenSCAD be able to manage with reasonable performance? On Monday, July 14, 2025 at 07:20:04 AM EDT, nop head via Discuss <discuss@lists.openscad.org> wrote: >Why not use Manifold instead of CGAL? That's a good question. As was pointed out on the OpenPythonSCAD Google Group, I meant "CSG", but I hadn't noticed that in various updates and switching versions, my having enabled Manifold was undone. Currently running: >Rendering Polygon Mesh using Manifold... on a shorter file (3,588 lines) and it finished with: >Parsing design (AST generation)... >Running Python 3.12.9 without venv. >Compiling design (CSG Tree generation)... >Rendering Polygon Mesh using Manifold... >Geometries in cache: 27396 >Geometry cache size in bytes: 934313952 >CGAL Polyhedrons in cache: 2 >CGAL cache size in bytes: 0 >Total rendering time: 0:04:11.220 >Top level object is a 3D object (manifold): >Status: NoError >Genus: 0 >Vertices: 12644 >Facets: 25284 >Measurements: >Surface: 203994.91 >Volume: 204742.03 >Rendering finished. generating a 99,995 line long CSG tree. Quitting and re-starting and switching back to CGAL the file ran for sufficiently a long time that I didn't bother to wait for it, so I suspect the change is very recent (maybe when I installed the new build and switched from openscad.ext to pythonscad.exe). Which still leaves the question --- is a greater than 100,000 line long CSG tree something which it is reasonable to expect that OpenPythonSCAD to handle? William