Geometric information as data
I think if there is an efficient way to perform offset that is robust, I
will be happy to look at it and try to implement it in Manifold. So far
most approaches I know are quite hacky.
On Tue, Dec 16, 2025, 07:58 Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I specifically implemented only SMALL offset, meaning I assumed that none
of the things that make offset nontrivial are permitted to occur. (That's
my definition of "small".) I don't know anything about robust general
offset, but it would be a very useful thing to have, since 99.9% of uses of
minkowski are really just offset.
On Mon, Dec 15, 2025 at 7:18 PM pca006132 john.lck40@gmail.com wrote:
I think if there is an efficient way to perform offset that is robust, I
will be happy to look at it and try to implement it in Manifold. So far
most approaches I know are quite hacky.
On Tue, Dec 16, 2025, 07:58 Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
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
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On December 15, 2025 3:58:16 PM PST, Adrian Mariano via Discuss discuss@lists.openscad.org wrote:
To me "possible" means that I can implement, right now, in OpenSCAD
language, an efficient priority queue.
I updated my thread, because it is actually possible! There are fully-immutable-functional priority queue algorithms which use structural sharing (supported by OpenSCAD language) to either be optimal (O(1)) or near-optimal (O(ln n)). I'll see if it's easy to translate a Leftist Heap to OpenSCAD with some help.
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).
We're discussing what to expose from Manifold right now over at https://github.com/openscad/openscad/issues/2076#issuecomment-3636010396 (my suggestion being: everything we can find!)
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.
There's probably a term for it, but indexed vertex set sounds like some of the right words. Mapping from vertex index to a list of all face indices which reference that vertex, right? With mutable data structures that's O(f). Not sure about doing it immutably.
- Cory
Well, that all sounded vaguely like English, but I only understood about
every third word.
I have obviously been retired too long.
-----Original Message-----
From: Cory Cross via Discuss discuss@lists.openscad.org
Sent: Monday, December 15, 2025 9:21 PM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Cory Cross openscad@corycross.org
Subject: [OpenSCAD] Re: Geometric information as data
On December 15, 2025 3:58:16 PM PST, Adrian Mariano via Discuss
discuss@lists.openscad.org wrote:
To me "possible" means that I can implement, right now, in OpenSCAD
language, an efficient priority queue.
I updated my thread, because it is actually possible! There are
fully-immutable-functional priority queue algorithms which use structural
sharing (supported by OpenSCAD language) to either be optimal (O(1)) or
near-optimal (O(ln n)). I'll see if it's easy to translate a Leftist Heap to
OpenSCAD with some help.
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).
We're discussing what to expose from Manifold right now over at
https://github.com/openscad/openscad/issues/2076#issuecomment-3636010396 (my
suggestion being: everything we can find!)
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.
There's probably a term for it, but indexed vertex set sounds like some of
the right words. Mapping from vertex index to a list of all face indices
which reference that vertex, right? With mutable data structures that's
O(f). Not sure about doing it immutably.
- Cory
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
If you used pythonscad you could access all points AS simple AS using mesh()
Lee DeRaud via Discuss discuss@lists.openscad.org schrieb am Di., 16.
Dez. 2025, 12:10:
Well, that all sounded vaguely like English, but I only understood about
every third word.
I have obviously been retired too long.
-----Original Message-----
From: Cory Cross via Discuss discuss@lists.openscad.org
Sent: Monday, December 15, 2025 9:21 PM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Cory Cross openscad@corycross.org
Subject: [OpenSCAD] Re: Geometric information as data
On December 15, 2025 3:58:16 PM PST, Adrian Mariano via Discuss
discuss@lists.openscad.org wrote:
To me "possible" means that I can implement, right now, in OpenSCAD
language, an efficient priority queue.
I updated my thread, because it is actually possible! There are
fully-immutable-functional priority queue algorithms which use structural
sharing (supported by OpenSCAD language) to either be optimal (O(1)) or
near-optimal (O(ln n)). I'll see if it's easy to translate a Leftist Heap
to
OpenSCAD with some help.
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).
We're discussing what to expose from Manifold right now over at
https://github.com/openscad/openscad/issues/2076#issuecomment-3636010396
(my
suggestion being: everything we can find!)
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.
There's probably a term for it, but indexed vertex set sounds like some of
the right words. Mapping from vertex index to a list of all face indices
which reference that vertex, right? With mutable data structures that's
O(f). Not sure about doing it immutably.
- Cory
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 was not talking about "accessing all points". I was talking about
accessing the faces that are adjacent to every vertex in an efficient
manner (i.e. better than quadratic).
On Tue, Dec 16, 2025 at 10:06 AM Guenther Sohler via Discuss <
discuss@lists.openscad.org> wrote:
If you used pythonscad you could access all points AS simple AS using
mesh()
Lee DeRaud via Discuss discuss@lists.openscad.org schrieb am Di., 16.
Dez. 2025, 12:10:
Well, that all sounded vaguely like English, but I only understood about
every third word.
I have obviously been retired too long.
-----Original Message-----
From: Cory Cross via Discuss discuss@lists.openscad.org
Sent: Monday, December 15, 2025 9:21 PM
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: Cory Cross openscad@corycross.org
Subject: [OpenSCAD] Re: Geometric information as data
On December 15, 2025 3:58:16 PM PST, Adrian Mariano via Discuss
discuss@lists.openscad.org wrote:
To me "possible" means that I can implement, right now, in OpenSCAD
language, an efficient priority queue.
I updated my thread, because it is actually possible! There are
fully-immutable-functional priority queue algorithms which use structural
sharing (supported by OpenSCAD language) to either be optimal (O(1)) or
near-optimal (O(ln n)). I'll see if it's easy to translate a Leftist Heap
to
OpenSCAD with some help.
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).
We're discussing what to expose from Manifold right now over at
https://github.com/openscad/openscad/issues/2076#issuecomment-3636010396
(my
suggestion being: everything we can find!)
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.
There's probably a term for it, but indexed vertex set sounds like some of
the right words. Mapping from vertex index to a list of all face indices
which reference that vertex, right? With mutable data structures that's
O(f). Not sure about doing it immutably.
- Cory
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
If you could get the points and vertexes of an OpenSCAD subassembly, what
would you do with the information?
BOSL2 has useful (which I consider essential) operations such as skin() and
sweep() which require paths as point lists. It would be very helpful to be
able to extract this data from subassemblies for those operations or
perhaps even better to create equivalent primitives directly in OpenSCAD.
Imagine having a loft() module which could connect two profiles or could
connect non convex 2d children(). We have hull() and minkowski() but these
alone are insufficient to achieve this very basic functionality which is
present in most every other CAD system.
On Sun, Dec 14, 2025 at 4:44 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> 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 to discuss-leave@lists.openscad.org
Todd, a lot of 2d stuff is already possible with point lists in BOSL2. The
main issues are slow run time and less robust implementation. What sort
of things do you envision that can't already be done?
The other thread about separating objects is an example of something that
we could do in 3d if we had access to the geometry data: breaking an object
apart into its connected components.
On Fri, Jan 2, 2026 at 12:06 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
If you could get the points and vertexes of an OpenSCAD subassembly,
what would you do with the information?
BOSL2 has useful (which I consider essential) operations such as skin()
and sweep() which require paths as point lists. It would be very helpful
to be able to extract this data from subassemblies for those operations or
perhaps even better to create equivalent primitives directly in OpenSCAD.
Imagine having a loft() module which could connect two profiles or could
connect non convex 2d children(). We have hull() and minkowski() but these
alone are insufficient to achieve this very basic functionality which is
present in most every other CAD system.
On Sun, Dec 14, 2025 at 4:44 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> 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 to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Todd, a lot of 2d stuff is already possible with point lists in BOSL2.
The main issues are slow run time and less robust implementation. What
sort of things do you envision that can't already be done?
I use BOSL2 sweeps and skin extensively and would have ditched OpenSCAD if
BOSL2 did not exist. But I can not use skin and sweeps as much as I
would like. For example, BOSL2 provides modules for text but does not have
functions that return text as point lists. So for a single example of
countless problems, I can not use offset_sweep to extrude text with a tear
drop bottom. BOSL2 has convex_offset_extrude implemented using hull but
text isn't convex. If OpenSCAD had a loft operation of reasonable
efficiency then it would be easy to have an offset_extrude which would be
suitable for use with text. Even if there is a library somewhere with
functions returning text outlines there are many other library modules that
don't have equivalents implemented as functions. Reimplementing things as
functions can be tedious as one gives up features such as BOSL2's
hierarchical attachments. If there is a library with functions for text
the utility is still constrained by the efficiency of the approach of doing
sweeps with point lists. The workarounds I know of to implement
offset_extrude such as stacking many thin offset linear_extrude layers or
doing it with my hull_join are also limited by efficiency.
So back to Jordan's original question of how would I use a feature that
would return the vertices of an OpenSCAD subassembly, my very first desire
would be an equivalent to OpenScad's projection() module done as a function
returning a BOSL2 region data structure to use with BOSL2's sweeps, skin,
etc. My second desire would be an expansion of OpenSCAD's primitives to
include things such as loft/skin and sweeps which should have better
performance and thus wider utility than operations on point lists.
On Sat, Jan 3, 2026 at 8:04 AM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
Todd, a lot of 2d stuff is already possible with point lists in BOSL2.
The main issues are slow run time and less robust implementation. What
sort of things do you envision that can't already be done?
The other thread about separating objects is an example of something that
we could do in 3d if we had access to the geometry data: breaking an object
apart into its connected components.
On Fri, Jan 2, 2026 at 12:06 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
If you could get the points and vertexes of an OpenSCAD subassembly,
what would you do with the information?
BOSL2 has useful (which I consider essential) operations such as skin()
and sweep() which require paths as point lists. It would be very helpful
to be able to extract this data from subassemblies for those operations or
perhaps even better to create equivalent primitives directly in OpenSCAD.
Imagine having a loft() module which could connect two profiles or could
connect non convex 2d children(). We have hull() and minkowski() but these
alone are insufficient to achieve this very basic functionality which is
present in most every other CAD system.
On Sun, Dec 14, 2025 at 4:44 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> 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 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
Yeah, text is definitely a major use-case where it's frustrating that we
don't have access to point lists. Note that if you can return objects as
point lists you don't need a projection module that returns data. You can
run projection() first and then return the resulting 2d data. I think
sweeps are something that is not notably inefficient to do in user space.
The algorithm is linear. Depending on how you run skin it can be O(n^3),
but I'm not sure if there's a clever way to make it faster.
The question of how you would use a feature that provides access to
geometry data seems to be that you would extract point lists from 2d
objects to use for skins and sweeps. This suggests that you do not have a
use case for extracting 3d geometry data.
On Sat, Jan 3, 2026 at 4:45 PM Todd Allen speedebikes@gmail.com wrote:
Todd, a lot of 2d stuff is already possible with point lists in BOSL2.
The main issues are slow run time and less robust implementation. What
sort of things do you envision that can't already be done?
I use BOSL2 sweeps and skin extensively and would have ditched OpenSCAD if
BOSL2 did not exist. But I can not use skin and sweeps as much as I
would like. For example, BOSL2 provides modules for text but does not have
functions that return text as point lists. So for a single example of
countless problems, I can not use offset_sweep to extrude text with a tear
drop bottom. BOSL2 has convex_offset_extrude implemented using hull but
text isn't convex. If OpenSCAD had a loft operation of reasonable
efficiency then it would be easy to have an offset_extrude which would be
suitable for use with text. Even if there is a library somewhere with
functions returning text outlines there are many other library modules that
don't have equivalents implemented as functions. Reimplementing things as
functions can be tedious as one gives up features such as BOSL2's
hierarchical attachments. If there is a library with functions for text
the utility is still constrained by the efficiency of the approach of doing
sweeps with point lists. The workarounds I know of to implement
offset_extrude such as stacking many thin offset linear_extrude layers or
doing it with my hull_join are also limited by efficiency.
So back to Jordan's original question of how would I use a feature that
would return the vertices of an OpenSCAD subassembly, my very first desire
would be an equivalent to OpenScad's projection() module done as a function
returning a BOSL2 region data structure to use with BOSL2's sweeps, skin,
etc. My second desire would be an expansion of OpenSCAD's primitives to
include things such as loft/skin and sweeps which should have better
performance and thus wider utility than operations on point lists.
On Sat, Jan 3, 2026 at 8:04 AM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
Todd, a lot of 2d stuff is already possible with point lists in BOSL2.
The main issues are slow run time and less robust implementation. What
sort of things do you envision that can't already be done?
The other thread about separating objects is an example of something that
we could do in 3d if we had access to the geometry data: breaking an object
apart into its connected components.
On Fri, Jan 2, 2026 at 12:06 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
If you could get the points and vertexes of an OpenSCAD subassembly,
what would you do with the information?
BOSL2 has useful (which I consider essential) operations such as skin()
and sweep() which require paths as point lists. It would be very helpful
to be able to extract this data from subassemblies for those operations or
perhaps even better to create equivalent primitives directly in OpenSCAD.
Imagine having a loft() module which could connect two profiles or could
connect non convex 2d children(). We have hull() and minkowski() but these
alone are insufficient to achieve this very basic functionality which is
present in most every other CAD system.
On Sun, Dec 14, 2025 at 4:44 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> 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 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