Side view of a shaft of undefined length
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?
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 ].
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.
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.
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.
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?
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.
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.
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.
But here's a different answer for this particular case, that doesn't
rely on undefined colors and doesn't have a potential for Z-fighting.
You're drawing a black shape, and then drawing a super-bright shape on
top of it so that only the outline shows.
So just use difference. That way you don't need to simulate the
background; you can let the actual background show through. I've
included the entire program below for easy copy/paste/run, but the only
thing I've changed is shaft().
// Shaft of undefined length
module lissajous(l, r)
{
polygon([
for ( i = [0 : 1 : 360])
[r/4sin(i)+l/2, rcos(i/2)],
for ( i = [360 : -1 : 0])
[r/4sin(i)-l/2, rcos(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]) difference() {
offset(off)
lissajous(l=l, r=r);
offset(-off)
lissajous(l=l, r=r);
}
}
shaft(10, 100, 0.2);
Meant to include a picture...
Jordan Brown wrote:
You're drawing a black shape, and then drawing a super-bright shape on
top of it so that only the outline shows.
The super-bright shape doesn’t show, if the colour is right, but it makes the object (the shaft) opaque.
I have found that colour differences can be seen most clearly if I push back the screen of my laptop until it is almost flat and look at it from a low angle.
A shape in the xy-plane appears brightest, white in fact, at $vpr=[ 45, 45, 0 ] and $vpr=[ 225, -225, 0 ]. Over a range $vpr=[ 45+/-12, 0, 0 ], a shape with an RGB colour of [1, 1, 0.9] matches the background. So, at $vpr=[ 0, 0, 0 ], the brightness of the shape has to be boosted to match the background, one would imagine by 1/sin45. But the actual factor determined by visual comparison seems to be 1/sin51.1 or 1.285. Perhaps this discrepancy is because “color() expects numbers between 0.0 and 1.0”. But this is not a catastrophe, and the discrepancy is plainly visible, so I don’t think it merits or needs a warning in the console. Unnecessary warnings make the necessary ones harder to find.
Is OpenSCAD really the tool you want for this? It seems like Povray might
do better.
On Tue, Sep 23, 2025 at 2:32 PM Caddiy via Discuss <
discuss@lists.openscad.org> wrote:
Jordan Brown wrote:
You're drawing a black shape, and then drawing a super-bright shape on
top of it so that only the outline shows.
The super-bright shape doesn’t show, if the colour is right, but it makes
the object (the shaft) opaque.
I have found that colour differences can be seen most clearly if I push
back the screen of my laptop until it is almost flat and look at it from a
low angle.
A shape in the xy-plane appears brightest, white in fact, at $vpr=[ 45,
45, 0 ] and $vpr=[ 225, -225, 0 ]. Over a range $vpr=[ 45+/-12, 0, 0 ], a
shape with an RGB colour of [1, 1, 0.9] matches the background. So, at
$vpr=[ 0, 0, 0 ], the brightness of the shape has to be boosted to match
the background, one would imagine by 1/sin45. But the actual factor
determined by visual comparison seems to be 1/sin51.1 or 1.285. Perhaps
this discrepancy is because “color() expects numbers between 0.0 and 1.0”.
But this is not a catastrophe, and the discrepancy is plainly visible, so I
don’t think it merits or needs a warning in the console. Unnecessary
warnings make the necessary ones harder to find.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Father Horton wrote:
Is OpenSCAD really the tool you want for this? It seems like Povray might do better.
Povray seems much too sophisticated for producing 2D drawings and requires lots of processing capacity/time.
On 9/23/2025 12:31 PM, Caddiy via Discuss wrote:
But this is not a catastrophe, and the discrepancy is plainly visible,
so I don’t think it merits or needs a warning in the console.
Unnecessary warnings make the necessary ones harder to find.
You asked for something meaningless.
The fact that it accidentally did something that wasn't catastrophic,
and was maybe even what you wanted, is irrelevant.
For most people, if they get their arithmetic wrong and ask for
something meaningless, they'd rather get told about it than silently get
the wrong answer.
For this kind of application, what I would do is to create a large
backdrop, and then vertically stack colored objects on top of it.
I would never overlap two objects at the same height, because that's
another kind of undefined behavior.
If you then look at that from +Z in orthogonal mode you should get a
clean image, with whatever background color you like. Well, as long as
you don't like bright colors, because it's not lit straight-on and so
isn't fully lit.
I don't immediately come up with a straightforward way to have something
that is both fully lit and orthogonal to the camera. If you were
super-ultra clever you might be able to draw the object skewed and then
view it skewed, so that it's orthogonal to the light and appears to be
orthogonal to the camera.
Exporting to SVG might be useful too.
Caddy,
+1 to Jordan. As you went further
brightness of the shape has to be boosted to match the background, one would imagine by 1/sin45.
But the actual factor determined by visual comparison seems to be 1/sin51.1 or 1.285.
Perhaps this discrepancy is because “color() expects numbers between 0.0 and 1.0”. But this is not a catastrophe, and the discrepancy is plainly visible,
Those values are meaningless, as you have no idea of the garbage-in (some quantum magic) nicely-coloured-garbage-out.
Rather than trying to work within the 0..1 range.
You will get burnt in the long run. But if this is once-off, not to be revisited in future versions, good luck to you.
From: Jordan Brown via Discuss [mailto:discuss@lists.openscad.org]
Sent: Wednesday, September 24, 2025 1:43 PM
To: OpenSCAD general discussion Mailing-list
Cc: mikeonenine@web.de; Jordan Brown
Subject: [OpenSCAD] Re: Side view of a shaft of undefined length
On 9/23/2025 12:31 PM, Caddiy via Discuss wrote:
But this is not a catastrophe, and the discrepancy is plainly visible, so I don’t think it merits or needs a warning in the console. Unnecessary warnings make the necessary ones harder to find.
You asked for something meaningless.
The fact that it accidentally did something that wasn't catastrophic, and was maybe even what you wanted, is irrelevant.
The documented RGB value for Cornfield (kindly supplied by Jordan) gave me the relationship R:G:B. I was then able to determine empirically that it must to be boosted by 1.285 for a Cornfield surface in the XY-plane to match the background. Why 1.285? I don’t know and don’t care.
It works. Es besteht den Puddingtest. The proof of the pudding is in the eating, as they say. I can’t see anything meaningless in that.
Putting the colour boosted by 1.285 in the XY-plane brings the boost back down to 1.0, putting it back within the “legal” range - exactly the same as the background, in fact, which presumably is “legal”. So where is the problem?
+1 to Jordan.
I think we have a conflict between a practical approach and an academic approach.
On 9/24/2025 10:31 AM, Caddiy via Discuss wrote:
It works. /Es besteht den Puddingtest./ The proof of the pudding is in
the eating, as they say. I can’t see anything meaningless in that.
As long as you don't complain when it doesn't work in the next build, or
when it doesn't work on your new computer, or when it doesn't with with
the next edition of your OS, or whatever, go for it.
Thinking about the pipeline, I'm actually a little surprised that it
works. Sure, it works mathematically, but most of that low-level
graphics stuff is done with finite-sized integers. I would have guessed
that the color of the surface would have been fed through an 8,8,8 bit
bottleneck somewhere in the picture, too early to then be later dimmed
by the lack of light. I would not be at all surprised if it fails for
some graphics pipelines.