OpenScad Help Centre

[old man emu]

I think that we should stop for a moment and review what we have done so far, and to consider if we should establish an agreed plan of attack.

It is becoming clear that there are two groups contributing to this thread, and the groups can be identified by their familiarity with programming and software development in general. I place myself in the group that has very little experience. The other group contains people like Roxy, dacb, Printbus, Fri and the others who we see posting in the Marlin update thread. These people are obviously experienced programmers.

I see my group as being like the typist in the word processing pool. We don't need to know the source code for Word, but would really like to be able to use as many of its features as possible. The other group is the developers back at Microsoft who are working to debug the current version of Word, and at the same time working on its updates.

When I started this thread, I was sort of looking for the assembly of a document "OpenScad for Klutzes". I was, and am, prepared to pose the seemingly dumb questions, but in order to finish up with a useful document, I suggest that we need to go right back to Square One.

I thought I had gone there when I started to ask about syntax, but replies to those questions have made me realize that syntax is at least Square Three. Having thought about it, I am now thinking that Square One is "The OpenScad alphabet". We have jumped too far ahead with what we are looking at at the moment. For me, it is like asking a First Grader to read War and Peace in the original Cyrillic script.

I did some searching for 'symbols in programming' and found that, as well as the usual +, -, * /, sin, cos and tan, other symbols like braces, brackets, =, <,> and so on are just as important in getting a bit of code to work. Explanations of the use of symbols are not found in in the OpenScad documentation. I put that failure down to the documentation having been written by people who know their " programming alphabet" and forget that many users of the program they are developing can see the Cat on the Mat, but cannot express what they see in good code. The documentation is very heavily infested with programmers jargon, and even with mathematical knowledge that is beyond the ken of us Klutzes.

I appreciate the input that the programmers amongst you have had to this thread, but I would ask you to dumb down your inputs until we simpleton users have caught on.

Old Man Emu

[curious aardvark]

didn't you hollow it out ?

well that's easy enough.
Copy and paste the first module.

just reduce the size of the original by 2-3mm all round. Call it removeblock module. And difference the two modules.

You can repeat that script for different size and shape blocks.

[Roxy]

If you are smart, you ought to make sure your lego blocks plug into the real ones. That way, you can tell the parents to go buy the normal ones. And you can print the cool, specialty ones the kid needs (wants). Otherwise, you are going to be printing millions of these things!

[curious aardvark]

I think that we should stop for a moment and review what we have done so far, and to consider if we should establish an agreed plan of attack.

It is becoming clear that there are two groups contributing to this thread, and the groups can be identified by their familiarity with programming and software development in general. I place myself in the group that has very little experience. The other group contains people like Roxy, dacb, Printbus, Fri and the others who we see posting in the Marlin update thread. These people are obviously experienced programmers.

I see my group as being like the typist in the word processing pool. We don't need to know the source code for Word, but would really like to be able to use as many of its features as possible. The other group is the developers back at Microsoft who are working to debug the current version of Word, and at the same time working on its updates.

When I started this thread, I was sort of looking for the assembly of a document "OpenScad for Klutzes". I was, and am, prepared to pose the seemingly dumb questions, but in order to finish up with a useful document, I suggest that we need to go right back to Square One.

I thought I had gone there when I started to ask about syntax, but replies to those questions have made me realize that syntax is at least Square Three. Having thought about it, I am now thinking that Square One is "The OpenScad alphabet". We have jumped too far ahead with what we are looking at at the moment. For me, it is like asking a First Grader to read War and Peace in the original Cyrillic script.

I did some searching for 'symbols in programming' and found that, as well as the usual +, -, * /, sin, cos and tan, other symbols like braces, brackets, =, <,> and so on are just as important in getting a bit of code to work. Explanations of the use of symbols are not found in in the OpenScad documentation. I put that failure down to the documentation having been written by people who know their " programming alphabet" and forget that many users of the program they are developing can see the Cat on the Mat, but cannot express what they see in good code. The documentation is very heavily infested with programmers jargon, and even with mathematical knowledge that is beyond the ken of us Klutzes.

I appreciate the input that the programmers amongst you have had to this thread, but I would ask you to dumb down your inputs until we simpleton users have caught on.

Old Man Emu

That actually makes it a whole lot more complicated.
What you're suggesting is that we memorise every single command and symbol BEFORE actually doing anything practical.

I'm actually in the third camp. Not a programmer, not a complete novice. I'm The User. I want to make things.

So I start with something I want to make and work out what i need to learn for that model. And the more models I make the more openscad I absorb.
But the important thing is: 'I'M USING THE PROGRAM ALL THE TIME'.
When i come across something I want to do and can't, I go looking for the method to use.

It's a more organic way of learning.
I don't NEED to know every symbol openscad uses. I only need to know the ones relevant to the models I'm making at the time.

[Mjolinor]

That actually makes it a whole lot more complicated.
What you're suggesting is that we memorise every single command and symbol BEFORE actually doing anything practical.

I'm actually in the third camp. Not a programmer, not a complete novice. I'm The User. I want to make things.

So I start with something I want to make and work out what i need to learn for that model. And the more models I make the more openscad I absorb.
But the important thing is: 'I'M USING THE PROGRAM ALL THE TIME'.
When i come across something I want to do and can't, I go looking for the method to use.

It's a more organic way of learning.
I don't NEED to know every symbol openscad uses. I only need to know the ones relevant to the models I'm making at the time.

I'm with you on that one. Cheat sheet open and once you work out what you need you figure which commands do it. Slowly you use the cheat sheet less and occasionally you need to learn something new and open it again.

[Roxy]

So I start with something I want to make and work out what i need to learn for that model. And the more models I make the more openscad I absorb.
But the important thing is: 'I'M USING THE PROGRAM ALL THE TIME'.
When i come across something I want to do and can't, I go looking for the method to use.

I've been doing things along this line of thinking. But I would add one thing. Sometimes I can do what I want, but it is very clumsy and brute force. If I can see the source code from somebody else that solved the problem the 'right way' using the full power of the language, I can learn a lot from that.

[curious aardvark]

Yep - but you can actually learn a lot by doing something the long way round.

Example I had no idea that you could use the facet command for a single model rather than as a purely global variable.

So when i made this model: http://www.thingiverse.com/thing:582323
I had to work out how to program a polygon script. Learnt a lot doing that, which I would not have learned just using a six faceted cylinder :-)
I now know both ways :-)

In case you're wondering I'm the idiot holding the duck - yes i should have been wearing gloves. That thing stings !
But it works :-) And i enjoyed working out a fully parametric polygon generator.

[Mjolinor]

Yep - but you can actually learn a lot by doing something the long way round.

Example I had no idea that you could use the facet command for a single model rather than as a purely global variable.

So when i made this model: http://www.thingiverse.com/thing:582323
I had to work out how to program a polygon script. Learnt a lot doing that, which I would not have learned just using a six faceted cylinder :-)
I now know both ways :-)

In case you're wondering I'm the idiot holding the duck - yes i should have been wearing gloves. That thing stings !
But it works :-) And i enjoyed working out a fully parametric polygon generator.

You'll never get a shine on that duck doing it that way. Your buffing wheel needs to go faster and use some polishing wax.

[Roxy]

Example I had no idea that you could use the facet command for a single model rather than as a purely global variable.

What's a facet command? Searching the OpenScad manual doesn't find any reference to that.

Update: I figured out what you meant. I suspect you are talking about the $fn parameter????

[old man emu]

Curious Aardvark - his father was a pheasant plucker, so he's a pheasant plucker's son. Oh it's so pleasant being a pheasant plucker's son, plucking pheasants in the sun. Plucking pheasants in the sun and being video'd by Mum.

The whirring sound is Noel Coward spinning in his grave.

OME