Side view of a shaft of undefined length
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.