TA
Todd Allen
Sat, Jan 3, 2026 11:59 PM
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.
Being able to get point lists for 2d data such as generated by text,
projections of 3d models and BOSL2's hierarchically attached 2d modules
would let me do things I currently do in better ways. I don't currently do
much in OpenSCAD with 3d geometry as data. I am aware of the VNF stuff in
BOSL2 but vnf_bend is the only part of it I've used. If it was easy to
extract a vnf from a 3d model and there was a library of routines making it
easy to select and manipulate vertices, faces, edges and paths based on
things like normals, angles/quaternions and distances then I would likely
find a use case or two although thinking more about 3d geometry as data
might increase my frustration with OpenSCAD's immutable variables and the
desire to do more in python.
On Sat, Jan 3, 2026 at 4:23 PM Adrian Mariano avm4@cornell.edu wrote:
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
> 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.
Being able to get point lists for 2d data such as generated by text,
projections of 3d models and BOSL2's hierarchically attached 2d modules
would let me do things I currently do in better ways. I don't currently do
much in OpenSCAD with 3d geometry as data. I am aware of the VNF stuff in
BOSL2 but vnf_bend is the only part of it I've used. If it was easy to
extract a vnf from a 3d model and there was a library of routines making it
easy to select and manipulate vertices, faces, edges and paths based on
things like normals, angles/quaternions and distances then I would likely
find a use case or two although thinking more about 3d geometry as data
might increase my frustration with OpenSCAD's immutable variables and the
desire to do more in python.
On Sat, Jan 3, 2026 at 4:23 PM Adrian Mariano <avm4@cornell.edu> wrote:
> 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
>>
>>