I have come across an odd problem.

I have a box out of which I cut various holes using difference() which is for a drill guide.
This works fine, but the side of the thing over which the guide fits is slightly slanted, making it not fit well.
So I made the cut out which creates the hole for the to-be-drilled-box into a polyhedron, so the floor could have the matching slant.

This works fine when I cut out a cube. But when I cut out a polyhedron, the bottom surface of the shape cut from the cube is see through.

Any insights would be much appreciated.

This is the code..

/////////////////////////////////
//
// Drill guide for Attenuator holes
//
////////////////////////////////

// A box with the bottom slanted, to match the slanted side of the Hammond 1590B, which is 112mm long
// on the base and 111mm long on the top. To be cut out of the main lump of plastic.

module slanted_side_box(width, depth, height, slant) {
polyhedron(
points=[[0,0,0],[0,depth,slant],[width,depth,slant],[width,0,0], [0,0,height+4],[0,depth,height+4],[width,depth,height+4],[width,0,height+4]],
faces=[[0,1,2,3],[0,4,7,3],[0,1,5,4],[1,2,6,5],[3,7,6,2],[4,5,6,7]], convexity = 10);
}

// The main box, out of which the slanted box, the kerf relief space, the guide holes and
// A couple of material saving holes are cut.
module box(height, depth, width, wall_thickness, guide_thickness, guide_radius, slant) {
$fn=100;
difference() {
// The box out of which we chop the holes
cube([width+(wall_thickness*2),depth+(wall_thickness*2),height+guide_thickness]);

union() {
// The hole into which the box fits
//translate([wall_thickness,wall_thickness,guide_thickness]) cube([width,depth,height+2]); //<--- this works.
translate([wall_thickness,wall_thickness,guide_thickness]) slanted_side_box(width, depth, height, 0.5); // <-- this not so much.

// A dip in the floor to allow shavings to not rub against the box
translate([wall_thickness*2,wall_thickness*2,guide_thickness-2]) cube([width-(wall_thickness*2),depth-(wall_thickness*2),height+8]);

// One of the bushing holes
translate([wall_thickness+20.34, wall_thickness+19,-1]) cylinder(r=guide_radius, h=guide_thickness+4);

// The other bushing hole
translate([wall_thickness+20.34+20.32, wall_thickness+19, -1]) cylinder(r=guide_radius, h=guide_thickness+4);

// Saving some print material..
translate([wall_thickness*1.5,wall_thickness*2,-1]) cube([6,depth-(wall_thickness*2), guide_thickness+2]);

// Saving some print material..
translate([width+2-wall_thickness*1.1,wall_thickness*2,-1]) cube([6,depth-(wall_thickness*2), guide_thickness+2]);

// Bottom text
translate([13,1,10]) rotate([90,0,0]) linear_extrude(2) text(text="Bottom", size=10, $fn=100);
// Top text
translate([45,depth+wall_thickness+wall_thickness-1,10]) rotate([90,0,180]) linear_extrude(2) text(text="Top", size=10, $fn=100);
};

};
};

box(height=15, width=61, depth=31.7, wall_thickness=5,guide_thickness=15,guide_radius=6.5, slant=0); // For 1/4" drill bushing

Hi David,

It's a good idea to start a new topic rather than replying to someone
else's.

You problem isa face is inside-out. You see this in View/Thrown-together as
purple;
http://forum.openscad.org/file/n16248/davidJohnson.jpg

See Point ordering for faces in
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Primitive_Solids#polyhedron

Admin - PM me if you need anything, or if I've done something stupid...

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/  time is running out!

View this message in context: http://forum.openscad.org/Is-it-possible-to-use-shapes-as-variables-tp16223p16248.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Aetig wrote

• I am a newbie with regard to OpenSCAD, and I was wondering is it possible
• to use shapes as variables?

You cannot currently write
myShape = difference()  {cube(12, center=true); sphere(8);};
although that is being considered as a future extension.

Instead, you must write
module myShape() difference()  {cube(12, center=true); sphere(8);};
and write "myShape()" instead of "myShape" to reference the definition.
This is more verbose, but is otherwise equivalent to "myShape = ..."

• I think the usual way goes like this:
• union()  {

• cylinder(15, 7);
  

• difference()  {cube(12, center=true); sphere(8);}
  

• }
• In this case the structure is build somehow from bottom up, first shapes
• being generates deepest / last in the code.
• Somehow, at least for me, it would be easier to read and write code using
• shapes as variables and manipulating them incrementally, and the same code
• could look something like this:
• myShape = difference()  {cube(12, center=true); sphere(8);};
• myShape = union()  {myShape; cylinder(15, 7);};
• In this case first shapes are first in the code, and they are
• incrementally developed.
• So is it possible to write code like in second imaginary example?

Yes, but you need to use a slightly different style than you are used to.

OpenSCAD is a declarative, "single-assignment" language. A variable can
only be assigned once. Another way to think of this: "x = y;" is a
definition of x.

You can still write a sequence of definitions, and define your shape
incrementally, but each definition must have a different name. That's only
a small change from the way you'd code this in an imperative language.

If we supported shape variables, you'd write:

myShape = difference()  {cube(12, center=true); sphere(8);};
myShape2 = union()  {myShape; cylinder(15, 7);};

But since you need to use module definitions, you instead will write:

module myShape() difference()  {cube(12, center=true); sphere(8);};
module myShape2() union()  {myShape(); cylinder(15, 7);};

You need to know 2 more things to make the transition from an imperative to
a declarative style: how to code incremental definitions involving
conditionals, and involving loops.

In an imperative language, using conditionals you might write:

myShape = difference()  {cube(12, center=true); sphere(8);};
if (flag) myShape = union()  {myShape; cylinder(15, 7);};

In OpenSCAD, you can't update a variable from inside an if statement, but
you can do something equivalent by rearranging the code. First, in variable
form (not yet valid OpenSCAD):

myShape = difference()  {cube(12, center=true); sphere(8);};
myShape2 = union() {myShape; if (flag) cylinder(15, 7); }

In the second definition, union has 1 argument if flag is false, or 2
arguments if flag is true.

And now in module form:

module myShape() difference()  {cube(12, center=true); sphere(8);};
module myShape2() union() {myShape(); if (flag) cylinder(15, 7); }

In an imperative language, using a loop, you might write:

myShape = sphere(10, center=true);
for (i = [0:60:300]) {
bump = rotate(i) translate([10,0,0]) sphere(2, center=true);
myShape = union() {myShape; bump;};
}

In OpenSCAD, you can't update a variable from inside a loop, but by
rearranging the code, you can do something equivalent. First in variable
form (not yet valid OpenSCAD):

myShape = sphere(10, center=true);
bumps = for (i = [0:60:300]) {
rotate(i) translate([10,0,0]) sphere(2, center=true);
}
myShape2 = union() {myShape; bumps;}

and now in module form:

module myShape() sphere(10, center=true);
module bumps() for (i = [0:60:300]) {
rotate(i) translate([10,0,0]) sphere(2, center=true);
}
module myShape2() union() {myShape(); bumps();}

To summarize, there are 3 basic idioms involved in incrementally defining a
shape: sequences of definitions, conditionals, and loops. I've shown how to
translate those 3 idioms from an imperative language to a declarative
language like OpenSCAD. There's nothing missing from OpenSCAD, relative to
an imperative language, you just need to write your code slightly
differently.

Carsten said: "You cannot do it in the OpenSCAD language, as you are not
allowed to modify variables, and you cannot store shapes in variables."

That may be overstating the issue. The same concepts can be expressed; it's
just that the idioms and syntax are different. Once we have shape
variables, we'll be able to write terser code, but the issue here is
verbosity, not expressibility.