gilboonet wrote

So the subject question is now resolved.

OpenSCAD Admin - email* me if you need anything,  or if I've done something stupid...

• on the Forum, click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

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

On Thu, Mar 25, 2021, at 8:46 PM, Jordan Brown wrote:

Many of the OpenSCAD-like programs are capable of doing this. The primary requirement is that you treat shapes as values, and that you provide programmatic access to the representation of shape values. There are two reasons OpenSCAD can't do this. One is purely about syntax: the language is designed so that it is impossible to reference a shape as a value. The other reason is cultural: the feature has been left out of the language due to concerns about performance. Although, note, the operation to get a triangle mesh out of a shape would be no slower than render().

The render() module already exists: it renders the shape into a triangle mesh before the preview runs. So that's not the problem. The "major overhaul" is to the syntax, because it is currently impossible to write a function that takes a shape as an argument and returns a value.

Given that many or most modelling languages let you query geometry, I think the remaining question is whether you can implement this kind of algorithm efficiently in the modelling language. If you are doing this in the domain of triangle meshes, then some models have hundreds of thousands, or millions, of triangles. If you are doing this in Curv, then you are doing it over a voxel grid, and there can likewise be a huge number of voxels. If the performance is superlinear in the number of triangles/voxels, then the wait time could be substantial for complex models.

It's theoretically possible to implement this feature in the Curv language, but the performance would be terrible, because Curv is an interpreted language.

Ideally, you would want to perform this operation in about 50 milliseconds. That would be fast enough to support animation in the customizer, if you are dragging a slider around and watching the shape change in a preview window. I think the best way to get this kind of performance is to design a shape splitting algorithm that can be implemented on the GPU using massive parallelism. Curv programs can be compiled into GPU code, but only for the purpose of rendering, not for doing compute, which is what's needed here. The next major version of Curv will also support GPU compute, because in my opinion that's the missing feature in general purpose high performance 3D modelling languages.

On 3/27/2021 9:40 AM, Doug Moen wrote:

No, or not exactly.  You have to actually do the various transforms
and operations while the program is running.

I wrote a cheesy little Python-based environment, that processes a
Python API that looks sort of like OpenSCAD.  It doesn't happen to offer
access to the "insides" of objects, but it could.  But that access won't
help here, because the "insides" are just the CSG tree.  The "insides"
of a cylinder are two radii and a height - not a triangle mesh.  Just as
in OpenSCAD, the "output" of the program is a CSG tree, that is then
processed by another program to produce previews and STL.

Yes, it's before the preview.

No, it's not before the program proper finishes executing.  render() is
just a node in the CSG tree.  It doesn't do anything until you start
processing the tree, which is after the program finishes.

Try this program:

n = 3;
m = 6;
for (i=[1:n]) {
    render() {
        for (j=[1:m])
            translate([i,j,0]) sphere(d=i+j);
    }
    echo(i=i);
}

Watch the timing of the "echo" output.  Observe that the echo output
comes out instantly, and then the slow part starts.

If you have programmatic access to the CSG tree, and you have a Turing equivalent programming language, then it's guaranteed that you can write an algorithm to split the tree into disjoint shapes.  To solve the general case, you'd have to tessellate primitives into triangle meshes yourself, but that is doable in OpenSCAD. Obviously it would be slow, but that's why I said that performance considerations are really important. Obviously it would be better to have an operation that returns the mesh for a shape. I don't think it's that hard to implement (except for syntax). There's already a function that converts a CSG tree to a mesh, just call this function from the interpreter, then convert the mesh to an OpenSCAD value. You don't need to restructure OpenSCAD to do this (see below), except maybe for the syntax issues I mentioned. The arguments I've heard against providing this operation have mostly been about performance: the operation would slow down the onset of preview as much as render() does, and then iterating over the triangle mesh in OpenSCAD might be slow as well (depending on the model), potentially creating even more lag before the preview is rendered.

This rejected pull request demonstrates how to evaluate geometry from inside the interpreter. It's easy:
https://github.com/openscad/openscad/pull/1713
The relevant code is
GeometryEvaluator geomEvaluator(tree);
geom=geomEvaluator.evaluateGeometry(*nc,exact);

The scary part is the syntax. You might need to do major surgery on the parser. Maybe syntax like this:
geom = evaluate_geometry( cube(10); )
or from inside a module,
geom = evaluate_geometry( children(); )
The issue is that evaluate_geometry is not a module and not a function, it is some weird new syntax wired in to the parser. The argument is an OpenSCAD statement, making it a kind of syntax that isn't currently supported.

Doug Moen.

On Sat, Mar 27, 2021, at 1:08 PM, Jordan Brown wrote:

m = 6;
for (i=[1:n]) {
render() {
for (j=[1:m])
translate([i,j,0]) sphere(d=i+j);
}
echo(i=i);
}