Named objects
When using the lazy union option in recent versions of OpenSCAD it is possible to have multiple objects in one file. When I import them into my slicer, they come in as OpenSCAD Model 1, OpenSCAD Model 2, …
Is it possible to specify the object name in OpenSCAD?
Also, it appears that grouping objects in a module creates an implicit union() and thus just one object, so it’s only possible to have the lazy union outside of any modules. Is it possible to have the lazy union feature work inside a module?
Thanks,
Mark
I'll pile on to the naming thing. I'm using lazy union to make a multi- object .3MF of an integration render, to be used in a web viewer for other project members to study the project, and selectively turn on/off the various objects.
On April 20, 2026 12:11:24 PM MDT, Mark Erbaugh via Discuss discuss@lists.openscad.org wrote:
When using the lazy union option in recent versions of OpenSCAD it is possible to have multiple objects in one file. When I import them into my slicer, they come in as OpenSCAD Model 1, OpenSCAD Model 2, …
Is it possible to specify the object name in OpenSCAD?
Also, it appears that grouping objects in a module creates an implicit union() and thus just one object, so it’s only possible to have the lazy union outside of any modules. Is it possible to have the lazy union feature work inside a module?
Thanks,
Mark
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 4/20/26 11:11 AM, Mark Erbaugh via Discuss wrote:
When using the lazy union option in recent versions of OpenSCAD it is possible to have multiple objects in one file. When I import them into my slicer, they come in as OpenSCAD Model 1, OpenSCAD Model 2, …
Is it possible to specify the object name in OpenSCAD?
No. There's a github issue about naming parts though.
Cory
Also, it appears that grouping objects in a module creates an implicit union() and thus just one object, so it’s only possible to have the lazy union outside of any modules. Is it possible to have the lazy union feature work inside a module?
This is one of the reasons that the "lazy union" feature is not expected
to survive in its current form.
It was intended as a performance optimization, not as a mechanism for
managing multi-part models. With the introduction of Manifold it has
been largely unnecessary for performance, and for a number of reasons it
is poorly suited to addressing the need for multi-part models.
Again, you should assume that "lazy union" will not survive in its
current form. There is likely to be some other solution to the various
multi-part-model problems, but that won't be it.
Thanks,
I’ve learned a lot about how OpenSCAD works through the comments in this thread, but correct me if I'm wrong, lazy unions are currently the only way to deal with multi-part models, short of multiple rendering steps.
One of the things I’ve seen many times is that someone invents something and the community comes up with ways to use it in ways beyond what the inventor intended. As long as these aren’t harmful, dangerous or illegal, I see no problem in using them.
This is one of the reasons that the "lazy union" feature is not expected to survive in its current form.
It was intended as a performance optimization, not as a mechanism for managing multi-part models. With the introduction of Manifold it has been largely unnecessary for performance, and for a number of reasons it is poorly suited to addressing the need for multi-part models.
Again, you should assume that "lazy union" will not survive in its current form. There is likely to be some other solution to the various multi-part-model problems, but that won't be it.
I think Jordan's point is that if you build up a work flow based on lazy
union then you're going to be frustrated when that feature disappears. Or
you'll be stuck using an old dev snapshot and not able to move forward.
That's the thing to be concerned about here. The lazy union feature is not
going to be available in the future.
On Tue, Apr 21, 2026 at 7:04 AM Mark Erbaugh via Discuss <
discuss@lists.openscad.org> wrote:
Thanks,
I’ve learned a lot about how OpenSCAD works through the comments in this
thread, but correct me if I'm wrong, lazy unions are currently the only way
to deal with multi-part models, short of multiple rendering steps.
One of the things I’ve seen many times is that someone invents something
and the community comes up with ways to use it in ways beyond what the
inventor intended. As long as these aren’t harmful, dangerous or illegal, I
see no problem in using them.
This is one of the reasons that the "lazy union" feature is not expected
to survive in its current form.
It was intended as a performance optimization, not as a mechanism for
managing multi-part models. With the introduction of Manifold it has been
largely unnecessary for performance, and for a number of reasons it is
poorly suited to addressing the need for multi-part models.
Again, you should assume that "lazy union" will not survive in its current
form. There is likely to be some other solution to the various
multi-part-model problems, but that won't be it.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
As long as a replacement mechanism is added for multipart export before
lazy union is removed it wouldn't be a problem.
If I live long enough to finish my multi-extruder design then it wouldn't
be an issue for me as all my STLs are automatically generated, so all I
would need to do is name them accordingly.
On Tue, 21 Apr 2026 at 12:13, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
I think Jordan's point is that if you build up a work flow based on lazy
union then you're going to be frustrated when that feature disappears. Or
you'll be stuck using an old dev snapshot and not able to move forward.
That's the thing to be concerned about here. The lazy union feature is not
going to be available in the future.
On Tue, Apr 21, 2026 at 7:04 AM Mark Erbaugh via Discuss <
discuss@lists.openscad.org> wrote:
Thanks,
I’ve learned a lot about how OpenSCAD works through the comments in this
thread, but correct me if I'm wrong, lazy unions are currently the only way
to deal with multi-part models, short of multiple rendering steps.
One of the things I’ve seen many times is that someone invents something
and the community comes up with ways to use it in ways beyond what the
inventor intended. As long as these aren’t harmful, dangerous or illegal, I
see no problem in using them.
This is one of the reasons that the "lazy union" feature is not expected
to survive in its current form.
It was intended as a performance optimization, not as a mechanism for
managing multi-part models. With the introduction of Manifold it has been
largely unnecessary for performance, and for a number of reasons it is
poorly suited to addressing the need for multi-part models.
Again, you should assume that "lazy union" will not survive in its
current form. There is likely to be some other solution to the various
multi-part-model problems, but that won't be 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
I agree, but as I haven’t found any other mechanism for creating a multi-part .3mf file.
I’m working on a workflow where there is one module for each part and then at the end of the file a lazy union of those modules is created. When lazy unions are replaced, it should be simple matter of replacing them with a mechanism that calls each of the individual part modules with the new method.
I think Jordan's point is that if you build up a work flow based on lazy union then you're going to be frustrated when that feature disappears. Or you'll be stuck using an old dev snapshot and not able to move forward. That's the thing to be concerned about here. The lazy union feature is not going to be available in the future.
The 3MF specification allows multiple 'objects' in a file, and any of those objects can be a distinct mesh. It would be nice if OpenSCAD allowed one to distinctly managed multiple meshes at export.
I wrote a command-line CAD program a short while ago that manages a vector of Manifolds; I'm going to add a 'name' operator to handle such, all the way into 3MF export, so I'm good...
On April 21, 2026 6:26:54 AM MDT, Mark Erbaugh via Discuss discuss@lists.openscad.org wrote:
I agree, but as I haven’t found any other mechanism for creating a multi-part .3mf file.
I’m working on a workflow where there is one module for each part and then at the end of the file a lazy union of those modules is created. When lazy unions are replaced, it should be simple matter of replacing them with a mechanism that calls each of the individual part modules with the new method.
I think Jordan's point is that if you build up a work flow based on lazy union then you're going to be frustrated when that feature disappears. Or you'll be stuck using an old dev snapshot and not able to move forward. That's the thing to be concerned about here. The lazy union feature is not going to be available in the future.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
One of the things I’ve seen many times is that someone invents something and the community comes up with ways to use it in ways beyond what the inventor intended. As long as these aren’t harmful, dangerous or illegal, I see no problem in using them.
The question is then what happens to that behavior when the creators eventually build a feature to address the need in the “right” way. There will often, even usually, be those who demand that the old half-bug behavior be maintained, because eliminating it breaks their workflow. The creators are evil, or incompetent, because they should maintain “compatibility” at any cost. The result is no fun for anybody.
So… you’ve been warned. You should expect that at some point there will be a designed mechanism for multi-part models, and that at that point “lazy union” will likely go away.