volumetric color
So, to start to answer my own questions and move some goalposts (maybe)...
How do you think this improves on colorscad?
Colorscad says "Let's avoid weird geometry such as overlapping color volumes... Avoid using multiple colors in an intersection() or difference(), if unavoidable then just wrap it in a color() statement."
So that's obvious.
You made a number of choices regarding what union/difference/intersection mean, but are those useful and efficient in creating actual shapes versus i.e. BOSL2's coloring?
Let's say I design a really cool eye module made of several different colored non-overlapping meshes. I then want to place it overlapping an arbitrary mesh M. With volumetric that's just a union, but I must place my eye first. Without, it's a union with the eye and the difference of M minus the eye... NO! because the difference-created faces gain the eye colors, colorscad doesn't work.
I think this can only be backward-compatible by having color take an option meaning volumetric and having union, intersection, etc use the new behaviour when any child is volumetric colored; Or have some global setting to say "color is now volumetric". Or can they coexist!?
I think the usual process in Blender etc is to build a mesh and then color faces of it, because it's more for computer graphics. If I made i.e. a flexi-dragon that way, I'd still have the problem of making it printable; either there's some foolproof limited algorithm (its volume is X color; colored faces are extruded Y deep) or you must then break it into separate meshes manually?
But that makes me think they can't simply coexist and thus there should be a flag that switches the meaning globally. Actually, especially with geometry literals, it must happen before evaluation begins, so I think that means new syntax happening at parse time. Or... they can coexist, but if any time an operation has something with volumetric color, face color becomes undefined.
OpenSCAD is going to have to maintain a map of volumetric color to mesh everywhere a mesh is currently returned, wouldn't it? And what was an i.e. intersection of two meshes is now NxN meshes, just like your POC shows.
- Cory
Sorry, I answered my own questions, but took too long and then my email program ate it. I'll try to write it all again later.
My "real-world" example was an eye made of many materials and attaching it to another object. With volumetric color, all you must do is union it, with it being the first entry and the things you want to attach/embed it into being the second item. Without, you must maintain separate entries for each volumetric color on both sides manually. For simple functional things (like I make) it didn't seem useful, colorscad easy enough, but the first time you would try to operate on multiple things with multiple colors... yuck.
You could have an option to automatically "volumetrically-colorize" any shape with face coloring.
Backward-compatibility seems feasible (the operations will know if any child has volumetric color; otherwise preserve existing behaviour).
- Ciry
On December 24, 2025 12:28:45 AM PST, Jordan Brown via Discuss discuss@lists.openscad.org wrote:
How do you think this improves on colorscad?
I haven’t used colorscad; I’ve only just now read its README. Looking at it, it looks like it’s actually almost exactly the stuff I said you could wrap around this implementation to make it actually useful.
But it doesn’t do the stuff that I consider truly interesting. Consider this paragraph from its README:
Let's avoid weird geometry such as overlapping color volumes... Avoid using multiple colors in an intersection() or difference(), if unavoidable then just wrap it in a color() statement.
If you’re willing to live with those restrictions, well, OK, but it sure seems like the example that I gave would be much harder to build if you have to live within them. I want something where color (“red”) cube(10); color(“blue”) sphere(10); does something sensible and predictable, without me having to do the work to avoid the overlap. Similarly, I want to be able to take a multicolor object and cut it in half with a difference or intersection and have it just work. (Which I suspect it will, with colorscad, but the documentation isn’t encouraging.)
As an exercise, you could demonstrate creating my sample model using colorscad’s restrictions; it would be interesting to see the comparison. (Remember that “my sample model” is only the stuff inside the “main” module; the rest is infrastructure.)
You made a number of choices regarding what union/difference/intersection mean, but are those useful and efficient in creating actual shapes versus i.e. BOSL2's coloring?
I haven’t noticed similar support in BOSL2, but I haven’t looked. It wouldn’t surprise me if they had something similar, because what I did is a lot like what they do with their diff() operator.
But that would only make my point, which is that it is possible to define volumetric color.
Are the definitions I picked useful? I have no practical experience with them, since I don’t have a multicolor printer. However, since they’re a superset of the capabilities of colorscad’s design capabilities - if you avoid overlaps, it’ll generate the same results that colorscad produces - they’re at least as useful as it is. (Again noting that it does the automation that wraps around this geometry processing to step through the colors, which wasn’t the point of this exercise.)
I’ve been thinking about the definitions on and off for a long time. Difference is easy; the colors of the first child must remain unchanged as you cut away parts of it. Intersection and the overlapping part of union, which are in a sense the same thing, kind of need to be either first-wins or last-wins, and the two strategies seems equivalent, so I picked first-wins because that’s what difference needs. Hull and the others need some answer, but I doubt that what the answer is matters.
Are they efficient? First, I don’t care. Getting a useful and understandable result is the critical piece; a scheme that is ten times faster and requires the model to be ten times as complicated (or even twice as complicated) is in my mind a losing proposition. Second… as implemented, absolutely not. There’s at least a couple of optimizations that could be made even in an OpenSCAD-language implementation, and there’s several more that can be made if you can work directly with the CSG tree. (Geometry values from PR#4478 would help there.) Third, I expect that a multicolor scheme is always going to be slower than a single-color scheme, because there’s just more geometry processing to do.
On 12/24/25 16:18, gene heskett via Discuss wrote:
I use .3mf exclusively unless the slicer objects, but have not been
made aware of that. Where can I find this documentation so I can
understand what is out there?
Thank you.
If you look at the specification example
https://github.com/3MFConsortium/spec_core/blob/master/3MF%20Core%20Specification.md#appendix-b2-3mf-metadata-example,
you can see that it defines a basematerials with id=1, and references
that in the object with id=2 using pid="1", and the object contains a
mesh. From chapter 4, it said that the pid attribute is for "Reference
to the property group element with the matching id attribute value (e.g.
<basematerials>). It is REQUIRED if pindex is specified.". You can also
add properties per triangle (4.1.4.1). The materials extensions
(https://github.com/3MFConsortium/spec_materials/blob/master/3MF%20Materials%20Extension.md)
allows you to specify more complex properties, such as interpolation,
coordinates, display properties, etc. But i think the core spec is
enough for simple volumetric color/material.
I feel like the best way would be to have a new modifier, and not to mix
things.
On 12/24/25 18:34, Cory Cross via Discuss wrote:
Sorry, I answered my own questions, but took too long and then my
email program ate it. I'll try to write it all again later.
My "real-world" example was an eye made of many materials and
attaching it to another object. With volumetric color, all you must do
is union it, with it being the first entry and the things you want to
attach/embed it into being the second item. Without, you must maintain
separate entries for each volumetric color on both sides manually. For
simple functional things (like I make) it didn't seem useful,
colorscad easy enough, but the first time you would try to operate on
multiple things with multiple colors... yuck.
You could have an option to automatically "volumetrically-colorize"
any shape with face coloring.
Backward-compatibility seems feasible (the operations will know if any
child has volumetric color; otherwise preserve existing behaviour).
- Ciry
On December 24, 2025 12:28:45 AM PST, Jordan Brown via Discuss
discuss@lists.openscad.org wrote:
How do you think this improves on colorscad?
I haven’t used colorscad; I’ve only just now read its README.
Looking at it, it looks like it’s actually almost exactly the
stuff I said you could wrap around this implementation to make it
actually useful.
But it doesn’t do the stuff that I consider truly interesting.
Consider this paragraph from its README:
Let's avoid weird geometry such as overlapping color
volumes... Avoid using multiple colors in an
|intersection()|or|difference()|, if unavoidable then just
wrap it in a|color()| statement.
If you’re willing to live with those restrictions, well, OK, but
it sure seems like the example that I gave would be much harder to
build if you have to live within them. I want something where
color (“red”) cube(10); color(“blue”) sphere(10); does something
sensible and predictable, without me having to do the work to
avoid the overlap. Similarly, I want to be able to take a
multicolor object and cut it in half with a difference or
intersection and have it just work. (Which I suspect it will, with
colorscad, but the documentation isn’t encouraging.)
As an exercise, you could demonstrate creating my sample model
using colorscad’s restrictions; it would be interesting to see the
comparison. (Remember that “my sample model” is only the stuff
inside the “main” module; the rest is infrastructure.)
You made a number of choices regarding what
union/difference/intersection mean, but are those useful and
efficient in creating actual shapes versus i.e. BOSL2's coloring?
I haven’t noticed similar support in BOSL2, but I haven’t looked.
It wouldn’t surprise me if they had something similar, because
what I did is a lot like what they do with their diff() operator.
But that would only make my point, which is that it *is* possible
to define volumetric color.
Are the definitions I picked useful? I have no practical
experience with them, since I don’t have a multicolor printer.
However, since they’re a superset of the capabilities of
colorscad’s design capabilities - if you avoid overlaps, it’ll
generate the same results that colorscad produces - they’re at
least as useful as it is. (Again noting that it does the
automation that wraps around this geometry processing to step
through the colors, which wasn’t the point of this exercise.)
I’ve been thinking about the definitions on and off for a long
time. Difference is easy; the colors of the first child must
remain unchanged as you cut away parts of it. Intersection and the
overlapping part of union, which are in a sense the same thing,
kind of need to be either first-wins or last-wins, and the two
strategies seems equivalent, so I picked first-wins because that’s
what difference needs. Hull and the others need *some* answer, but
I doubt that what the answer is matters.
Are they efficient? First, I don’t care. Getting a useful and
understandable result is the critical piece; a scheme that is ten
times faster and requires the model to be ten times as complicated
(or even twice as complicated) is in my mind a losing proposition.
Second… as implemented, absolutely not. There’s at least a couple
of optimizations that could be made even in an OpenSCAD-language
implementation, and there’s several more that can be made if you
can work directly with the CSG tree. (Geometry values from PR#4478
would help there.) Third, I expect that a multicolor scheme is
always going to be slower than a single-color scheme, because
there’s just more geometry processing to do.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
On 12/24/25 06:56, pca006132 via Discuss wrote:
On 12/24/25 16:18, gene heskett via Discuss wrote:
I use .3mf exclusively unless the slicer objects, but have not been
made aware of that. Where can I find this documentation so I can
understand what is out there?
Thank you.
If you look at the specification example
https://github.com/3MFConsortium/spec_core/blob/master/3MF%20Core%20Specification.md#appendix-b2-3mf-metadata-example,
you can see that it defines a basematerials with id=1, and references
that in the object with id=2 using pid="1", and the object contains a
mesh. From chapter 4, it said that the pid attribute is for "Reference
to the property group element with the matching id attribute value
(e.g. <basematerials>). It is REQUIRED if pindex is specified.". You
can also add properties per triangle (4.1.4.1). The materials
extensions
(https://github.com/3MFConsortium/spec_materials/blob/master/3MF%20Materials%20Extension.md)
allows you to specify more complex properties, such as interpolation,
coordinates, display properties, etc. But i think the core spec is
enough for simple volumetric color/material.
Just reading the disclaimer would prevent me from touching that with a
30 ft fiberglass pole. While it is probably do-able in dot mixing
formats such as a color paper printer where the exact color of the inks
is known to a fraction of a % for all inks, I don't see it as
practically applicable to a 3d printer, because it would require a
mixing device operating at lay temp to blend 2 or more of the
complimentary colors to blend to the desired color with 2 or more
filaments being fed to the nozzle, each at the flow rate desired. Just
the complexity of that isn't suitable for a mailing list.
What I had more in mind was for the plastic maker to supply an RGBA
table, available using current RF-ID tech for each spool mounted. That
would restrict the available choices to what was loaded. But could be
done in 60 days or less of coding for a POC. Hundreds of times more usable.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
Gene:
I have not read the spec, but I believe that when a multi-color 3D model
file is loaded into a slicer, the operator of the slicer gets to assign
the model colors to the available filaments. They can assign a green
from a model to a green colored filament, but they could just as easily
assign it to a red colored filament. Mixing devices are not required.
Jon
On 12/24/2025 8:18 AM, gene heskett via Discuss wrote:
On 12/24/25 06:56, pca006132 via Discuss wrote:
On 12/24/25 16:18, gene heskett via Discuss wrote:
I use .3mf exclusively unless the slicer objects, but have not been
made aware of that. Where can I find this documentation so I can
understand what is out there?
Thank you.
If you look at the specification example
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_3MFConsortium_spec-5Fcore_blob_master_3MF-2520Core-2520Specification.md-23appendix-2Db2-2D3mf-2Dmetadata-2Dexample&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=pIZg2czpDjuvuPC-XsRq8QI3FCn_RXY-AQy8oXHVWSnFwZudr4mhxqINwA2g1BOT&s=0pp9aMmd17NFFNK4mQ6jRdpH8CsrrD7EKbp-oVGh5L0&e=,
you can see that it defines a basematerials with id=1, and references
that in the object with id=2 using pid="1", and the object contains a
mesh. From chapter 4, it said that the pid attribute is for
"Reference to the property group element with the matching id
attribute value (e.g. <basematerials>). It is REQUIRED if pindex is
specified.". You can also add properties per triangle (4.1.4.1). The
materials extensions
(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_3MFConsortium_spec-5Fmaterials_blob_master_3MF-2520Materials-2520Extension.md&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=pIZg2czpDjuvuPC-XsRq8QI3FCn_RXY-AQy8oXHVWSnFwZudr4mhxqINwA2g1BOT&s=ifnaGFisJXbJIoC9oXR4OqqlSQsD0kS-pBQ63JBiZLE&e=)
allows you to specify more complex properties, such as interpolation,
coordinates, display properties, etc. But i think the core spec is
enough for simple volumetric color/material.
Just reading the disclaimer would prevent me from touching that with a
30 ft fiberglass pole. While it is probably do-able in dot mixing
formats such as a color paper printer where the exact color of the
inks is known to a fraction of a % for all inks, I don't see it as
practically applicable to a 3d printer, because it would require a
mixing device operating at lay temp to blend 2 or more of the
complimentary colors to blend to the desired color with 2 or more
filaments being fed to the nozzle, each at the flow rate desired. Just
the complexity of that isn't suitable for a mailing list.
What I had more in mind was for the plastic maker to supply an RGBA
table, available using current RF-ID tech for each spool mounted. That
would restrict the available choices to what was loaded. But could be
done in 60 days or less of coding for a POC. Hundreds of times more
usable.
Cheers, Gene Heskett, CET.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
On 12/24/25 08:52, Jon Bondy wrote:
Gene:
I have not read the spec, but I believe that when a multi-color 3D
model file is loaded into a slicer, the operator of the slicer gets to
assign the model colors to the available filaments. They can assign a
green from a model to a green colored filament, but they could just as
easily assign it to a red colored filament. Mixing devices are not
required.
Correct, Jon but what if the desired color isn't available? That .3mf
spec as I read it, would only apply to an inkjet printer. You'd have to
bend things beyond recognition to apply it to a printer incapable of
blending to get the desired color. So if I buy something like a box
turtle, it will be for mounting a 2nd spool of the same color to
automatically continue a print that has used up the current spool in
use. Most of what I've done would be continued when the existing spool
was used up. With the Soval sv08 max I could do a part that uses half a
spool per part pair, 8 up without baby sitting it to feed a new spool on
the fly, my current situation.
Jon
On 12/24/2025 8:18 AM, gene heskett via Discuss wrote:
On 12/24/25 06:56, pca006132 via Discuss wrote:
On 12/24/25 16:18, gene heskett via Discuss wrote:
I use .3mf exclusively unless the slicer objects, but have not been
made aware of that. Where can I find this documentation so I can
understand what is out there?
Thank you.
If you look at the specification example
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_3MFConsortium_spec-5Fcore_blob_master_3MF-2520Core-2520Specification.md-23appendix-2Db2-2D3mf-2Dmetadata-2Dexample&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=pIZg2czpDjuvuPC-XsRq8QI3FCn_RXY-AQy8oXHVWSnFwZudr4mhxqINwA2g1BOT&s=0pp9aMmd17NFFNK4mQ6jRdpH8CsrrD7EKbp-oVGh5L0&e=,
you can see that it defines a basematerials with id=1, and
references that in the object with id=2 using pid="1", and the
object contains a mesh. From chapter 4, it said that the pid
attribute is for "Reference to the property group element with the
matching id attribute value (e.g. <basematerials>). It is REQUIRED
if pindex is specified.". You can also add properties per triangle
(4.1.4.1). The materials extensions
(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_3MFConsortium_spec-5Fmaterials_blob_master_3MF-2520Materials-2520Extension.md&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=pIZg2czpDjuvuPC-XsRq8QI3FCn_RXY-AQy8oXHVWSnFwZudr4mhxqINwA2g1BOT&s=ifnaGFisJXbJIoC9oXR4OqqlSQsD0kS-pBQ63JBiZLE&e=)
allows you to specify more complex properties, such as
interpolation, coordinates, display properties, etc. But i think the
core spec is enough for simple volumetric color/material.
Just reading the disclaimer would prevent me from touching that with
a 30 ft fiberglass pole. While it is probably do-able in dot mixing
formats such as a color paper printer where the exact color of the
inks is known to a fraction of a % for all inks, I don't see it as
practically applicable to a 3d printer, because it would require a
mixing device operating at lay temp to blend 2 or more of the
complimentary colors to blend to the desired color with 2 or more
filaments being fed to the nozzle, each at the flow rate desired.
Just the complexity of that isn't suitable for a mailing list.
What I had more in mind was for the plastic maker to supply an RGBA
table, available using current RF-ID tech for each spool mounted.
That would restrict the available choices to what was loaded. But
could be done in 60 days or less of coding for a POC. Hundreds of
times more usable.
Cheers, Gene Heskett, CET.
Cheers, Gene Heskett, CET.
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.
The file contains all the information you want, but it does not mean
that you have to follow the information. It is designed to include
information useful for any manufacturing purposes, but it does not mean
that each manufacturing method has to support all features. And I think
slicers ignore RGB for slicing, it will just ask you to assign a
material for that color, probably.
Also, I don't think there is anything weird with their disclaimer. How
can they be responsible for any damage caused by an implementation of
the spec? This is a format specification, not about how you should
implement your slicer to be complaint to this. And even for compliant,
it is really just about reading the file, your print does not have to
adhere to the material specification because it is impossible to do so.
On 12/24/25 22:28, gene heskett via Discuss wrote:
On 12/24/25 08:52, Jon Bondy wrote:
Gene:
I have not read the spec, but I believe that when a multi-color 3D
model file is loaded into a slicer, the operator of the slicer gets
to assign the model colors to the available filaments. They can
assign a green from a model to a green colored filament, but they
could just as easily assign it to a red colored filament. Mixing
devices are not required.
Correct, Jon but what if the desired color isn't available? That .3mf
spec as I read it, would only apply to an inkjet printer. You'd have
to bend things beyond recognition to apply it to a printer incapable
of blending to get the desired color. So if I buy something like a
box turtle, it will be for mounting a 2nd spool of the same color to
automatically continue a print that has used up the current spool in
use. Most of what I've done would be continued when the existing spool
was used up. With the Soval sv08 max I could do a part that uses half
a spool per part pair, 8 up without baby sitting it to feed a new
spool on the fly, my current situation.Jon
On 12/24/2025 8:18 AM, gene heskett via Discuss wrote:
On 12/24/25 06:56, pca006132 via Discuss wrote:
On 12/24/25 16:18, gene heskett via Discuss wrote:
I use .3mf exclusively unless the slicer objects, but have not
been made aware of that. Where can I find this documentation so I
can understand what is out there?
Thank you.If you look at the specification example
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_3MFConsortium_spec-5Fcore_blob_master_3MF-2520Core-2520Specification.md-23appendix-2Db2-2D3mf-2Dmetadata-2Dexample&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=pIZg2czpDjuvuPC-XsRq8QI3FCn_RXY-AQy8oXHVWSnFwZudr4mhxqINwA2g1BOT&s=0pp9aMmd17NFFNK4mQ6jRdpH8CsrrD7EKbp-oVGh5L0&e=,
you can see that it defines a basematerials with id=1, and
references that in the object with id=2 using pid="1", and the
object contains a mesh. From chapter 4, it said that the pid
attribute is for "Reference to the property group element with the
matching id attribute value (e.g. <basematerials>). It is REQUIRED
if pindex is specified.". You can also add properties per triangle
(4.1.4.1). The materials extensions
(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_3MFConsortium_spec-5Fmaterials_blob_master_3MF-2520Materials-2520Extension.md&d=DwIGaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=pIZg2czpDjuvuPC-XsRq8QI3FCn_RXY-AQy8oXHVWSnFwZudr4mhxqINwA2g1BOT&s=ifnaGFisJXbJIoC9oXR4OqqlSQsD0kS-pBQ63JBiZLE&e=)
allows you to specify more complex properties, such as
interpolation, coordinates, display properties, etc. But i think
the core spec is enough for simple volumetric color/material.
Just reading the disclaimer would prevent me from touching that with
a 30 ft fiberglass pole. While it is probably do-able in dot mixing
formats such as a color paper printer where the exact color of the
inks is known to a fraction of a % for all inks, I don't see it as
practically applicable to a 3d printer, because it would require a
mixing device operating at lay temp to blend 2 or more of the
complimentary colors to blend to the desired color with 2 or more
filaments being fed to the nozzle, each at the flow rate desired.
Just the complexity of that isn't suitable for a mailing list.What I had more in mind was for the plastic maker to supply an RGBA
table, available using current RF-ID tech for each spool mounted.
That would restrict the available choices to what was loaded. But
could be done in 60 days or less of coding for a POC. Hundreds of
times more usable.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
.Cheers, Gene Heskett, CET.
Cheers, Gene Heskett, CET.
but the first time you would try to operate on multiple things with multiple colors... yuck.
Yeah, that was what my intuition said.
Backward-compatibility seems feasible
Yes, any of a couple of ways. And there’s a question of what preview should do with volumetric color; my initial experiments years ago floundered on the fact that preview really doesn’t like coincident faces and this processing generates a lot of faces, many of them coincident.
I haven’t thought too much about the language binding, about how you would say you want volumetric color. When I first played with this years ago, it was after somebody told me not to document the existing color behavior because it was kind of an accident and maybe not the right behavior. One of my initial thoughts would be to just cut over, accepting the short term pain to get the long term simplicity. However, (a) there are a lot of people relying, for visualization and other non-3DP purposes, on the current behavior, and (b) non-3DP applications like video games probably want face coloring, so reluctantly I wouldn’t recommend that choice today.
They could be a second operator - “part”, maybe, to encompass color, material, and maybe other similar applications. There could be an option on color(). There could be a $ variable that you could set at the top level. (I see TP cringing.)
Right now I think a general purpose part() might be best, but since I come up with at least four applications for it, care would be required to ensure that it covers all of them without unduly burdening any of them.
Those four applications are:
Color
Material
“Modifier” shapes that enclose other shapes and do things like change print parameters. (Maybe transparency is one of these, or maybe it’s a color or material.)
Multiple result-shapes in one file. I often group related models together, for preview and file management reasons, but then separate them for printing. This might also tie into semi automatic mechanisms for splitting shapes larger than your print bed.
I have been working on openscad with python for a few years now.
I use Jupyter Lab to write my python code and it is working well for me.
But simply writing openscad code in python is not very useful. You need to
learn first to work with points list instead of openscad primitives.
I have written various examples for this approach and here is a small video
for a starting point in case you are interested:
https://youtu.be/kBshJ0CQCS0
On Wed, 24 Dec 2025 at 09:06, Lee DeRaud via Discuss <
discuss@lists.openscad.org> wrote:
The whole "just do it in python" thing seems to be turning into a meme. 😊
There appear to be multiple approaches to extending OS with python...
Any suggestions for where best to start, assuming someone (1) decently
familiar with OS,
(2) relative beginner with python, and (3) working in a Windows
environment (if that matters)?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org