JB
Jordan Brown
Sat, Jan 3, 2026 8:52 PM
On 1/3/2026 12:01 PM, Cory Cross via Discuss wrote:
But also, since faces can get volumetric color,
Huh?
I think it ends up with a "don't cross the streams" rule. Face color is
never transcribed into fill color, and fill color is never transcribed
into face color.
With what I use, I simply map every RGB to material. Sometimes I just use red and blue, but they're green and white. I treat RGB as an index to material that just happens to show up as a visual color in the viewport.
You can do that, but I think it's a hack.
You should be able to represent red PLA and red TPU and have them be
distinct, and both red.
If we add part, we either need to augment color or allow part to apply to faces.
Maybe. Does material (PLA, TPU, et cetera) ever apply to a face?
Another reason to reference by name is libraries, like BOSL2, are already built around taking a single value as a color. They might work with an object, but they definitely work with strings. So if we add another character besides # to the color namespace, we minimize the code needed for libraries to update. This is stupid, probably, but color("+m+redtpu") applies the redtpu "part" to the volume of children, color("+f+redtpu") to faces, and, now you'll see why I set it to "m" before, color("+v+redtpu") for vertices!
And why vertices? As Emmett wrote, computer graphics primarily use vertex coloring and he should not have even added face coloring in 3mf spec. So if we think OpenSCAD should ever be used for computer graphics, then it probably should support vertex coloring (see tetrahedron puzzle example at manifoldcad.org). But also you could have a printer with dyes so you literally could have the same material and color gradient interpreted. Or, heck, why not a blend of two different materials!
Indeed, there are good arguments for supporting some sort of vertex
coloring. But since (I think) vertex coloring is a superset of face
coloring, and we haven't exposed any independent way to do face
coloring, we're not precluding vertex coloring.
But even then, I think I'd offer face coloring, just because it's
simpler. I think that the relationship between face coloring and
vertex coloring is that face coloring is vertex coloring where all of
the vertexes on that face have the same color - so, think of it as
cube(n) being a shortcut for cube([n,n,n]).
And then there's UV mapping.
On 1/3/2026 12:01 PM, Cory Cross via Discuss wrote:
> But also, since faces can get volumetric color,
Huh?
I think it ends up with a "don't cross the streams" rule. Face color is
never transcribed into fill color, and fill color is never transcribed
into face color.
> With what I use, I simply map every RGB to material. Sometimes I just use red and blue, but they're green and white. I treat RGB as an index to material that just happens to show up as a visual color in the viewport.
You can do that, but I think it's a hack.
You should be able to represent red PLA and red TPU and have them be
distinct, and both red.
> If we add `part`, we either need to augment `color` or allow `part` to apply to faces.
Maybe. Does material (PLA, TPU, et cetera) ever apply to a face?
> Another reason to reference by name is libraries, like BOSL2, are already built around taking a single value as a color. They might work with an object, but they definitely work with strings. So if we add another character besides # to the color namespace, we minimize the code needed for libraries to update. This is stupid, probably, but color("+m+redtpu") applies the redtpu "part" to the volume of children, color("+f+redtpu") to faces, and, now you'll see why I set it to "m" before, color("+v+redtpu") for vertices!
Um.... eww.
> And why vertices? As Emmett wrote, computer graphics primarily use vertex coloring and he should not have even added face coloring in 3mf spec. So if we think OpenSCAD should ever be used for computer graphics, then it probably should support vertex coloring (see tetrahedron puzzle example at manifoldcad.org). But also you could have a printer with dyes so you literally could have the same material and color gradient interpreted. Or, heck, why not a blend of two different materials!
Indeed, there are good arguments for supporting some sort of vertex
coloring. But since (I think) vertex coloring is a superset of face
coloring, and we haven't exposed any independent way to do face
coloring, we're not precluding vertex coloring.
But even then, I think I'd offer face coloring, just because it's
simpler. I *think* that the relationship between face coloring and
vertex coloring is that face coloring is vertex coloring where all of
the vertexes on that face have the same color - so, think of it as
cube(n) being a shortcut for cube([n,n,n]).
And then there's UV mapping.
CC
Cory Cross
Sat, Jan 3, 2026 9:20 PM
On 1/3/26 12:52 PM, Jordan Brown via Discuss wrote:
On 1/3/2026 12:01 PM, Cory Cross via Discuss wrote:
But also, since faces can get volumetric color,
Huh?
I think it ends up with a "don't cross the streams" rule. Face color
is never transcribed into fill color, and fill color is never
transcribed into face color.
First I'm going to quote you:
What is visible in the UI is the face color, if defined, else the
fill color, and if there's no fill color, the default color (yellow).
Preview, for example, can only operate on faces. So uncolored faces get
"fill" color.
Second, when you encode a 3mf, you can apply part to a mesh and a
different part to its faces. There is only one set of "parts" so for
exporting you want to be able to use the same set for both.
With what I use, I simply map every RGB to material. Sometimes I just use red and blue, but they're green and white. I treat RGB as an index to material that just happens to show up as a visual color in the viewport.
You can do that, but I think it's a hack.
You should be able to represent red PLA and red TPU and have them be
distinct, and both red.
Sure, but I'm trying to communicate that when I say "color" I mean it to
encode everything.
If we add part, we either need to augment color or allow part to apply to faces.
Maybe. Does material (PLA, TPU, et cetera) ever apply to a face?
Yes. I can do it in a slicer today.
Another reason to reference by name is libraries, like BOSL2, are already built around taking a single value as a color. They might work with an object, but they definitely work with strings. So if we add another character besides # to the color namespace, we minimize the code needed for libraries to update. This is stupid, probably, but color("+m+redtpu") applies the redtpu "part" to the volume of children, color("+f+redtpu") to faces, and, now you'll see why I set it to "m" before, color("+v+redtpu") for vertices!
Backward-compability is very important. But I think would could drop in
a "material" object (with modifiers for face/fill) instead of a string.
And why vertices? As Emmett wrote, computer graphics primarily use vertex coloring and he should not have even added face coloring in 3mf spec. So if we think OpenSCAD should ever be used for computer graphics, then it probably should support vertex coloring (see tetrahedron puzzle example at manifoldcad.org). But also you could have a printer with dyes so you literally could have the same material and color gradient interpreted. Or, heck, why not a blend of two different materials!
Indeed, there are good arguments for supporting some sort of vertex
coloring. But since (I think) vertex coloring is a superset of face
coloring, and we haven't exposed any independent way to do face
coloring, we're not precluding vertex coloring.
But even then, I think I'd offer face coloring, just because it's
simpler. I think that the relationship between face coloring and
vertex coloring is that face coloring is vertex coloring where all of
the vertexes on that face have the same color - so, think of it as
cube(n) being a shortcut for cube([n,n,n]).
You must duplicate every vertex if using vertex coloring to do face
coloring.
On 1/3/26 12:52 PM, Jordan Brown via Discuss wrote:
> On 1/3/2026 12:01 PM, Cory Cross via Discuss wrote:
>> But also, since faces can get volumetric color,
>
> Huh?
>
> I think it ends up with a "don't cross the streams" rule. Face color
> is never transcribed into fill color, and fill color is never
> transcribed into face color.
First I'm going to quote you:
> What is visible in the UI is the face color, if defined, else the
fill color, and if there's no fill color, the default color (yellow).
Preview, for example, can only operate on faces. So uncolored faces get
"fill" color.
Second, when you encode a 3mf, you can apply part to a mesh and a
different part to its faces. There is only one set of "parts" so for
exporting you want to be able to use the same set for both.
>
>> With what I use, I simply map every RGB to material. Sometimes I just use red and blue, but they're green and white. I treat RGB as an index to material that just happens to show up as a visual color in the viewport.
>
> You can do that, but I think it's a hack.
>
> You should be able to represent red PLA and red TPU and have them be
> distinct, and both red.
Sure, but I'm trying to communicate that when I say "color" I mean it to
encode everything.
>> If we add `part`, we either need to augment `color` or allow `part` to apply to faces.
>
> Maybe. Does material (PLA, TPU, et cetera) ever apply to a face?
Yes. I can do it in a slicer today.
>> Another reason to reference by name is libraries, like BOSL2, are already built around taking a single value as a color. They might work with an object, but they definitely work with strings. So if we add another character besides # to the color namespace, we minimize the code needed for libraries to update. This is stupid, probably, but color("+m+redtpu") applies the redtpu "part" to the volume of children, color("+f+redtpu") to faces, and, now you'll see why I set it to "m" before, color("+v+redtpu") for vertices!
>
> Um.... eww.
Backward-compability is very important. But I think would could drop in
a "material" object (with modifiers for face/fill) instead of a string.
>> And why vertices? As Emmett wrote, computer graphics primarily use vertex coloring and he should not have even added face coloring in 3mf spec. So if we think OpenSCAD should ever be used for computer graphics, then it probably should support vertex coloring (see tetrahedron puzzle example at manifoldcad.org). But also you could have a printer with dyes so you literally could have the same material and color gradient interpreted. Or, heck, why not a blend of two different materials!
>
> Indeed, there are good arguments for supporting some sort of vertex
> coloring. But since (I think) vertex coloring is a superset of face
> coloring, and we haven't exposed any independent way to do face
> coloring, we're not precluding vertex coloring.
>
> But even then, I think I'd offer face coloring, just because it's
> simpler. I *think* that the relationship between face coloring and
> vertex coloring is that face coloring is vertex coloring where all of
> the vertexes on that face have the same color - so, think of it as
> cube(n) being a shortcut for cube([n,n,n]).
You must duplicate every vertex if using vertex coloring to do face
coloring.
CC
Cory Cross
Sat, Jan 3, 2026 9:53 PM
On 1/3/26 12:26 PM, Jordan Brown via Discuss wrote:
No, because a mesh is just the surface; it isn't the interior.
Meshes are collections of faces. Collections of faces might or might
not bound solids.
Consider the common-English word: a mesh is a piece of fabric, not the
thing that the fabric encloses.
OpenSCAD is CSG and can't represent non-manifold surfaces, so a mesh is
always a bounded solid.
I'm having a hard time wrapping my head around the definitions
you've given. That's not to say that they are wrong, just that they
aren't "clicking" in my head.
I wonder whether it would be helpful to take a lesson from 2D
drawing programs, and consider there to be "face color" and "fill
color", with the possibility that either of those might be "undefined".
That's confusing to me because "fill color" is "face color" in 2d
drawing programs.
That's because you're looking at your 2D drawings from a 3D
perspective, and at your 3D models from a 3D perspective. When you're
looking at a 2D drawing you're able to see both the boundary and the
interior; when you're looking at a 3D object you're only able to see
the boundary.
You need to look at your 2D images from the side. Alternatively, you
need to look at your 3D models from a 4D perspective, but that's harder.
No I don't. I "need" to avoid using confusing terminology which requires
paragraphs to explain and ends with "but that's harder"
Union:
- Face colors are unchanged.
- Fill colors are unchanged, with A winning for overlaps.
- Coincident faces: A wins (because it's an overlap).
What makes this complicated is handling the overlapping cases. You
can eliminate this with the rule I posted, where it's solely defined
with a non-overlapping union() + difference() + intersection().
You only need union plus difference. You don't need the intersection.
The result of unioning A and B is union(A, difference(B,A)).
I believe you had union(difference(A,B), intersect(A,B),
difference(B,A)), with the first two retaining A's color, but when you
add that difference to that intersection you're back to A.
I think it mattered with my suggestion to "promote" volumetric color to
face color, but that was a bad idea. So I agree you just need
non-overlapping union (which is trivial) plus difference.
- Their interior is to opposite sides: both faces continue to exist
separately unless volumetric ("fill") color is the same on both
sides; then they are removed where that condition holds.
That latter is just a special case of the fact that all same-color
(and same-material et cetera) shapes get unioned.
Visually, unions are the same for face coloring and fill coloring.
Except when you both in the same program.
I don't think so. What's a case where they are visibly different?
volume_color("red") union () {
color("green") cube();
sphere();
}
A volumetric color view is only red. A face color view has green and red.
Or, I don't understand what you're trying to say.
- Coincident faces: A wins (because they are existing faces of A).
I don't think that's the best reasoning; faces have no thickness so a
face alone cannot remove another face. Thus coincidence is irrelevant.
If the parts are on opposite sides of the coincident face, that face
remains colored with the color it had in A.
I didn't say it was wrong :)
I believe it's better to combine this with the first statement and
say: Every face comes from some or all of an existing face of either
A or B; face color is preserved from before.
I think that means the same thing that I said.
It does, I hope, but fewer rules and makes more sense to me :).
In this scheme, I think there's an overall rule that if the inputs
have no face colors, the outputs must not have face colors either.
(If the operation can introduce face colors where there were none
before, that will unexpectedly influence downstream operations.)
I think I understand the motivation for writing this, but there's
always a face color, we just call some of them positive or negative
uncolor.
What is the sound of no hands clapping? :-)
I think we end up with the same behavior, but I would say that "has no
color" is not a color, just as undef is not a number. There is no RGB
triple that represents positive-undefined or negative-undefined.
Sure, but there's no RGB triple which represents translucency either :)
In your terminology of vol() and face() I think you're missing that a
shape may have some faces that have colors and others that don't, that
are what you're calling uncolor.
No, that was my point above: uncolor is still a color. It makes the
rules simpler. That's why it's "uncolor" and not "no color" :).
difference() { vol(); face(); } -- all new faces take from the face
color of the removing face, except when it's positive uncolor, then
it gets negative uncolor. If all meshes of a volumetric color are
contained within the right-hand operand, that volumetric color is gone.
In any A-B, if all of A is contained in B, the result is the empty
shape. I don't immediately see how its fill color matters at that point.
A = {{ union() { vol_color("red") cube(); vol_color("blue") sphere(); } }}
B = {{ sphere(); }}
assert(len(A.volumetric_colors()) == 2)
assert(len({{ difference() { A; B; } }}.volumetric_colors() == 1)
A has multiple meshes, at least one for each volumetric color. This
difference will eliminate all meshes which have blue volumetric color.
On 1/3/26 12:26 PM, Jordan Brown via Discuss wrote:
> No, because a mesh is just the surface; it isn't the interior.
>
> Meshes are collections of faces. Collections of faces might or might
> not bound solids.
>
> Consider the common-English word: a mesh is a piece of fabric, not the
> thing that the fabric encloses.
OpenSCAD is CSG and can't represent non-manifold surfaces, so a mesh is
always a bounded solid.
>
>>> I'm having a hard time wrapping my head around the definitions
>>> you've given. That's not to say that they are wrong, just that they
>>> aren't "clicking" in my head.
>>>
>>> I wonder whether it would be helpful to take a lesson from 2D
>>> drawing programs, and consider there to be "face color" and "fill
>>> color", with the possibility that either of those might be "undefined".
>>
>> That's confusing to me because "fill color" *is* "face color" in 2d
>> drawing programs.
>
> That's because you're looking at your 2D drawings from a 3D
> perspective, and at your 3D models from a 3D perspective. When you're
> looking at a 2D drawing you're able to see both the boundary and the
> interior; when you're looking at a 3D object you're only able to see
> the boundary.
>
> You need to look at your 2D images from the side. Alternatively, you
> need to look at your 3D models from a 4D perspective, but that's harder.
No I don't. I "need" to avoid using confusing terminology which requires
paragraphs to explain and ends with "but that's harder"
>>> Union:
>>>
>>> * Face colors are unchanged.
>>> * Fill colors are unchanged, with A winning for overlaps.
>>> * Coincident faces: A wins (because it's an overlap).
>>>
>> What makes this complicated is handling the overlapping cases. You
>> can eliminate this with the rule I posted, where it's solely defined
>> with a non-overlapping union() + difference() + intersection().
>
> You only need union plus difference. You don't need the intersection.
>
> The result of unioning A and B is union(A, difference(B,A)).
>
> I believe you had union(difference(A,B), intersect(A,B),
> difference(B,A)), with the first two retaining A's color, but when you
> add that difference to that intersection you're back to A.
I think it mattered with my suggestion to "promote" volumetric color to
face color, but that was a bad idea. So I agree you just need
non-overlapping union (which is trivial) plus difference.
>> 2. Their interior is to opposite sides: both faces continue to exist
>> separately unless volumetric ("fill") color is the same on both
>> sides; then they are removed where that condition holds.
>
> That latter is just a special case of the fact that all same-color
> (and same-material et cetera) shapes get unioned.
That's a tautology.
>>> Visually, unions are the same for face coloring and fill coloring.
>>>
>> Except when you both in the same program.
>
> I don't think so. What's a case where they are visibly different?
volume_color("red") union () {
color("green") cube();
sphere();
}
A volumetric color view is only red. A face color view has green and red.
Or, I don't understand what you're trying to say.
>>> * Coincident faces: A wins (because they are existing faces of A).
>>>
>> I don't think that's the best reasoning; faces have no thickness so a
>> face alone cannot remove another face. Thus coincidence is irrelevant.
>
> If the parts are on opposite sides of the coincident face, that face
> remains colored with the color it had in A.
I didn't say it was wrong :)
>
>> I believe it's better to combine this with the first statement and
>> say: Every face comes from some or all of an existing face of either
>> A or B; face color is preserved from before.
>
> I think that means the same thing that I said.
It does, I hope, but fewer rules and makes more sense to me :).
>
>>> In this scheme, I think there's an overall rule that if the inputs
>>> have no face colors, the outputs must not have face colors either.
>>> (If the operation can introduce face colors where there were none
>>> before, that will unexpectedly influence downstream operations.)
>>>
>> I think I understand the motivation for writing this, but there's
>> always a face color, we just call some of them positive or negative
>> uncolor.
>
> What is the sound of no hands clapping? :-)
>
> I think we end up with the same behavior, but I would say that "has no
> color" is not a color, just as undef is not a number. There is no RGB
> triple that represents positive-undefined or negative-undefined.
Sure, but there's no RGB triple which represents translucency either :)
> In your terminology of vol() and face() I think you're missing that a
> shape may have some faces that have colors and others that don't, that
> are what you're calling uncolor.
No, that was my point above: uncolor is still a color. It makes the
rules simpler. That's why it's "uncolor" and not "no color" :).
>> difference() { vol(); face(); } -- all new faces take from the face
>> color of the removing face, except when it's positive uncolor, then
>> it gets negative uncolor. If all meshes of a volumetric color are
>> *contained* within the right-hand operand, that volumetric color is gone.
>
> In any A-B, if all of A is contained in B, the result is the empty
> shape. I don't immediately see how its fill color matters at that point.
A = {{ union() { vol_color("red") cube(); vol_color("blue") sphere(); } }}
B = {{ sphere(); }}
assert(len(A.volumetric_colors()) == 2)
assert(len({{ difference() { A; B; } }}.volumetric_colors() == 1)
A has multiple meshes, at least one for each volumetric color. This
difference will eliminate all meshes which have blue volumetric color.
- Cory
JB
Jordan Brown
Sat, Jan 3, 2026 11:20 PM
On 1/3/2026 1:20 PM, Cory Cross via Discuss wrote:
What is visible in the UI is the face color, if defined, else the
fill color, and if there's no fill color, the default color (yellow).
Preview, for example, can only operate on faces. So uncolored faces
get "fill" color.
Anything you see on the screen is just a presentation, and the
implementation that underlies it doubly so. (Remember that word
"display" you kept emphasizing? :-)
The color that's visible on the display in this case is the fill color.
That doesn't make it the face color.
Second, when you encode a 3mf, you can apply part to a mesh and a
different part to its faces. There is only one set of "parts" so for
exporting you want to be able to use the same set for both.
Exports are always going to involve mapping from the OpenSCAD concepts
to the export format concepts. That might involve collapsing some
OpenSCAD concepts down into less-flexible export-format concepts, or
might involve selecting a mapping that doesn't use all of the
flexibility of the export format. OpenSCAD is not a Manifold front end,
nor is it a 3MF front end. It's a tool for designing 3D models, that
can be implemented atop other libraries, and can be exported into other
forms.
You should be able to represent red PLA and red TPU and have them be
distinct, and both red.
Sure, but I'm trying to communicate that when I say "color" I mean it
to encode everything.
And while color and material are closely related and probably handled
similarly, they aren't the same thing.
If we add part, we either need to augment color or allow part
to apply to faces.
Maybe. Does material (PLA, TPU, et cetera) ever apply to a face?
Yes. I can do it in a slicer today.
Can you do it because it makes sense, or because it's the only real way
they have to offer that control?
With the possible exception of the "paint" use case - which PrusaSlicer
doesn't seem to support, don't know about others - I think any
face-coloring for material control is a user interface hack, a mechanism
to let them take a monochromatic model and apply some color to it,
without needing to go back to the (monochromatic) design tool.
Another reason to reference by name is libraries, like BOSL2, are
already built around taking a single value as a color. They might
work with an object, but they definitely work with strings. So if we
add another character besides # to the color namespace, we minimize
the code needed for libraries to update. This is stupid, probably,
but color("+m+redtpu") applies the redtpu "part" to the volume of
children, color("+f+redtpu") to faces, and, now you'll see why I set
it to "m" before, color("+v+redtpu") for vertices!
Backward-compability is very important. But I think would could drop
in a "material" object (with modifiers for face/fill) instead of a
string.
I'm not very concerned about coming up with a scheme that lets an
unmodified library somehow "support" more advanced concepts. The
primary concern needs to be keeping it as simple and understandable as
possible for the user. Libraries will pick up the features when and if
they like. If we add some intricate syntax for the color strings that
lets today's BOSL2 have material controls, and tomorrow's BOSL2 has
direct and obvious material support, we end up having a legacy of the
intricate syntax that's no longer needed.
And if you're on a full-color printer, how do you represent [0.5, 0.7,
0.1] in TPU?
You must duplicate every vertex if using vertex coloring to do face
coloring.
And...?
Current OpenSCAD is face-colored. If we're going to continue to support
that, the underlying implementation needs to fall in line, whatever it
needs to do to do that.
On 1/3/2026 1:20 PM, Cory Cross via Discuss wrote:
> > What is visible in the UI is the face color, if defined, else the
> fill color, and if there's no fill color, the default color (yellow).
>
> Preview, for example, can only operate on faces. So uncolored faces
> get "fill" color.
Anything you see on the screen is just a presentation, and the
implementation that underlies it doubly so. (Remember that word
"display" you kept emphasizing? :-)
The color that's visible on the display in this case is the fill color.
That doesn't make it the face color.
> Second, when you encode a 3mf, you can apply part to a mesh and a
> different part to its faces. There is only one set of "parts" so for
> exporting you want to be able to use the same set for both.
Exports are always going to involve mapping from the OpenSCAD concepts
to the export format concepts. That might involve collapsing some
OpenSCAD concepts down into less-flexible export-format concepts, or
might involve selecting a mapping that doesn't use all of the
flexibility of the export format. OpenSCAD is not a Manifold front end,
nor is it a 3MF front end. It's a tool for designing 3D models, that
can be implemented atop other libraries, and can be exported into other
forms.
>> You should be able to represent red PLA and red TPU and have them be
>> distinct, and both red.
> Sure, but I'm trying to communicate that when I say "color" I mean it
> to encode everything.
And while color and material are closely related and probably handled
similarly, they aren't the same thing.
>>> If we add `part`, we either need to augment `color` or allow `part`
>>> to apply to faces.
>> Maybe. Does material (PLA, TPU, et cetera) ever apply to a face?
> Yes. I can do it in a slicer today.
Can you do it because it makes sense, or because it's the only real way
they have to offer that control?
With the possible exception of the "paint" use case - which PrusaSlicer
doesn't seem to support, don't know about others - I think any
face-coloring for material control is a user interface hack, a mechanism
to let them take a monochromatic model and apply some color to it,
without needing to go back to the (monochromatic) design tool.
>>> Another reason to reference by name is libraries, like BOSL2, are
>>> already built around taking a single value as a color. They might
>>> work with an object, but they definitely work with strings. So if we
>>> add another character besides # to the color namespace, we minimize
>>> the code needed for libraries to update. This is stupid, probably,
>>> but color("+m+redtpu") applies the redtpu "part" to the volume of
>>> children, color("+f+redtpu") to faces, and, now you'll see why I set
>>> it to "m" before, color("+v+redtpu") for vertices!
>> Um.... eww.
> Backward-compability is very important. But I think would could drop
> in a "material" object (with modifiers for face/fill) instead of a
> string.
I'm not very concerned about coming up with a scheme that lets an
unmodified library somehow "support" more advanced concepts. The
primary concern needs to be keeping it as simple and understandable as
possible for the user. Libraries will pick up the features when and if
they like. If we add some intricate syntax for the color strings that
lets today's BOSL2 have material controls, and tomorrow's BOSL2 has
direct and obvious material support, we end up having a legacy of the
intricate syntax that's no longer needed.
And if you're on a full-color printer, how do you represent [0.5, 0.7,
0.1] in TPU?
> You must duplicate every vertex if using vertex coloring to do face
> coloring.
And...?
Current OpenSCAD is face-colored. If we're going to continue to support
that, the underlying implementation needs to fall in line, whatever it
needs to do to do that.
GH
gene heskett
Sat, Jan 3, 2026 11:24 PM
On 1/3/26 15:01, Cory Cross via Discuss wrote:
[...]
On a multi-head printer - note that Prusa is supposed to be introducing
an 8-head version of the Core One+ this year - you might reasonably keep
a number of colors and materials "stock", mounted all the time.
Picking up moisture from the environment . Such housings are worthless w/o
enough heat to keep the filament dry so it doesn't get confused with
Orvilles finest
popcorn in the printhead hotends. I like the multihead idea, and will
probably buy
that kit for my sovol SV08 Max but the cost of PTC heaters to maintain
the on-demand
mounted filaments dry, is not going to happen this week. Until they
realize we need
it and they offer it as part of the package, they'll use that as an
excuse to milk another
$2000 a printer out of us.
And having spent >$1600 trying to make an MK3S work with its $5 hot
end just
because I wanted to use PETG in it, it will be a long time before I buy
another Prusa.
Could not stop the nozzle leaks. Now I make my own hot ends. No leaks,
no clogs.
Does PC like most do PLA, but a lot hotter for PC.
The
more that the slicer and the printer can know about materials and
colors, and the more that we can represent them in the model, the more
that stuff like that can be just "render and print".
I am waiting for that day, but at 91, I feel like I'm running out of
time. Help
make it happen please.
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.
On 1/3/26 15:01, Cory Cross via Discuss wrote:
[...]
On a multi-head printer - note that Prusa is supposed to be introducing
>> an 8-head version of the Core One+ this year - you might reasonably keep
>> a number of colors and materials "stock", mounted all the time.
Picking up moisture from the environment . Such housings are worthless w/o
enough heat to keep the filament dry so it doesn't get confused with
Orvilles finest
popcorn in the printhead hotends. I like the multihead idea, and will
probably buy
that kit for my sovol SV08 Max but the cost of PTC heaters to maintain
the on-demand
mounted filaments dry, is not going to happen this week. Until they
realize we need
it and they offer it as part of the package, they'll use that as an
excuse to milk another
$2000 a printer out of us.
And having spent >$1600 trying to make an MK3S work with its $5 hot
end just
because I wanted to use PETG in it, it will be a long time before I buy
another Prusa.
Could not stop the nozzle leaks. Now I make my own hot ends. No leaks,
no clogs.
Does PC like most do PLA, but a lot hotter for PC.
>> The
>> more that the slicer and the printer can know about materials and
>> colors, and the more that we can represent them in the model, the more
>> that stuff like that can be just "render and print".
I am waiting for that day, but at 91, I feel like I'm running out of
time. Help
make it happen please.
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
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.
JB
Jordan Brown
Sat, Jan 3, 2026 11:34 PM
On 1/3/2026 1:53 PM, Cory Cross via Discuss wrote:
On 1/3/26 12:26 PM, Jordan Brown via Discuss wrote:
No, because a mesh is just the surface; it isn't the interior.
Meshes are collections of faces. Collections of faces might or might
not bound solids.
Consider the common-English word: a mesh is a piece of fabric, not
the thing that the fabric encloses.
OpenSCAD is CSG and can't represent non-manifold surfaces, so a mesh
is always a bounded solid.
First, no. OpenSCAD is perfectly capable of constructing non-manifold
surfaces. polyhedron() will do it all you like. It can't do much with
those surfaces, but it can construct them.
But regardless, "mesh" isn't the right word. A mesh that OpenSCAD
generates may almost always be watertight, but that doesn't mean that
all meshes are, or that OpenSCAD won't eventually learn how to handle
non-watertight meshes.
Visually, unions are the same for face coloring and fill coloring.
Except when you both in the same program.
I don't think so. What's a case where they are visibly different?
volume_color("red") union () {
color("green") cube();
sphere();
}
A volumetric color view is only red. A face color view has green and red.
Or, I don't understand what you're trying to say.
Using only today's color() and union() (no difference, no intersection),
can you tell whether color() does face coloring or fill coloring?
Can you construct a model that will display differently if color() does
face coloring than if it does fill coloring.
In your terminology of vol() and face() I think you're missing that a
shape may have some faces that have colors and others that don't,
that are what you're calling uncolor.
No, that was my point above: uncolor is still a color. It makes the
rules simpler. That's why it's "uncolor" and not "no color" :).
Then what distinction are you drawing between vol() and face(), if they
both have both face and fill colors?
But also note that your rules then need to say "show the face color,
unless it's uncolor, else show the fill color, unless it's uncolor, else
show the default", which is almost the same as "show the face color, if
any, else show the fill color, if any, else show the default".
difference() { vol(); face(); } -- all new faces take from the face
color of the removing face, except when it's positive uncolor, then
it gets negative uncolor. If all meshes of a volumetric color are
contained within the right-hand operand, that volumetric color is
gone.
In any A-B, if all of A is contained in B, the result is the empty
shape. I don't immediately see how its fill color matters at that point.
A = {{ union() { vol_color("red") cube(); vol_color("blue") sphere(); } }}
B = {{ sphere(); }}
assert(len(A.volumetric_colors()) == 2)
assert(len({{ difference() { A; B; } }}.volumetric_colors() == 1)
A has multiple meshes, at least one for each volumetric color. This
difference will eliminate all meshes which have blue volumetric color.
Uh, OK, yes. If you subtract away everything using a particular color,
then that color is no longer used.
Whether that's important depends on whether you think that a color is
some sort of separate object, versus just being an analysis of the
model. A model that has no red components... has no red components.
The fact that it might have had some, if they were not all subtracted
away, is of little interest.
On 1/3/2026 1:53 PM, Cory Cross via Discuss wrote:
> On 1/3/26 12:26 PM, Jordan Brown via Discuss wrote:
>> No, because a mesh is just the surface; it isn't the interior.
>>
>> Meshes are collections of faces. Collections of faces might or might
>> not bound solids.
>>
>> Consider the common-English word: a mesh is a piece of fabric, not
>> the thing that the fabric encloses.
>
> OpenSCAD is CSG and can't represent non-manifold surfaces, so a mesh
> is always a bounded solid.
First, no. OpenSCAD is perfectly capable of constructing non-manifold
surfaces. polyhedron() will do it all you like. It can't do much with
those surfaces, but it can construct them.
But regardless, "mesh" isn't the right word. A mesh *that OpenSCAD
generates* may almost always be watertight, but that doesn't mean that
all meshes are, or that OpenSCAD won't eventually learn how to handle
non-watertight meshes.
>>>> Visually, unions are the same for face coloring and fill coloring.
>>>>
>>> Except when you both in the same program.
>>
>> I don't think so. What's a case where they are visibly different?
>
> volume_color("red") union () {
> color("green") cube();
> sphere();
> }
>
> A volumetric color view is only red. A face color view has green and red.
>
> Or, I don't understand what you're trying to say.
Using only today's color() and union() (no difference, no intersection),
can you tell whether color() does face coloring or fill coloring?
Can you construct a model that will display differently if color() does
face coloring than if it does fill coloring.
>> In your terminology of vol() and face() I think you're missing that a
>> shape may have some faces that have colors and others that don't,
>> that are what you're calling uncolor.
>
> No, that was my point above: uncolor is still a color. It makes the
> rules simpler. That's why it's "uncolor" and not "no color" :).
Then what distinction are you drawing between vol() and face(), if they
both have both face and fill colors?
But also note that your rules then need to say "show the face color,
unless it's uncolor, else show the fill color, unless it's uncolor, else
show the default", which is almost the same as "show the face color, if
any, else show the fill color, if any, else show the default".
>
>>> difference() { vol(); face(); } -- all new faces take from the face
>>> color of the removing face, except when it's positive uncolor, then
>>> it gets negative uncolor. If all meshes of a volumetric color are
>>> *contained* within the right-hand operand, that volumetric color is
>>> gone.
>>
>> In any A-B, if all of A is contained in B, the result is the empty
>> shape. I don't immediately see how its fill color matters at that point.
>
> A = {{ union() { vol_color("red") cube(); vol_color("blue") sphere(); } }}
> B = {{ sphere(); }}
>
> assert(len(A.volumetric_colors()) == 2)
> assert(len({{ difference() { A; B; } }}.volumetric_colors() == 1)
>
> A has multiple meshes, at least one for each volumetric color. This
> difference will eliminate all meshes which have blue volumetric color.
Uh, OK, yes. If you subtract away everything using a particular color,
then that color is no longer used.
Whether that's important depends on whether you think that a color is
some sort of separate object, versus just being an analysis of the
model. A model that has no red components... has no red components.
The fact that it might have had some, if they were not all subtracted
away, is of little interest.
JB
Jordan Brown
Sat, Jan 3, 2026 11:41 PM
On 1/3/2026 3:24 PM, gene heskett via Discuss wrote:
Picking up moisture from the environment . Such housings are
worthless w/o
enough heat to keep the filament dry so it doesn't get confused with
Orvilles finest
popcorn in the printhead hotends.
There are certain advantages to living in SoCal, where humidity is often
less than 25%.
But I keep my filaments open on a shelf year-round and have never
perceived a problem. Maybe I'm just not picky enough.
On 1/3/2026 3:24 PM, gene heskett via Discuss wrote:
> Picking up moisture from the environment . Such housings are
> worthless w/o
> enough heat to keep the filament dry so it doesn't get confused with
> Orvilles finest
> popcorn in the printhead hotends.
There are certain advantages to living in SoCal, where humidity is often
less than 25%.
But I keep my filaments open on a shelf year-round and have never
perceived a problem. Maybe I'm just not picky enough.
JB
Jon Bondy
Sun, Jan 4, 2026 12:07 AM
My experience is that I never dry PLA, PETG, or TPU, and my prints are
all flawless. I have a Prusa XL, a Bambulab X1C, and a Bambulab H2D,
all fully loaded with spools of filament.
I know that I am an outlier.
Living in Vermont and heating with wood might account for some of this.
On 1/3/2026 6:24 PM, gene heskett via Discuss wrote:
Picking up moisture from the environment . Such housings are
worthless w/o
enough heat to keep the filament dry so it doesn't get confused with
Orvilles finest
popcorn in the printhead hotends.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
My experience is that I never dry PLA, PETG, or TPU, and my prints are
all flawless. I have a Prusa XL, a Bambulab X1C, and a Bambulab H2D,
all fully loaded with spools of filament.
I know that I am an outlier.
Living in Vermont and heating with wood might account for some of this.
On 1/3/2026 6:24 PM, gene heskett via Discuss wrote:
> Picking up moisture from the environment . Such housings are
> worthless w/o
> enough heat to keep the filament dry so it doesn't get confused with
> Orvilles finest
> popcorn in the printhead hotends.
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
GH
gene heskett
Sun, Jan 4, 2026 12:31 AM
On 1/3/26 18:42, Jordan Brown via Discuss wrote:
On 1/3/2026 3:24 PM, gene heskett via Discuss wrote:
Picking up moisture from the environment . Such housings are
worthless w/o
enough heat to keep the filament dry so it doesn't get confused with
Orvilles finest
popcorn in the printhead hotends.
There are certain advantages to living in SoCal, where humidity is often
less than 25%.
Yeah, Nice advantage. Chuckle. But you import water from Colorado, and
your electricity
comes from San Juan coal fired station or the 4 corners coal fired
generation plant between
Farmington and Shiprock NM. Last time I checked, over 60 gigawats of
it. The air in Farmington
isn't breathable on a long term basis. The San Juan River Basin traps
all that pollution.
BTDT, both places. Here in WV, nat gas rules, air is breathable. Geiger
counter runs 2 to 3 x
the background range AES claims so that's a minus of sorts. Yeah, I
track such stuff, the
counter is about 20" from where I'm sitting.
But I keep my filaments open on a shelf year-round and have never
perceived a problem. Maybe I'm just not picky enough.
I can't, a week exposed and I have to dry for a day.
Whereas my 90% furnace has a humidifier, to keep it up around 50% for
the Wifes COPD,
but she signed off from it 5 years back up the log. Had her for 31
years. Now I'm alone,
pestering some of the net where I might be able to help. Or in this
case, to learn about
OpenSCAD. Thank you ALL!
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.
On 1/3/26 18:42, Jordan Brown via Discuss wrote:
> On 1/3/2026 3:24 PM, gene heskett via Discuss wrote:
>> Picking up moisture from the environment . Such housings are
>> worthless w/o
>> enough heat to keep the filament dry so it doesn't get confused with
>> Orvilles finest
>> popcorn in the printhead hotends.
> There are certain advantages to living in SoCal, where humidity is often
> less than 25%.
Yeah, Nice advantage. Chuckle. But you import water from Colorado, and
your electricity
comes from San Juan coal fired station or the 4 corners coal fired
generation plant between
Farmington and Shiprock NM. Last time I checked, over 60 gigawats of
it. The air in Farmington
isn't breathable on a long term basis. The San Juan River Basin traps
all that pollution.
BTDT, both places. Here in WV, nat gas rules, air is breathable. Geiger
counter runs 2 to 3 x
the background range AES claims so that's a minus of sorts. Yeah, I
track such stuff, the
counter is about 20" from where I'm sitting.
> But I keep my filaments open on a shelf year-round and have never
> perceived a problem. Maybe I'm just not picky enough.
I can't, a week exposed and I have to dry for a day.
Whereas my 90% furnace has a humidifier, to keep it up around 50% for
the Wifes COPD,
but she signed off from it 5 years back up the log. Had her for 31
years. Now I'm alone,
pestering some of the net where I might be able to help. Or in this
case, to learn about
OpenSCAD. Thank you ALL!
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
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.
GH
gene heskett
Sun, Jan 4, 2026 1:28 AM
On 1/3/26 19:07, Jon Bondy wrote:
My experience is that I never dry PLA, PETG, or TPU, and my prints are
all flawless. I have a Prusa XL, a Bambulab X1C, and a Bambulab H2D,
all fully loaded with spools of filament.
I know that I am an outlier.
Living in Vermont and heating with wood might account for some of this.
Absolutely Jon although I'd assume the spring with its warmer rain might
give you a faint hint
now and then. You wouldn't see it much but your prints might feel like
sandpaper occasionally.
Like after a foggy morning.
On 1/3/2026 6:24 PM, gene heskett via Discuss wrote:
Picking up moisture from the environment . Such housings are
worthless w/o
enough heat to keep the filament dry so it doesn't get confused with
Orvilles finest
popcorn in the printhead hotends.
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.
On 1/3/26 19:07, Jon Bondy wrote:
> My experience is that I never dry PLA, PETG, or TPU, and my prints are
> all flawless. I have a Prusa XL, a Bambulab X1C, and a Bambulab H2D,
> all fully loaded with spools of filament.
>
> I know that I am an outlier.
>
> Living in Vermont and heating with wood might account for some of this.
Absolutely Jon although I'd assume the spring with its warmer rain might
give you a faint hint
now and then. You wouldn't see it much but your prints might feel like
sandpaper occasionally.
Like after a foggy morning.
>
>
> On 1/3/2026 6:24 PM, gene heskett via Discuss wrote:
>> Picking up moisture from the environment . Such housings are
>> worthless w/o
>> enough heat to keep the filament dry so it doesn't get confused with
>> Orvilles finest
>> popcorn in the printhead hotends.
>
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.
