Rendering issue with latest openscad

So I decided to design a 3d picture pinboard. More as an exercise in openscad scripting and captive printing than anything else.
One of these things - saw one in a cleints house and thought it would be fun to make a one print version.
http://ecx.images-amazon.com/images/I/51R%2BlG4DlAL.jpg

That part worked really well. It's parametric and I can - theoretically - generate any size grid.
Theoretically.
I've generated and printed a 2x2 grid - 4 pins. And it looks like I got my calculations and spacing right first time. Which is bloody unusual :-)
Ideally I want one almost as large as my print bed. And that's where I'm hitting problems.

A 10x10 grid (which would be about 8cm square - I'd like one at least 10x20cm), after about an hour rendering - crashes openscad with a couple of microsoft visual c++ error popups and then openscad just shuts down.

Currently trying a 5x5 grid. Nope bombed out.

The thing is it's a pretty simple script. pin module, hole module and four loops to place first the holes and then the pins in a cube sized according to the number of columns and rows.
There's no shape more complicated than a dual diameter cylinder.
So why does it take so long to render ?
And why does it crash.

And has anyone else had any crash issues with the latest openscad ?

Would you mind posting the .SCAD file so we can take a look? But... Even if you can't do that I have a couple of thoughts. Can you turn the matrix of cylinders into square pegs? The reason is spheres and cylinders have way way more triangles to 'compose' them than flat surfaces. Almost for sure that will make it render faster and use much less memory.

I have switched to the 2015-03 version of OpenScad. It is better than the previous version. But I have managed to get those same pop up windows. And once you get OpenScad sick, I think it is best to shut it down and re-open it. It appears to work if you don't do that. But it seems like once it gets sick, it never recovers. There is a very active OpenScad forum. I suspect if you post the code that blows it up a fix will happen!

Yeah this is the new version that's crashing. Never had any issues with the earlier versions.
I guess square pins and holes would work as well as round ones. Can't hurt to try. You could be onto something there. I never had any problems with the large crossbow dart holders.
cheers I'll give that a go. The top of the pins are spheres - guess I could knock the facets down to 50 or maybe less.

And when it crashes it shuts itself down, so that's not a problem. f5 works fine, there's nothing wrong with the script.

Yeah, not big on sharing code for cool things :-)
plus it's real simple code.
I don't mind of it take a whole day to render, I've got enough computers to leave one doing nothing else - just wish it would actually render.

well dropped the cylinders down to 12 facets, and the speheres to 20 and it finally rendered a 5x5 grid.

The pins and spheres are pretty small so it probably won't look that much different.
I'll knock them down to 10 and 15 and see if it'll do the bigger matrix.

Seems a pretty poor limitation though.

Quote:

---

Originally Posted by curious aardvark

well dropped the cylinders down to 12 facets, and the speheres to 20 and it finally rendered a 5x5 grid.

The pins and spheres are pretty small so it probably won't look that much different.
I'll knock them down to 10 and 15 and see if it'll do the bigger matrix.

Seems a pretty poor limitation though.

---

Yeah... Well... It is a huge amount of computation to go look for intersections and stuff. I feel sorry for my computer every time I tell it to render something big and tedious like that. If you wanted to get clever, you could make the tops of the pins a polygon. That would be fairly fast to instantiate on each pin and the computation would not be that bad. And for that matter... If you made the pins polygons, I bet your problems go away. The big problem is defining those polygons is a real pain in the @$$.

weeelllll, one problem went away - with reduced facets it will render larger grids. But says the resultant model is not a 2 level manifold.
ie: has holes and probably won't print properly. At least I think that's what it means.

Far as I can see nothing has changed in the model layout - no reason why it should.
So why on earth should fewer facets stop it being manifold ?

It gets weird. with 75 facets set globally 2x2 grid renders without any error messages. with 50 facets I get the error message. With 55 - I don't.
Currently workijg my way up to find the facet threshhold that starts generating the error messages.
Then I'll apply it to the individual cylinders and sphere and try to isolate the part that's causing the problem.

weird.

It gets weirder.
If I set global facets to 10 and the sphere facets to 50 - it renders without error. yet with global facets at 50 you get an error.

well - it'll now render a 5x5 with 25 facet speheres (which'll print smooth, my machine's not that precise).

top view
Attachment 5977

bottom view
Attachment 5978


Right I'll try for some larger matrixes and see what happens :-)

Okay I now get the:

Quote:

---

WARNING: Object may not be a valid 2-manifold and may need repair! See http://en.wikibooks.org/wiki/OpenSCA...ort_and_Export WARNING: Exported object may not be a valid 2-manifold and may need re

---

message on exporting the stl file.
Don't get it on render though.
This is just weird. I'm going to have to try and print it to see if there are any actual issues.

Usually when you get non-manifold stuff in OpenScad it is because you are taking the difference of two things where the edges are at the same location.

This is problematic:

Code:

---

difference() {
cube([50,50,50]);
cube([25,25,50]);
}

---

You will usually even see the 'phantom' edge in the picture that OpenScad renders. Instead, doing something like this produces a clean manifold:

Code:

---


difference() {
cube([50,50,50]);
translate([-.001,-.001,-.001]) cube([25,25,55]);
}

---

ah - yes I usually do the second thing. haven't bothered for this script, so that probably make sense.
And I rendered, exported (both with error message) and printed a 5x5 without any issues - so basically I think I can just ignore the message.
It is actually creating a printable and manifold model.

Cheers for the help Roxy, appreciated :-)

Going to try for a 30x20 grid. 600 pins and around 15x10cm
no idea how long it'll take to render - even at the low facet numbers.

that's the main thing that's missing from this version of openscad - it used to tell you how long a render had taken. It doesn't any more. I used to find that really useful.

You know... I just had a thought... Do you have to render the entire thing? If you were to render a 1" x 1" section of it and place copies of that next to itself on the build plate, you could go to any size that made sense. Or if you wanted to keep it all in source form, with the new OpenScad you could render the 'child()' object and then use that in a multiple for() loops to make it as big as you wanted. The way OpenScad handles children is it only calculates and renders it once, and then it gets used again and again by the parent. It would probably dramatically cut down on the processing time. Maybe you could go crazy and use a very high $fn number and not bog things down.

You would just have to make sure the pattern replicated faithfully in all directions.

Quote:

---

you could render the 'child()' object and then use that in a multiple for() loops to make it as big as you wanted.

---

thought that was what I did by using modules - but please explain. I am using loops with modules. No clue as to how you render one bit and then use it in another bit.

And yeah i did think about arranging a bunch of 5x5's on the printbed - but it's a bit tricky getting them all exactly the right distance away from each other. Auto arrange doesn't seem to come with a user definable distance.

And it still crashes with a big grid :-(

Quote:

---

Originally Posted by curious aardvark

thought that was what I did by using modules - but please explain. I am using loops with modules. No clue as to how you render one bit and then use it in another bit.

---

In the latest release of OpenScad... Goto File/Examples/Advanced/Children.scad

I think there is a good chance you can do what ever size and complexity you want using that way to structure your code.

glad about that ' cos I've found openscads breaking point :-)

Quote:

---

WARNING: Normalized tree is growing past 4000 elements. Aborting normalization. WARNING: Normalized tree has 7123 elements!
WARNING: OpenCSG rendering has been disabled.

---

that's a 40x30 grid.

Oh yeah if I use 9 facets for everything - It doesn't actually crash :-)
20x15 seems to be the limit.

Well that's a very clever script - can't say any of it make much sense to me though.

Although the text makes sense - was wondering how to use the new text command.

But as far as the rest of it goes - that's just not how I write scad scripts. What's with putting modules last ? That's just illogical

And while I did see a children(); command - not the foggiest what it's doing.

This is the problem I have with the openscad manual - it's written by programmers for programmers. And I was never a programmer :-)
What's with indenting everything - that really makes it difficult to see where a command line actually ends.

So in words of one syllable - what does children do and how do I use it ?

ps. I have stitched 2 15x20 boards together to make a 30x20 in s3d.
first time I've seen the s32d slicer really struggle lol

Now I've got to try and print the bastard lol

Quote:

---

Originally Posted by curious aardvark

And while I did see a children(); command - not the foggiest what it's doing.

...

So in words of one syllable - what does children do and how do I use it ?

---

OpenScad compiles everything for every place it is used. But children() is sort of an exception to this. It compiles the code to do the child and then just keeps re-using it for the module referencing the child(). So that dramatically cuts down on the work (and memory) that needs to be done to generate the object you are building.

The syntax for child() is the same as doing simple things like translate([0,0,0]) something(). If you define a module that references a child, then you just say

my_module() the_child_it_references();

And my_module() could go into a big loop placing the_child_it_references() a bunch of times even though it is only calculated once.