TooTallToby CAD challenge
I've churned through all the above. The time to render or produce STL
is +/-10% between all. The time is so short, so it varies by that much
(inaccuraies, not RealTime, windows10 etc)
Adrians using BOSL2 is 3 times slower in parsing (fraction of a second).
But that is probably saved by the faster time to generate the code (which
is what the challenge was: time to code the shape)
Jordans 2nd attempt is not manifold, but my slicer accepted it
nevertheless. Williams is slightly wrong, as he has pointed out.
Irrespective of the code, the slicer says it needs 69.03 cm³ plastic, with
solid infill. I have not printed it.
On Thu, 22 Jan 2026 at 18:48, Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
Jordan, BOSL2 will help you avoid that trig and decrease the required
thinking as shown below. :) I think I like my second BOSL2 solution the
best. To me it seems the most comprehensible.
include<BOSL2/std.scad>
module truncatedCube() {
difference() {
cube();
translate([1,0,0])
rot(from=[1,0,0],to=[1,-1,1])
translate([0,-1,0]) cube(2);
}
}
module diagonalHalfCube() {
difference() {
cube();
rotate([45,0,0]) translate([-1,0,0]) cube(3);
}
}
truncatedCube();
translate([0,1,1]) truncatedCube();
translate([0,1,0]) cube();
translate([1,1,0]) cube();
translate([1,0,0]) diagonalHalfCube();
On Thu, Jan 22, 2026 at 12:31 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
Here's a geometric answer. I'm deeply dissatisfied by the need to resort
to trig. Intuitively, it seems like you should be able to construct that
figure using a series of 45° rotates, but I wasn't able to. Note also that
this violates the sometimes-rule of avoiding coincident faces. I found
constructing the polyhedron to be significantly easier. This required
actual thinking; the polyhedron was just a bit tedious.
module truncatedCube() {
difference() {
cube();
translate([1,0,0])
rotate([0,-atan2(1/2,sqrt(2)/2),-45])
translate([0,-1,0]) cube(2);
}
}
module diagonalHalfCube() {
difference() {
cube();
rotate([45,0,0]) translate([-1,0,0]) cube(3);
}
}
truncatedCube();
translate([0,1,1]) truncatedCube();
translate([0,1,0]) cube();
translate([1,1,0]) cube();
translate([1,0,0]) diagonalHalfCube();
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 1/22/2026 9:48 AM, Adrian Mariano via Discuss wrote:
Jordan, BOSL2 will help you avoid that trig and decrease the required
thinking as shown below. :)
Thanks, and I agree that's more obvious, but it's still unsatisfying
that it's not a sequence of 45° rotates. It probably can't be such a
sequence, but it should be.
On 1/22/2026 1:44 AM, Curt McDowell via Discuss wrote:
Anyone else notice that /command line/ OpenSCAD can't parse original
attachment because it is UTF-8 (has the UTF-8 prefix) ?
I thought I'd seen something to catch and ignore U+FEFF ZERO WIDTH
NO-BREAK SPACE, also known as BYTE ORDER MARK, but I'm not finding it now.
I filed issue #6555 https://github.com/openscad/openscad/issues/6555.
I would think that ease of writing and perhaps comprehending the code would
be more important most of the time compared to run time. The question
then is which code is the easiest to understand. Which ones were easy to
write? I didn't keep track of how long it took to write mine.
Here's a 3rd one that took just a few minutes to write, but not sure it's
particularly readable.
include<BOSL2/std.scad>
s1 = subdivide_path(square(2),n=8); // bottom layer shape
s2 = [[1,1],each select(s1,2,-1)]; // next layer shape
s3 = back(1,square(1)); // base of the small cube
s4 = select(s3,1,-1); // top layer shape
skin([s1,s2,s3,s4],z=[0,1,1,2],slices=0,method="distance");
On Thu, Jan 22, 2026 at 1:38 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/22/2026 9:48 AM, Adrian Mariano via Discuss wrote:
Jordan, BOSL2 will help you avoid that trig and decrease the required
thinking as shown below. :)
Thanks, and I agree that's more obvious, but it's still unsatisfying that
it's not a sequence of 45° rotates. It probably can't be such a
sequence, but it should be.
On 1/22/2026 10:27 AM, Michael Möller via Discuss wrote:
Jordans 2nd attempt is not manifold, but my slicer accepted it
nevertheless.
I think it's actually entirely manifold, but I see that CGAL objects.
The problem is that CGAL appears to be having trouble figuring out that
the union of the various solids (each of which is clearly manifold) is
itself manifold.
Even though the vertexes are all at integer coordinates, perhaps the
tilted-cube difference is yielding vertexes that are slightly off the
integer, and that's giving CGAL indigestion.
Here's an answer that's a hybrid of a polyhedron and a geometric
answer. (If you're wondering why [2,-1,2] instead of [1,0,1]: the
resulting tetrahedron contains the desired volume, and none of its faces
are coincident with the original cube's.) This polyhedron was simple
enough that I could do it entirely "freehand", without needing markers
for the points. Slightly to my surprise, since I was doing it all at
once and all in my head, I got it right the first time.
And CGAL likes it, suggesting that my guess about the vertexes of the
tilted-cube difference was indeed the problem in the previous example.
This one again violates the sometimes-rule of avoiding coincident faces.
module truncatedCube() {
difference() {
cube();
polyhedron(
points=[
[0,0,1],
[1,0,0],
[1,1,1],
[2,-1,2],
],
faces=[
[0,1,2],
[0,3,1],
[0,2,3],
[1,3,2],
]
);
}
}
module diagonalHalfCube() {
difference() {
cube();
rotate([45,0,0]) translate([-1,0,0]) cube(3);
}
}
truncatedCube();
translate([0,1,1]) truncatedCube();
translate([0,1,0]) cube();
translate([1,1,0]) cube();
translate([1,0,0]) diagonalHalfCube();
The question: what can you get with 45 deg rotations around the x, y and z
axes? It turns out this is an infinite group and so it's possible you can
get arbitrarily close to the [1,1,1] vector you were looking for. I leave
the task of finding the best approximator to the [1,1,1] angle using a
product of N 45 deg angles as an exercise...
I tried to draw a picture of the available points with a simple monte carlo
scheme:
include<BOSL2/std.scad>
module drawpt(p,max,count=0)
{
move(p) sphere(r=.01);
dir=rand_int(1,3,1)[0];
if (count<max)
drawpt( dir==0 ? zrot(45,p)
: dir==1 ? xrot(45,p)
: /dir==2/ yrot(45,p),max,count+1);
}
for(i=[1:20])
drawpt(RIGHT,2000);
Note as an aside, is there no way to increase allowed recursion depth? If
I set the max much higher it fails with "recursion detected" (like I didn't
know).
The image:
[image: image.png]
On Thu, Jan 22, 2026 at 1:38 PM Jordan Brown openscad@jordan.maileater.net
wrote:
On 1/22/2026 9:48 AM, Adrian Mariano via Discuss wrote:
Jordan, BOSL2 will help you avoid that trig and decrease the required
thinking as shown below. :)
Thanks, and I agree that's more obvious, but it's still unsatisfying that
it's not a sequence of 45° rotates. It probably can't be such a
sequence, but it should be.
On 1/22/2026 11:25 AM, Adrian Mariano wrote:
The question: what can you get with 45 deg rotations around the x, y
and z axes?
An additional constraint: my probably-wrong intuition says you should
be able to do it with no more than three rotations, zero or one in each
of the axes. (-45 rotations are OK.) That's a fairly small number;
maybe I'll put it together.
Note as an aside, is there no way to increase allowed recursion
depth? If I set the max much higher it fails with "recursion
detected" (like I didn't know).
At least one of the limits, maybe the only limit, is based on the
compiled-in C++ stack size. OpenSCAD recursion translates into C++
recursion, so that's a hard limit. (But: I don't know about the APIs
involved here, but at least some thread APIs let you specify the stack
size for newly created threads, so that might allow for customization.)
Tail recursion?
On Thu, Jan 22, 2026 at 1:35 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:
On 1/22/2026 11:25 AM, Adrian Mariano wrote:
The question: what can you get with 45 deg rotations around the x, y and z
axes?
An additional constraint: my probably-wrong intuition says you should be
able to do it with no more than three rotations, zero or one in each of the
axes. (-45 rotations are OK.) That's a fairly small number; maybe I'll
put it together.
Note as an aside, is there no way to increase allowed recursion depth? If
I set the max much higher it fails with "recursion detected" (like I didn't
know).
At least one of the limits, maybe the only limit, is based on the
compiled-in C++ stack size. OpenSCAD recursion translates into C++
recursion, so that's a hard limit. (But: I don't know about the APIs
involved here, but at least some thread APIs let you specify the stack size
for newly created threads, so that might allow for customization.)
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 1/22/2026 12:12 PM, Father Horton wrote:
Tail recursion?
Indeed, if it qualifies for tail recursion there's no limit.
(Which is itself a problem, since there's also no effective "abort"
mechanism.)