Geometric information as data
On 12/15/2025 7:52 AM, Glenn Butcher via Discuss wrote:
- Make multiple copies. Right now, every time I need a corbel on my
current project, a railroad depot model, I need to import() it from
the .3mf file. 23 times. It would be nice to be able to 'corbel =
import("corbel.3mf");', then 'render corbel;' or somesuch 23 times
prepended with the requisite translate() calls to place them around
the building.
Are you concerned here about repetition, or about performance?
If you're concerned about repetition, I'd think that wrapping the import
in a module would do about all that can be done.
If you're concerned about performance, sure, but what's the actual
cost? How long does one of those imports take to execute? I rarely
import models of any file format, and never 3MF, so I don't have any
feel for how fast import is. (And of course I'm sure that the
complexity of the model matters.) If it takes 0.01 seconds, it's hard
to get excited about, but if it takes more than a second then indeed
multiplying it by 23 is painful.
Unfortunately, if that cost is small-ish, sub-second, it's hard to
measure, because you want to separate it from the cost of the operations
on the imported data and we have no way to say "import this and then
throw it away".
If you import the same file multiple times, does it really do that? Or does it just use a cached copy of the first import?
I guess I could check by doing a bunch of imports of the same large file while monitoring memory usage, but where’s the sport in that? 😊
From: Jordan Brown via Discuss discuss@lists.openscad.org
Sent: Monday, December 15, 2025 8:31 AM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Glenn Butcher glenn.butcher@gmail.com; Jordan Brown openscad@jordan.maileater.net
Subject: [OpenSCAD] Re: Geometric information as data
On 12/15/2025 7:52 AM, Glenn Butcher via Discuss wrote:
- Make multiple copies. Right now, every time I need a corbel on my current project, a railroad depot model, I need to import() it from the .3mf file. 23 times. It would be nice to be able to 'corbel = import("corbel.3mf");', then 'render corbel;' or somesuch 23 times prepended with the requisite translate() calls to place them around the building.
Are you concerned here about repetition, or about performance?
If you're concerned about repetition, I'd think that wrapping the import in a module would do about all that can be done.
If you're concerned about performance, sure, but what's the actual cost? How long does one of those imports take to execute? I rarely import models of any file format, and never 3MF, so I don't have any feel for how fast import is. (And of course I'm sure that the complexity of the model matters.) If it takes 0.01 seconds, it's hard to get excited about, but if it takes more than a second then indeed multiplying it by 23 is painful.
Unfortunately, if that cost is small-ish, sub-second, it's hard to measure, because you want to separate it from the cost of the operations on the imported data and we have no way to say "import this and then throw it away".
On 12/15/2025 9:05 AM, Lee DeRaud via Discuss wrote:
If you import the same file multiple times, does it really do that? Or
does it just use a cached copy of the first import?
I guess I could check by doing a bunch of imports of the same large
file while monitoring memory usage, but where’s the sport in that? 😊
I believe that preview will read and interpret the file every time, but
that render will read and interpret it only once.
(But that's based on my understanding of the behaviors, not on any
immediate source inspection or experimentation.)
Monitoring memory usage wouldn't really tell you, because whether or not
it does the import, when it adds that mesh to the model it's got to be
copied to incorporate it into the overall model mesh. (But a
system-call trace tool could tell you.)
On Mon, 2025-12-15 at 06:29 -0500, Adrian Mariano via Discuss wrote:
The OpenSCAD language provides no powerful data structures. If you
look up geometrical algorithms they almost always rely on things like
a priority queue that is supposed to have O(log n) insertion and O(1)
retrieval. That's not possible to implement in OpenSCAD. The
result is that implementation of such algorithms ends up being
quadratic or worse. My implementation of offset() in 2d in
userspace is O(N^2) and relies on heuristics that sometimes fail
because when I tried a robust implementation it was taking minutes to
run on even small inputs.
I have been meaning to ask something, and this has reminded me of it.
I was wondering how hard it would be to offset a 3D surface.
That's what I mean by intractable, and that was in 2d. Our
implementation of duplicate point removal for 3d geometry can take a
long time to run. The validator for polygon data usually takes tens
of minutes on inputs of moderate size.
On Mon, Dec 15, 2025 at 12:33 AM Cory Cross via Discuss
discuss@lists.openscad.org wrote:
On December 14, 2025 2:50:52 PM PST, Adrian Mariano via Discuss
discuss@lists.openscad.org wrote:
The difficulty of doing interesting things to 3d objects in
userspace is
that typically it's intractable in OpenSCAD language.
What do you mean by this?
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
larry -
I just discovered that MeshInspector (free for personal use) does a very
good 3D offset for STL/OBJ files.
Len
On Mon, Dec 15, 2025 at 12:30 PM larry via Discuss <
discuss@lists.openscad.org> wrote:
On Mon, 2025-12-15 at 06:29 -0500, Adrian Mariano via Discuss wrote:
The OpenSCAD language provides no powerful data structures. If you
look up geometrical algorithms they almost always rely on things like
a priority queue that is supposed to have O(log n) insertion and O(1)
retrieval. That's not possible to implement in OpenSCAD. The
result is that implementation of such algorithms ends up being
quadratic or worse. My implementation of offset() in 2d in
userspace is O(N^2) and relies on heuristics that sometimes fail
because when I tried a robust implementation it was taking minutes to
run on even small inputs.
I have been meaning to ask something, and this has reminded me of it.
I was wondering how hard it would be to offset a 3D surface.
That's what I mean by intractable, and that was in 2d. Our
implementation of duplicate point removal for 3d geometry can take a
long time to run. The validator for polygon data usually takes tens
of minutes on inputs of moderate size.
On Mon, Dec 15, 2025 at 12:33 AM Cory Cross via Discuss
discuss@lists.openscad.org wrote:
On December 14, 2025 2:50:52 PM PST, Adrian Mariano via Discuss
discuss@lists.openscad.org wrote:
The difficulty of doing interesting things to 3d objects in
userspace is
that typically it's intractable in OpenSCAD language.
What do you mean by this?
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Performance.
I build my models as parts, usually one file per part although for
printing I sometimes make assemblies. I'll make an integration.scad
that imports them all and places them, for fit-checks and such. For the
steam locomotive, ~23 parts/assemblies, rendering that was
multi-minute. Manifold incorporation did cut that to just under a
minute. On a Windows Surface 7 tablet.
If I were to get just one wish, it would be exposing Manifold's
Simplify() method, even if just as a parameter to surface(). OpenSCAD
builds 'naive' meshes from heightmaps, four triangles per quad. For
large textures, or many instances of smaller ones (think, stone wall),
the render burden can be onerous. In writing my C++ program to make
stone walls from black-n-white wall profile pictures, I found even small
values passed to a Simplify() application to the heightmap-based mesh
cut the triangle count at least 30%, and cut the overall render time by
that or more.
https://github.com/butcherg/stonewall
On 12/15/2025 9:30 AM, Jordan Brown wrote:
On 12/15/2025 7:52 AM, Glenn Butcher via Discuss wrote:
- Make multiple copies. Right now, every time I need a corbel on my
current project, a railroad depot model, I need to import() it from
the .3mf file. 23 times. It would be nice to be able to 'corbel =
import("corbel.3mf");', then 'render corbel;' or somesuch 23 times
prepended with the requisite translate() calls to place them around
the building.
Are you concerned here about repetition, or about performance?
If you're concerned about repetition, I'd think that wrapping the
import in a module would do about all that can be done.
If you're concerned about performance, sure, but what's the actual
cost? How long does one of those imports take to execute? I rarely
import models of any file format, and never 3MF, so I don't have any
feel for how fast import is. (And of course I'm sure that the
complexity of the model matters.) If it takes 0.01 seconds, it's hard
to get excited about, but if it takes more than a second then indeed
multiplying it by 23 is painful.
Unfortunately, if that cost is small-ish, sub-second, it's hard to
measure, because you want to separate it from the cost of the
operations on the imported data and we have no way to say "import this
and then throw it away".
Glenn:
For (1), can you create a module() that contains the import() and then
distribute the copies around using BOSL2's move_copies()?
On 12/15/2025 10:52 AM, Glenn Butcher via Discuss wrote:
-
Make multiple copies. Right now, every time I need a corbel on my
current project, a railroad depot model, I need to import() it from
the .3mf file. 23 times. It would be nice to be able to 'corbel =
import("corbel.3mf");', then 'render corbel;' or somesuch 23 times
prepended with the requisite translate() calls to place them around
the building. -
Mung meshes made from heightmaps. On the same project, I'm
modeling stone walls, and the stones have a taper down to the mortar.
I'm doing this right now in a C++ program that uses OpenCV to make
incremental contours by scaling copies of the original contour and
using them as multipliers against the texture heightmap, but I think
there's a mesh deformation method that would be more straightforward.
Also, being able to define heightmap tables in the language would be
handy, too. Oh, and exposing Manifold's Simplify() method would be
handy to reduce the complexity of heightmap-sourced meshes.
Glenn
On 12/14/2025 3:36 PM, Jordan Brown via Discuss wrote:
If you could get the points and vertexes of an OpenSCAD subassembly,
what would you do with the information?
That is, suppose there was a feature that would let you build up an
arbitrarily complex model, and would then return the points and faces
in the result - suitable for passing to polyhedron() - what would
that let you do?
A couple of quick starters:
- You could get the bounding box, and position the subassembly (or
another subassembly) based on those dimensions. - You could (not easily!) bend the object.
- You could calculate the center of mass.
People ask for this feature not-infrequently... what are you itching
to do, that's hard to do without it?
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Offsetting a 3d surface a small amount is relatively easy. The BOSL2
vnf_small_offset does this. The assumption is that you don’t need to add
any points and the offset distance is small enough that a naive offset
produces no intersections. The tricky thing is organizing the polyhedron
data so you can find the faces sounding a vertex. And deciding exactly how
to define the normal
My offset algorithm would be possible to extend to 3d but it would be even
slower, quadratic but a worse constant. I wouldn’t be surprised if it
turned out slower than minkowski.
On Mon, Dec 15, 2025 at 13:31 larry via Discuss discuss@lists.openscad.org
wrote:
On Mon, 2025-12-15 at 06:29 -0500, Adrian Mariano via Discuss wrote:
The OpenSCAD language provides no powerful data structures. If you
look up geometrical algorithms they almost always rely on things like
a priority queue that is supposed to have O(log n) insertion and O(1)
retrieval. That's not possible to implement in OpenSCAD. The
result is that implementation of such algorithms ends up being
quadratic or worse. My implementation of offset() in 2d in
userspace is O(N^2) and relies on heuristics that sometimes fail
because when I tried a robust implementation it was taking minutes to
run on even small inputs.
I have been meaning to ask something, and this has reminded me of it.
I was wondering how hard it would be to offset a 3D surface.
That's what I mean by intractable, and that was in 2d. Our
implementation of duplicate point removal for 3d geometry can take a
long time to run. The validator for polygon data usually takes tens
of minutes on inputs of moderate size.
On Mon, Dec 15, 2025 at 12:33 AM Cory Cross via Discuss
discuss@lists.openscad.org wrote:
On December 14, 2025 2:50:52 PM PST, Adrian Mariano via Discuss
discuss@lists.openscad.org wrote:
The difficulty of doing interesting things to 3d objects in
userspace is
that typically it's intractable in OpenSCAD language.
What do you mean by this?
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 12/15/25 3:29 AM, Adrian Mariano via Discuss wrote:
The OpenSCAD language provides no powerful data structures. If you
look up geometrical algorithms they almost always rely on things like
a priority queue that is supposed to have O(log n) insertion and O(1)
retrieval. That's not possible to implement in OpenSCAD.
It is possible! There are efficient priority queues available for
immutable functional languages. I have started the topic at
https://github.com/openscad/openscad/issues/6441
- Cory
To me "possible" means that I can implement, right now, in OpenSCAD
language, an efficient priority queue. Not that the feature could be added
into the language by the devs. Any feature can potentially be added by the
devs. It's possible that there's some higher level geometry access feature
that would be useful---basically the thing that one wants the priority
queue in order to do. So for example maybe you could specify a query order
for geometry and then query a polyhedron in that order. It's hard to know
really what would be ideal here because when I think about things we might
implement I immediately rule out the possibility of any kind of processing
along these lines since it's intractable (right now).
Another thing that might be useful is structured access to geometry rather
than an unstructured list of faces. As I mentioned above, the tricky part
of doing "small" offset is organizing the data so that I can efficiently
find the faces around each vertex. For many operations which are
reasonable to perform in userspace, this processing is the dominant part of
the work. I think in principle it's n log n since it's a quicksort, but
I'm not sure about the practical behavior.
On Mon, Dec 15, 2025 at 4:16 PM Cory Cross via Discuss <
discuss@lists.openscad.org> wrote:
On 12/15/25 3:29 AM, Adrian Mariano via Discuss wrote:
The OpenSCAD language provides no powerful data structures. If you
look up geometrical algorithms they almost always rely on things like
a priority queue that is supposed to have O(log n) insertion and O(1)
retrieval. That's not possible to implement in OpenSCAD.
It is possible! There are efficient priority queues available for
immutable functional languages. I have started the topic at
https://github.com/openscad/openscad/issues/6441
- Cory
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org