OpenScad Help Centre

[old man emu]

Here's the link: http://www.openscad.org/cheatsheet/index.html

Yes! Yes! Hasten slowly.

I did a bit of that tonight, and here's the little bit of code I ended up with. The object is a toddler's Duplo building block. It took about half an hour to do, and that involved going back and forth to the cheat sheet.

Here's my notes for the object, except that I was going to make a four peg block when I pinched the Duplo from my grandson. The first design decision I made was to make a block with a single peg, then multiply and join the single one.

Duplo Sketch.jpg

After some reading; some cut and paste, and some delete and replace work, I came up with this:

Single Duplo Block.scad

Critique appreciated.

How do you get a grid displayed for measurement purposes? Working out where the centres of the spheres and cylinder was what took most of the time with this exercise.

Old Man Emu

[Roxy]

How do you get a grid displayed for measurement purposes? Working out where the centres of the spheres and cylinder was what took most of the time with this exercise.

A sphere and cylinder are always generated at (0,0). So when you translate them... what ever amount you translated them... Is where the center's are. I warmed over your code so you can see how to make your code easier to understand:

singleduploblock();

module singleduploblock () {
$fn=100;
cube (32,32,20);
color("gray", 0.5) translate([16,16,20]) cylinder(36, d=30);
difference() {
color("red" ) translate([16,16,55]) sphere(d=30);
color ("lime") translate ([ 8,8,68 ]) cube([16,16,8]);
 }
 }

First, in OpenScad you should have a 'Top Level' geometry. That is what that first singleduploblock(); is. It references other stuff, but it is at the top level.

singleduploblock() does not have any paremeters, and certainly does not need its name passed in as a parameter.

It is typical, and usually better to put modifiers like color() in the front of the line. And it is usually best to combine things that go together like color(), translate() and cube() so it is easy to pick out what everything is doing.

And of course, indenting really helps too. For example, having things indented makes it easier to see what the difference() is operating on. The code directive isn't working perfectly on this post... But you can see what I mean even though I'm restricted on how to indent 'properly'. You only have one module in this file so this won't be as clear. But a lot of people indent everything within a module so it is clear where a module starts and ends. The module declarations are part of the 'top level' so they are pushed as far to the left as possible. As you get nested deeper and deeper, you indent more and more to show that.

Even though what I posted is almost exactly what you had... most people would prefer to work with my version.

[printbus]

...And of course, indenting really helps too...

Another good habit for anywhere brackets are used is to comment the closing bracket to explain what it closes, exactly like CA did in his fully annotated script.