JB
Jordan Brown
Thu, Sep 3, 2026 12:52 AM
On 9/2/2026 4:57 PM, Mark Erbaugh via Discuss wrote:
I’ve been using a lazy union for multi-color models. It works well and I hope if it is “fixed” it doesn’t break a lot of my models. Here’s some demo code:
In my opinion - and I'm not an authority - you should expect that at
some point you will need to update those models.
That's what the "experimental" designation means, and why you must opt
in to be able to use an experimental feature. Features marked as
experimental may never be delivered "for real", or may arrive in a
subtly or completely different form.
(But I see that we don't say that prominently in the current UI, and we
should.)
On 9/2/2026 4:57 PM, Mark Erbaugh via Discuss wrote:
> I’ve been using a lazy union for multi-color models. It works well and I hope if it is “fixed” it doesn’t break a lot of my models. Here’s some demo code:
In my opinion - and I'm not an authority - you should expect that at
some point you will need to update those models.
That's what the "experimental" designation means, and why you must opt
in to be able to use an experimental feature. Features marked as
experimental may never be delivered "for real", or may arrive in a
subtly or completely different form.
(But I see that we don't say that prominently in the current UI, and we
should.)
LM
Leonard Martin Struttmann
Thu, Sep 3, 2026 2:29 AM
I would hope, though, that the evolution of technology that we are seeing
here (i.e., the ever increasing use of multi-filament printers) would give
the devs incentives to find ways for our users to easily adapt current
work-flows to use these new printers.
Sorry about the run-on sentence.
Len
On Wed, Sep 2, 2026 at 7:52 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 9/2/2026 4:57 PM, Mark Erbaugh via Discuss wrote:
I’ve been using a lazy union for multi-color models. It works well and I hope if it is “fixed” it doesn’t break a lot of my models. Here’s some demo code:
In my opinion - and I'm not an authority - you should expect that at some
point you will need to update those models.
That's what the "experimental" designation means, and why you must opt in
to be able to use an experimental feature. Features marked as experimental
may never be delivered "for real", or may arrive in a subtly or completely
different form.
(But I see that we don't say that prominently in the current UI, and we
should.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I would hope, though, that the evolution of technology that we are seeing
here (i.e., the ever increasing use of multi-filament printers) would give
the devs incentives to find ways for our users to easily adapt current
work-flows to use these new printers.
Sorry about the run-on sentence.
Len
On Wed, Sep 2, 2026 at 7:52 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
> On 9/2/2026 4:57 PM, Mark Erbaugh via Discuss wrote:
>
> I’ve been using a lazy union for multi-color models. It works well and I hope if it is “fixed” it doesn’t break a lot of my models. Here’s some demo code:
>
>
> In my opinion - and I'm not an authority - you should expect that at some
> point you will need to update those models.
>
> That's what the "experimental" designation means, and why you must opt in
> to be able to use an experimental feature. Features marked as experimental
> may never be delivered "for real", or may arrive in a subtly or completely
> different form.
>
> (But I see that we don't say that prominently in the current UI, and we
> should.)
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Thu, Sep 3, 2026 4:01 AM
On 9/2/2026 7:29 PM, Leonard Martin Struttmann via Discuss wrote:
I would hope, though, that the evolution of technology that we are
seeing here (i.e., the ever increasing use of multi-filament printers)
would give the devs incentives to find ways for our users to easily
adapt current work-flows to use these new printers.
I'm in the queue for a Prusa INDX upgrade, so I have a personal
incentive to make multi-color/multi-material handling be a first-class
citizen.
Will that first-class-citizen handling look at all like Lazy Union?
Probably not. LU as currently designed - and, for this use case, as it
must work - can never be enabled by default. It takes models that
were well-defined without LU and yields ill-defined and arguably invalid
results. Even in the best cases, it takes models that currently export
as a single "part" and exports them as multiple parts, even if that was
not the user's intent.
Will it be hard to adapt an LU-dependent model to use that
first-class-citizen feature? Probably not, but it may depend on how
complex the model is. If the model is designed so that module
invocations on its top level represent individual "parts", I would
expect that it will be simple. If, on the other hand, the part
boundaries are deeply buried inside the program, I expect that you'd
have to hunt down all of the part boundaries and mark them.
Will LU be killed the moment that a replacement is available? Probably
not; there will probably be a transition period where both are
available. But will that transition period be years and years, as has
been usual for incompatible changes? I would hope not; LU is and has
always been an experimental feature.
On 9/2/2026 7:29 PM, Leonard Martin Struttmann via Discuss wrote:
> I would hope, though, that the evolution of technology that we are
> seeing here (i.e., the ever increasing use of multi-filament printers)
> would give the devs incentives to find ways for our users to easily
> adapt current work-flows to use these new printers.
I'm in the queue for a Prusa INDX upgrade, so I have a personal
incentive to make multi-color/multi-material handling be a first-class
citizen.
Will that first-class-citizen handling look at all like Lazy Union?
Probably not. LU as currently designed - and, for this use case, as it
*must* work - can never be enabled by default. It takes models that
were well-defined without LU and yields ill-defined and arguably invalid
results. Even in the best cases, it takes models that currently export
as a single "part" and exports them as multiple parts, even if that was
not the user's intent.
Will it be hard to adapt an LU-dependent model to use that
first-class-citizen feature? Probably not, but it may depend on how
complex the model is. If the model is designed so that module
invocations on its top level represent individual "parts", I would
expect that it will be simple. If, on the other hand, the part
boundaries are deeply buried inside the program, I expect that you'd
have to hunt down all of the part boundaries and mark them.
Will LU be killed the moment that a replacement is available? Probably
not; there will probably be a transition period where both are
available. But will that transition period be years and years, as has
been usual for incompatible changes? I would hope not; LU is and has
always been an experimental feature.
TR
Thomas Richter
Thu, Sep 3, 2026 8:19 AM
You can rename the model parts, even though it's somewhat tedious. But for me it works:
- rename the .3mf to .zip (or simply append a .zip)
- unzip the zip
- go into the folder 3D and open the file
3dmodel.model with a text editor
- search for "OpenSCAD Model" and modify the
name attributes in the <object id="2" name="OpenSCAD Model ... XML tags to whatever you want to name the parts
- zip the folder again and rename it to .3mf
ATTENTION: On a Mac you need to delete the .DS_Store and other system folders. Otherwise the slicers deny the file to be corrupt. This can be achieved by zipping the folder in the Terminal. Run the following code INSIDE the root folder of the unzipped model:
zip -r ../renamed-parts-model.3mf * -x "*.DS_Store" -x "__MACOSX*"
Best,
Thomas
Yes, the original use case for lazy union was ill-considered, but there are still other reasons for retaining it. Particularly, if one (well, I) wants to model an assembly of discrete parts and save it as a multi-mesh .3mf. OpenSCAD will currently save such, owing to LU, but it doesn't provide the capability to name the individual meshes in the 3mf export.
It's not all just about 3D printing...
On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
There are no really good answers.
"Lazy union" shows up in most of the answers. However, LU as it is currently designed and implemented is not a good answer... it just happens to sort of accidentally produce useful results. It was designed as an optimization, and one of its key problems is that it produces results that aren't compatible with "ordinary" operation. You should assume that it will not continue to exist in its current form and that any workflow based on it will need changes when something better comes along. (This is why it is classified as "experimental".)
I would do something like Adam says, with a wrapper module that selectively generates each color, and a shell script that runs OpenSCAD multiple times to generate individual per-color files.
It looks like colorscad is a shell script that automates most of the process.
The good news is that I just ordered an INDX kit for my Core ONE+, and so my personal incentive to make something better happen is bumping way up...
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
You can rename the model parts, even though it's somewhat tedious. But for me it works:
- rename the .3mf to .zip (or simply append a .zip)
- unzip the zip
- go into the folder 3D and open the file `3dmodel.model` with a text editor
- search for "OpenSCAD Model" and modify the `name` attributes in the `<object id="2" name="OpenSCAD Model ...` XML tags to whatever you want to name the parts
- zip the folder again and rename it to .3mf
ATTENTION: On a Mac you need to delete the `.DS_Store` and other system folders. Otherwise the slicers deny the file to be corrupt. This can be achieved by zipping the folder in the Terminal. Run the following code INSIDE the root folder of the unzipped model:
```console
zip -r ../renamed-parts-model.3mf * -x "*.DS_Store" -x "__MACOSX*"
```
Best,
Thomas
> Yes, the original use case for lazy union was ill-considered, but there are still other reasons for retaining it. Particularly, if one (well, I) wants to model an assembly of discrete parts and save it as a multi-mesh .3mf. OpenSCAD will currently save such, owing to LU, but it doesn't provide the capability to name the individual meshes in the 3mf export.
> It's not all just about 3D printing...
> On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
>> There are no really good answers.
>>
>> "Lazy union" shows up in most of the answers. However, LU as it is currently designed and implemented is *not* a good answer... it just happens to sort of accidentally produce useful results. It was designed as an optimization, and one of its key problems is that it produces results that aren't compatible with "ordinary" operation. You should assume that it will not continue to exist in its current form and that any workflow based on it will need changes when something better comes along. (This is why it is classified as "experimental".)
>>
>> I would do something like Adam says, with a wrapper module that selectively generates each color, and a shell script that runs OpenSCAD multiple times to generate individual per-color files.
>>
>> It looks like colorscad is a shell script that automates most of the process.
>>
>> The good news is that I just ordered an INDX kit for my Core ONE+, and so my personal incentive to make something better happen is bumping way up...
>>
>>
>> _______________________________________________
>> 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
GB
Glenn Butcher
Thu, Sep 3, 2026 1:15 PM
I wrote a command-line CAD program using the functionality of the
Manifold library, and it has a rudimentary ability to save .3mf files
with individually named meshes:
https://github.com/butcherg/cadsh
The way I'm using it for the subject use case is to model the individual
components as separate .scad scripts, export each to .3mf, then I use
cadsh to load and name each, then save to a single .3mf. Here's the
result, in the og3d viewer:
https://glenn.pulpitrock.net/DRG_163/Models/integration/#model=integration.3mf
The left pane has a list of the individual named meshes from the
integration.3mf file. (click on the gear, and turn on 'Show Edges' for a
better view)
Glenn
On 9/3/2026 2:19 AM, Thomas Richter wrote:
You can rename the model parts, even though it's somewhat tedious. But for me it works:
- rename the .3mf to .zip (or simply append a .zip)
- unzip the zip
- go into the folder 3D and open the file
3dmodel.model with a text editor
- search for "OpenSCAD Model" and modify the
name attributes in the <object id="2" name="OpenSCAD Model ... XML tags to whatever you want to name the parts
- zip the folder again and rename it to .3mf
ATTENTION: On a Mac you need to delete the .DS_Store and other system folders. Otherwise the slicers deny the file to be corrupt. This can be achieved by zipping the folder in the Terminal. Run the following code INSIDE the root folder of the unzipped model:
zip -r ../renamed-parts-model.3mf * -x "*.DS_Store" -x "__MACOSX*"
Best,
Thomas
Yes, the original use case for lazy union was ill-considered, but there are still other reasons for retaining it. Particularly, if one (well, I) wants to model an assembly of discrete parts and save it as a multi-mesh .3mf. OpenSCAD will currently save such, owing to LU, but it doesn't provide the capability to name the individual meshes in the 3mf export.
It's not all just about 3D printing...
On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
There are no really good answers.
"Lazy union" shows up in most of the answers. However, LU as it is currently designed and implemented is not a good answer... it just happens to sort of accidentally produce useful results. It was designed as an optimization, and one of its key problems is that it produces results that aren't compatible with "ordinary" operation. You should assume that it will not continue to exist in its current form and that any workflow based on it will need changes when something better comes along. (This is why it is classified as "experimental".)
I would do something like Adam says, with a wrapper module that selectively generates each color, and a shell script that runs OpenSCAD multiple times to generate individual per-color files.
It looks like colorscad is a shell script that automates most of the process.
The good news is that I just ordered an INDX kit for my Core ONE+, and so my personal incentive to make something better happen is bumping way up...
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I wrote a command-line CAD program using the functionality of the
Manifold library, and it has a rudimentary ability to save .3mf files
with individually named meshes:
https://github.com/butcherg/cadsh
The way I'm using it for the subject use case is to model the individual
components as separate .scad scripts, export each to .3mf, then I use
cadsh to load and name each, then save to a single .3mf. Here's the
result, in the og3d viewer:
https://glenn.pulpitrock.net/DRG_163/Models/integration/#model=integration.3mf
The left pane has a list of the individual named meshes from the
integration.3mf file. (click on the gear, and turn on 'Show Edges' for a
better view)
Glenn
On 9/3/2026 2:19 AM, Thomas Richter wrote:
> You can rename the model parts, even though it's somewhat tedious. But for me it works:
>
> - rename the .3mf to .zip (or simply append a .zip)
> - unzip the zip
> - go into the folder 3D and open the file `3dmodel.model` with a text editor
> - search for "OpenSCAD Model" and modify the `name` attributes in the `<object id="2" name="OpenSCAD Model ...` XML tags to whatever you want to name the parts
> - zip the folder again and rename it to .3mf
>
> ATTENTION: On a Mac you need to delete the `.DS_Store` and other system folders. Otherwise the slicers deny the file to be corrupt. This can be achieved by zipping the folder in the Terminal. Run the following code INSIDE the root folder of the unzipped model:
>
> ```console
> zip -r ../renamed-parts-model.3mf * -x "*.DS_Store" -x "__MACOSX*"
> ```
>
> Best,
> Thomas
>
>
>> Yes, the original use case for lazy union was ill-considered, but there are still other reasons for retaining it. Particularly, if one (well, I) wants to model an assembly of discrete parts and save it as a multi-mesh .3mf. OpenSCAD will currently save such, owing to LU, but it doesn't provide the capability to name the individual meshes in the 3mf export.
>> It's not all just about 3D printing...
>> On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
>>> There are no really good answers.
>>>
>>> "Lazy union" shows up in most of the answers. However, LU as it is currently designed and implemented is *not* a good answer... it just happens to sort of accidentally produce useful results. It was designed as an optimization, and one of its key problems is that it produces results that aren't compatible with "ordinary" operation. You should assume that it will not continue to exist in its current form and that any workflow based on it will need changes when something better comes along. (This is why it is classified as "experimental".)
>>>
>>> I would do something like Adam says, with a wrapper module that selectively generates each color, and a shell script that runs OpenSCAD multiple times to generate individual per-color files.
>>>
>>> It looks like colorscad is a shell script that automates most of the process.
>>>
>>> The good news is that I just ordered an INDX kit for my Core ONE+, and so my personal incentive to make something better happen is bumping way up...
>>>
>>>
>>> _______________________________________________
>>> 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
L
larry
Thu, Sep 3, 2026 9:28 PM
On Thu, 2026-09-03 at 10:19 +0200, Thomas Richter via Discuss wrote:
You can rename the model parts, even though it's somewhat tedious.
But for me it works:
- rename the .3mf to .zip (or simply append a .zip)
- unzip the zip
I use7zip, but it's named 7z..
I find it easier to do this in a terminal:
Put the 3mf into a folder.
cd into that folder.
ls <tab>
replace the ls with 7z x <tab>
Done.
- go into the folder 3D and open the file
3dmodel.model with a text
editor
- search for "OpenSCAD Model" and modify the
name attributes in the
<object id="2" name="OpenSCAD Model ... XML tags to whatever you
want to name the parts
- zip the folder again and rename it to .3mf
ATTENTION: On a Mac you need to delete the .DS_Store and other
system folders. Otherwise the slicers deny the file to be corrupt.
This can be achieved by zipping the folder in the Terminal. Run the
following code INSIDE the root folder of the unzipped model:
zip -r ../renamed-parts-model.3mf * -x "*.DS_Store" -x "__MACOSX*"
Best,
Thomas
Yes, the original use case for lazy union was ill-considered, but
there are still other reasons for retaining it. Particularly, if
one (well, I) wants to model an assembly of discrete parts and
save it as a multi-mesh .3mf. OpenSCAD will currently save such,
owing to LU, but it doesn't provide the capability to name the
individual meshes in the 3mf export.
It's not all just about 3D printing...
On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
There are no really good answers.
"Lazy union" shows up in most of the answers. However, LU as it
is currently designed and implemented is not a good answer...
it just happens to sort of accidentally produce useful results.
It was designed as an optimization, and one of its key problems
is that it produces results that aren't compatible with
"ordinary" operation. You should assume that it will not
continue to exist in its current form and that any workflow based
on it will need changes when something better comes along. (This
is why it is classified as "experimental".)
I would do something like Adam says, with a wrapper module that
selectively generates each color, and a shell script that runs
OpenSCAD multiple times to generate individual per-color files.
It looks like colorscad is a shell script that automates most of
the process.
The good news is that I just ordered an INDX kit for my Core
ONE+, and so my personal incentive to make something better
happen is bumping way up...
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Thu, 2026-09-03 at 10:19 +0200, Thomas Richter via Discuss wrote:
> You can rename the model parts, even though it's somewhat tedious.
> But for me it works:
>
> - rename the .3mf to .zip (or simply append a .zip)
> - unzip the zip
I use7zip, but it's named 7z..
I find it easier to do this in a terminal:
Put the 3mf into a folder.
cd into that folder.
ls <tab>
replace the ls with 7z x <tab>
Done.
> - go into the folder 3D and open the file `3dmodel.model` with a text
> editor
> - search for "OpenSCAD Model" and modify the `name` attributes in the
> `<object id="2" name="OpenSCAD Model ...` XML tags to whatever you
> want to name the parts
> - zip the folder again and rename it to .3mf
>
> ATTENTION: On a Mac you need to delete the `.DS_Store` and other
> system folders. Otherwise the slicers deny the file to be corrupt.
> This can be achieved by zipping the folder in the Terminal. Run the
> following code INSIDE the root folder of the unzipped model:
>
> ```console
> zip -r ../renamed-parts-model.3mf * -x "*.DS_Store" -x "__MACOSX*"
> ```
>
> Best,
> Thomas
>
>
> > Yes, the original use case for lazy union was ill-considered, but
> > there are still other reasons for retaining it. Particularly, if
> > one (well, I) wants to model an assembly of discrete parts and
> > save it as a multi-mesh .3mf. OpenSCAD will currently save such,
> > owing to LU, but it doesn't provide the capability to name the
> > individual meshes in the 3mf export.
> > It's not all just about 3D printing...
> > On 9/1/2026 8:39 PM, Jordan Brown via Discuss wrote:
> > > There are no really good answers.
> > >
> > > "Lazy union" shows up in most of the answers. However, LU as it
> > > is currently designed and implemented is *not* a good answer...
> > > it just happens to sort of accidentally produce useful results.
> > > It was designed as an optimization, and one of its key problems
> > > is that it produces results that aren't compatible with
> > > "ordinary" operation. You should assume that it will not
> > > continue to exist in its current form and that any workflow based
> > > on it will need changes when something better comes along. (This
> > > is why it is classified as "experimental".)
> > >
> > > I would do something like Adam says, with a wrapper module that
> > > selectively generates each color, and a shell script that runs
> > > OpenSCAD multiple times to generate individual per-color files.
> > >
> > > It looks like colorscad is a shell script that automates most of
> > > the process.
> > >
> > > The good news is that I just ordered an INDX kit for my Core
> > > ONE+, and so my personal incentive to make something better
> > > happen is bumping way up...
> > >
> > >
> > > _______________________________________________
> > > 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
>
