// units
Zero = 0 ;
One = 25 ;
Two = One*2 ;

module Diagonal () {
polyhedron([ [Zero,Zero,Zero], [Zero,One,One], [One,Zero,One],
[Zero,Zero,One] ],
[ [0,1,3], [0,3,2], [1,2,3], [0,2,1] ]) ;
}

difference () {
cube(Two) ;
translate([Zero,Zero,One]) {
cube([One,Two,One]) ;
cube([Two,One,One]) ;
}
translate([Zero,-One,Zero]) rotate([0,-45,0]) cube([Two,Two,Two]) ;
translate([One,One,One]) Diagonal() ;
translate([Zero,One,Zero]) Diagonal() ;
}

Yeah, the "Diagonal" is a bit of a cheat I feel, but I am so bad at the
Two-Rotations with the acos/atan functions.
Next version :-)

Msquare

On Wed, 21 Jan 2026 at 14:31, William F. Adams via Discuss <
discuss@lists.openscad.org> wrote:

Nice!

Guenther pointed out that I got it wrong, but I was able to fix it by changing one number (hard-coded --- will have to figure out the trigonometry or other mechanism for placement).

William

On Wednesday, January 21, 2026 at 09:29:50 AM EST, Michael Möller private2michael@gmail.com wrote:

// units
Zero = 0 ;
One = 25 ;
Two = One*2 ;

module Diagonal () {
 polyhedron([ [Zero,Zero,Zero], [Zero,One,One], [One,Zero,One], [Zero,Zero,One] ],
            [ [0,1,3], [0,3,2], [1,2,3], [0,2,1] ]) ;
}

difference () {
  cube(Two) ;
  translate([Zero,Zero,One]) {
    cube([One,Two,One]) ;
    cube([Two,One,One]) ;
  }
  translate([Zero,-One,Zero]) rotate([0,-45,0]) cube([Two,Two,Two]) ;
  translate([One,One,One]) Diagonal() ;
  translate([Zero,One,Zero]) Diagonal() ;
}

Yeah, the "Diagonal" is a bit of a cheat I feel, but I am so bad at the Two-Rotations with the acos/atan functions.
Next version :-)

Msquare

On Wed, 21 Jan 2026 at 14:31, William F. Adams via Discuss discuss@lists.openscad.org wrote:

Two ways to do it in BOSL2

include<BOSL2/std.scad>

pat1 = [[0,0,1],[1,1,1],[1,1,1]];

pat2 = [[0,1],[1,1]];

top_half()

textured_tile(pat1, [2,2,1],  tex_reps=1)

align(TOP, RIGHT+FWD)

textured_tile(pat2, [1,1,1], tex_reps=1);

include<BOSL2/std.scad>

s1 = square(1);

s2 = select(s1,0,2);

skin([s1,s2],z=[0,1],slices=0);

left(1)skin([s1,s1,s2],z=[0,1,2],slices=0);

back(1.5)prismoid([2,1],[1,1],h=1,shift=[-1/2,0]);

On Wed, Jan 21, 2026 at 11:06 William F. Adams via Discuss <
discuss@lists.openscad.org> wrote:

Here's my entry. Although it's vanilla code, it's just about as readable
as a polyhedron()!

difference() {
     union() {
         translate([-1, 0, 0]) cube([2, 1, 1]);
         translate([-1, 0, 1]) cube(1);
     }

     translate([1, 1, 1] * 2 / 3)
         rotate([0, atan(sqrt(2)), 45])
             translate([-2, -2, 0]) cube(4);
}

difference() {
     translate([-1, 1, 0]) cube([2, 1, 1]);
     translate([0, 0, 1]) rotate([0, 45, 0]) cube(3);
}

Anyone else notice that /command line/ OpenSCAD can't parse original
attachment because it is UTF-8 (has the UTF-8 prefix) ?

$ openscad --version
OpenSCAD version 2026.01.02
$ openscad "MarkStoddard Block.scad" /*<=== Opens window and
displays correctly*/
$ openscad "MarkStoddard Block.scad" -o out.stl
ERROR: Parser error: syntax error in file MarkStoddard Block.scad,
line 1
Can't parse file 'MarkStoddard Block.scad'!

$ dos2unix "MarkStoddard Block.scad"
dos2unix: converting file MarkStoddard Block.scad to Unix format...
$ openscad "MarkStoddard Block.scad" -o out.stl
Geometries in cache: 17
Geometry cache size in bytes: 17672
CGAL Polyhedrons in cache: 2
CGAL cache size in bytes: 0
Total rendering time: 0:00:00.023
    Top level object is a 3D object (manifold):
    Status:     NoError
    Genus:      0
    Vertices:       18
    Facets:         32

If one edits the file in OpenSCAD, the file is saved back as ASCII.
After that it can be processed from the command line. (If one edits the
file in Emacs or Vim, the file is saved back as UTF-8.)

Possible bug 1: should be able to process a UTF-8 file from the command
line (at the very least, ignore the prefix)
Possible bug 2: should be able to edit a UTF-8 file and save it back as
UTF-8 (a bigger can of worms)

-Curt

On 1/21/26 05:30, William F. Adams via Discuss wrote:

Hey, that's an awesome short.
you are an absolute geometry wizard :)

On Thu, Jan 22, 2026 at 10:44 AM Curt McDowell via Discuss <
discuss@lists.openscad.org> wrote:

as a polyhedron()!

We have a winner!

On Thu, Jan 22, 2026 at 3:44 AM Curt McDowell 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:

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:

On 1/22/2026 9:48 AM, Adrian Mariano via Discuss wrote:

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:

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 10:27 AM, Michael Möller via Discuss wrote:

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.

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 11:25 AM, Adrian Mariano wrote:

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.

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 12:12 PM, Father Horton wrote:

Indeed, if it qualifies for tail recursion there's no limit.

(Which is itself a problem, since there's also no effective "abort"
mechanism.)