M
mikeonenine@web.de
Mon, Sep 22, 2025 8:07 PM
It took me a while to figure out, because, pretzel-like, lines cross, and one side is hidden behind the other. Then it occurred to me that Jules Antoine Lissajous might help. The rest was relatively straightforward:
// Shaft of undefined length
module lissajous(l, r)
{
polygon([
for ( i = [0 : 1 : 360])
[r/4*sin(i)+l/2, r*cos(i/2)],
for ( i = [360 : -1 : 0])
[r/4*sin(i)-l/2, r*cos(i/2)],
]);
polygon([
for ( i = [180 : 1 : 540])
[r/4*sin(i)+l/2+0.001, r*cos(i/2)],
]);
polygon([
for ( i = [-180 : 1 : 180])
[r/4*sin(i)-l/2-0.001, r*cos(i/2)],
]);
}
module shaft(r, l, off)
{
color([0, 0, 0])
offset(off)
lissajous(l=l, r=r);
color([1.3, 1.3, 1.15])
offset(-off)
lissajous(l=l, r=r);
}
shaft(10, 100, 0.2);
Looks a lot better than a simple rectangle.
BTW does anyone know the correct RGB values for the Cornfield background colour?
It took me a while to figure out, because, pretzel-like, lines cross, and one side is hidden behind the other. Then it occurred to me that Jules Antoine Lissajous might help. The rest was relatively straightforward:
`// Shaft of undefined length`
`module lissajous(l, r)`
`{`
`polygon([ `
`for ( i = [0 : 1 : 360])`
`[r/4*sin(i)+l/2, r*cos(i/2)],`
`for ( i = [360 : -1 : 0])`
`[r/4*sin(i)-l/2, r*cos(i/2)],`
`]);`
`polygon([ `
`for ( i = [180 : 1 : 540])`
`[r/4*sin(i)+l/2+0.001, r*cos(i/2)],`
`]);`
`polygon([ `
`for ( i = [-180 : 1 : 180])`
`[r/4*sin(i)-l/2-0.001, r*cos(i/2)],`
`]);`
`}`
`module shaft(r, l, off)`
`{`
`color([0, 0, 0])`
`offset(off)`
`lissajous(l=l, r=r);`
`color([1.3, 1.3, 1.15])`
`offset(-off)`
`lissajous(l=l, r=r);`
`}`
`shaft(10, 100, 0.2);`
Looks a lot better than a simple rectangle.
BTW does anyone know the correct RGB values for the Cornfield background colour?
JB
Jordan Brown
Mon, Sep 22, 2025 8:23 PM
BTW does anyone know the correct RGB values for the Cornfield background colour?
> BTW does anyone know the correct RGB values for the Cornfield background colour?
>
https://github.com/openscad/openscad/blob/master/src/glview/ColorMap.cc
Line 27
Looks like it’s FFFFE5. Or, if you prefer, [ 1, 1, 0.9 ].
M
mikeonenine@web.de
Mon, Sep 22, 2025 8:54 PM
BTW does anyone know the correct RGB values for the Cornfield background colour?
Not quite. That’s a very light grey, close to OpenSCAD White. It is given as background colour, whereas Cornfield is given as default. A little confusing.
Jordan Brown wrote:
> > BTW does anyone know the correct RGB values for the Cornfield background colour?
>
> https://github.com/openscad/openscad/blob/master/src/glview/ColorMap.cc
> Line 27
>
> Looks like it’s FFFFE5. Or, if you prefer, \[ 1, 1, 0.9 \].
Not quite. That’s a very light grey, close to OpenSCAD White. It is given as background colour, whereas Cornfield is given as default. A little confusing.
JB
Jordan Brown
Mon, Sep 22, 2025 9:19 PM
On 9/22/2025 1:54 PM, Caddiy via Discuss wrote:
Jordan Brown wrote:
BTW does anyone know the correct RGB values for the Cornfield
background colour?
https://github.com/openscad/openscad/blob/master/src/glview/ColorMap.cc
Line 27
Looks like it’s FFFFE5. Or, if you prefer, [ 1, 1, 0.9 ].
Not quite. That’s a very light grey, close to OpenSCAD White. It is
given as background colour, whereas Cornfield is given as default. A
little confusing.
Interesting.
I'm pretty sure that FFFFE5 is correct, both from source inspection and
from the fact that when I use a color-probing tool
https://learn.microsoft.com/en-us/windows/powertoys/color-picker
that's what it reports for the background. [ 1, 1, 0.9 ] is a tiny bit
whiter because of rounding; the B value resulting from it is 229.5
instead of 229 (on a 0-255 scale).
However, it depends on the lighting angle, and I suspect that it also
depends on the fact that it's being lit at all.
Here's an FFFFE5 cube with a FFFFE5 square just +X of it. Note how the
square is hiding part of the "100" on the axis, and the +X side of the
square is visible as a line.
The front two faces are of course the same color, yet because of
lighting they are shown much darker. My color probe calls the tops of
both the cube and square FFFFE6, so a tiny bit whiter than we asked for.
The same cube-and-square from +Z is not at all close to the FFFFE5 we
asked for:
So I'll stick with my original answer, but caution that colors on the
screen are influenced by lighting and so rarely precisely match the
specified color.
On 9/22/2025 1:54 PM, Caddiy via Discuss wrote:
>
> Jordan Brown wrote:
>
> BTW does anyone know the correct RGB values for the Cornfield
> background colour?
>
> https://github.com/openscad/openscad/blob/master/src/glview/ColorMap.cc
> Line 27
>
> Looks like it’s FFFFE5. Or, if you prefer, [ 1, 1, 0.9 ].
>
> Not quite. That’s a very light grey, close to OpenSCAD White. It is
> given as background colour, whereas Cornfield is given as default. A
> little confusing.
>
Interesting.
I'm pretty sure that FFFFE5 is correct, both from source inspection and
from the fact that when I use a color-probing tool
<https://learn.microsoft.com/en-us/windows/powertoys/color-picker>
that's what it reports for the background. [ 1, 1, 0.9 ] is a tiny bit
whiter because of rounding; the B value resulting from it is 229.5
instead of 229 (on a 0-255 scale).
However, it depends on the lighting angle, and I suspect that it also
depends on the fact that it's being lit at all.
Here's an FFFFE5 cube with a FFFFE5 square just +X of it. Note how the
square is hiding part of the "100" on the axis, and the +X side of the
square is visible as a line.
The front two faces are of course the same color, yet because of
lighting they are shown much darker. My color probe calls the tops of
both the cube and square FFFFE6, so a tiny bit whiter than we asked for.
The same cube-and-square from +Z is not at all close to the FFFFE5 we
asked for:
So I'll stick with my original answer, but caution that colors on the
screen are influenced by lighting and so rarely precisely match the
specified color.
M
mikeonenine@web.de
Mon, Sep 22, 2025 11:32 PM
I’m interested in the colour of the background, because I want to achieve the appearance of line drawings in which complete parts show just as an outline (cross-sections with hatching). The surface of the parts has to be exactly the same colour as the background.
However, it depends on the lighting angle, and I suspect that it also depends on the fact that it's being lit at all.
The drawings are 2D in the XY plane, the lighting is on the Z-axis.
Here's an FFFFE5 cube with a FFFFE5 square just +X of it. Note how the square is hiding part of the "100" on the axis, and the +X side of the square is visible as a line.
Your examples appear to use Cornfield too. The top of the cube is indistinguishable from the background - so far, so good. But the cube has been turned. I want to show objects as 2D outlines in the XY plane parallel to the background.
In theory, the RGB values for the XY plane could be derived from those of the top of the cube via the $vpr values - if these could be determined with any degree of precision.
I’m interested in the colour of the background, because I want to achieve the appearance of line drawings in which complete parts show just as an outline (cross-sections with hatching). The surface of the parts has to be exactly the same colour as the background.
> However, it depends on the lighting angle, and I suspect that it also depends on the fact that it's being lit at all.
The drawings are 2D in the XY plane, the lighting is on the Z-axis.
> Here's an FFFFE5 cube with a FFFFE5 square just +X of it. Note how the square is hiding part of the "100" on the axis, and the +X side of the square is visible as a line.
Your examples appear to use Cornfield too. The top of the cube is indistinguishable from the background - so far, so good. But the cube has been turned. I want to show objects as 2D outlines in the XY plane parallel to the background.
In theory, the RGB values for the XY plane could be derived from those of the top of the cube via the $vpr values - if these could be determined with any degree of precision.
M
mikeonenine@web.de
Mon, Sep 22, 2025 11:46 PM
The drawings are 2D in the XY plane, the lighting is on the Z-axis.
I think the lighting is NOT on the Z-axis, and that is the problem.
Where is it?
mikeonenine@web.de wrote:
> The drawings are 2D in the XY plane, the lighting is on the Z-axis.
I think the lighting is NOT on the Z-axis, and that is the problem.
Where is it?
M
mikeonenine@web.de
Tue, Sep 23, 2025 1:39 AM
The colour is
[1/sin(50), 1/sin(50), 0.9/sin(50)]
I believe
because 50 is a nice round number.
(Forget the 0.022% error in the blue.)
That’s mathematics guided by true faith.
The Church used to burn people like me at the stake.
The colour is
\[1/sin(50), 1/sin(50), 0.9/sin(50)\]
I believe
because 50 is a nice round number.
(Forget the 0.022% error in the blue.)
That’s mathematics guided by true faith.
The Church used to burn people like me at the stake.
MM
Michael Marx (spintel)
Tue, Sep 23, 2025 2:19 AM
Compiling design (CSG Tree generation)...
WARNING: color() expects numbers between 0.0 and 1.0. Value of 1.3 is out of range in file , line 47
WARNING: color() expects numbers between 0.0 and 1.0. Value of 1.3 is out of range in file , line 47
WARNING: color() expects numbers between 0.0 and 1.0. Value of 1.2 is out of range in file , line 47
1/sin(50) > 1
I wonder what color() does with out-of-range values, as it looks the right color.
From: Caddiy via Discuss [mailto:discuss@lists.openscad.org]
Sent: Tuesday, September 23, 2025 11:39 AM
To: discuss@lists.openscad.org
Cc: mikeonenine@web.de
Subject: [OpenSCAD] Re: Side view of a shaft of undefined length
The colour is
[1/sin(50), 1/sin(50), 0.9/sin(50)]
I believe
because 50 is a nice round number.
(Forget the 0.022% error in the blue.)
That’s mathematics guided by true faith.
The Church used to burn people like me at the stake.
Compiling design (CSG Tree generation)...
WARNING: color() expects numbers between 0.0 and 1.0. Value of 1.3 is out of range in file , line 47
WARNING: color() expects numbers between 0.0 and 1.0. Value of 1.3 is out of range in file , line 47
WARNING: color() expects numbers between 0.0 and 1.0. Value of 1.2 is out of range in file , line 47
1/sin(50) > 1
I wonder what color() does with out-of-range values, as it looks the right color.
_____
From: Caddiy via Discuss [mailto:discuss@lists.openscad.org]
Sent: Tuesday, September 23, 2025 11:39 AM
To: discuss@lists.openscad.org
Cc: mikeonenine@web.de
Subject: [OpenSCAD] Re: Side view of a shaft of undefined length
The colour is
[1/sin(50), 1/sin(50), 0.9/sin(50)]
I believe
because 50 is a nice round number.
(Forget the 0.022% error in the blue.)
That’s mathematics guided by true faith.
The Church used to burn people like me at the stake.
M
mikeonenine@web.de
Tue, Sep 23, 2025 2:39 AM
Michael Marx (spintel) wrote:
I wonder what color() does with out-of-range values, as it looks the right color.
Quite. Good question. More superfluous warnings to clog up the console.
Michael Marx (spintel) wrote:
> I wonder what color() does with out-of-range values, as it looks the right color.
Quite. Good question. More superfluous warnings to clog up the console.
JB
Jordan Brown
Tue, Sep 23, 2025 3:31 AM
Combining a couple of replies...
On 9/22/2025 4:32 PM, Caddiy via Discuss wrote:
The drawings are 2D in the XY plane, the lighting is on the Z-axis.
As you have figured out... you might want the lighting to be on the Z
axis, but it isn't.
In theory, the RGB values for the XY plane could be derived from those
of the top of the cube via the $vpr values - if these could be
determined with any degree of precision.
And if you know how the lighting affects the color. Which I don't :-)
I wonder what color() does with out-of-range values, as it looks
the right color.
Quite. Good question. More superfluous warnings to clog up the console.
No, it's not the right color. It's close, but it's not right. It ends
up at FFFFE9, at least on my system.
And no, it's not a superfluous warning. When you supplied a number
greater than one, you entered undefined territory. That's what the
warning is telling you. You MUST NOT depend on this behavior.
What I think is happening is that a value greater than 1.0 attempts to
set the color to that value. Depending on the lighting on the
particular face, you might get a darker version of that theoretical
"super" color, or it might get clamped to 100%. That's what it looks
like is happening, but I am not at all sure exactly what is implementing
this behavior, whether it's OpenSCAD, or some underlying library, or the
graphics hardware.
Next year, or even today on a different system, it might be an error, or
it might produce some other apparently-random color, or it might produce
an image that is brighter than 100%.
Again, this is UNDEFINED BEHAVIOR and you MUST NOT rely on it. It is
subject to CHANGE AT ANY TIME WITHOUT WARNING. If you continue to use
this behavior, DO NOT COMPLAIN if it ever stops working.
Combining a couple of replies...
On 9/22/2025 4:32 PM, Caddiy via Discuss wrote:
>
> The drawings are 2D in the XY plane, the lighting is on the Z-axis.
>
As you have figured out... you might *want* the lighting to be on the Z
axis, but it isn't.
> In theory, the RGB values for the XY plane could be derived from those
> of the top of the cube via the $vpr values - if these could be
> determined with any degree of precision.
>
And if you know how the lighting affects the color. Which I don't :-)
> I wonder what color() does with out-of-range values, as it looks
> the right color.
>
> Quite. Good question. More superfluous warnings to clog up the console.
>
No, it's not the right color. It's close, but it's not right. It ends
up at FFFFE9, at least on my system.
And no, it's not a superfluous warning. When you supplied a number
greater than one, you entered undefined territory. That's what the
warning is telling you. You MUST NOT depend on this behavior.
What I think is happening is that a value greater than 1.0 attempts to
set the color to that value. Depending on the lighting on the
particular face, you might get a darker version of that theoretical
"super" color, or it might get clamped to 100%. That's what it looks
like is happening, but I am not at all sure exactly what is implementing
this behavior, whether it's OpenSCAD, or some underlying library, or the
graphics hardware.
Next year, or even today on a different system, it might be an error, or
it might produce some other apparently-random color, or it might produce
an image that is brighter than 100%.
Again, this is UNDEFINED BEHAVIOR and you MUST NOT rely on it. It is
subject to CHANGE AT ANY TIME WITHOUT WARNING. If you continue to use
this behavior, DO NOT COMPLAIN if it ever stops working.
