Where's the perimeters before infill option? (S3D)

[swbluto]

I have this piece with a detailed bottom layer, and I notice that S3D keeps printing the individual 'bits' before the perimeters. The bits, being as small as they are, don't adhere well and lack the support of the perimeters to keep them in-place causing half the bottom layer to be screwed up. How do I tell S3D to print the perimeters before the Infill? I remember this being an option in Slic3r and Cura, but it's seems it's not an option nor default behavior in S3D.

If I had the source code...

Sort paths by length.
Print longest paths first, going down the list.

So simple to implement, I'm sure. Does the developer need any help? I know .NET like the back of my hand!

Edit:

Well, I've found out that if I print the complex piece by itself, it does print perimeters first. It seems like it doesn't, however, when it's printing out more than one piece. It seems like the program doesn't ...

-Separate the objects in the multi-piece print into unique 'print objects', each 'print object' with their own unique perimeter and infill.

-Print the perimeters of each object before their infill....

...For multi-piece prints. It seems that program treats a multi-piece print as "one big print". I'm guessing that's probably what needs to be implemented. (Well, now that I think about it, it probably does print out multiple pieces correctly if they're added individually via S3D Model's menu, just not if the multi-piece print happens to be in one .STL file.)

[jsc]

There is no option to print infill before perimeters. Are you sure that's what you're seeing? Can you share your factory file?

[jimc]

if its one stl then it will be treated as such. if they are individual stls then they are printed individually. goto mesh/separate connected meshes and see if that makes a difference.

[ednisley]

If I had the source code...

Well, Slic3r lets you print infill or perimeter first (with speed tuning for everything), you can vary that setting on a per-volume / per item basis, it seems to handle non-manifold models no more poorly than the most recent version of S3D, plus you can modify the source code until it does whatever you want exactly how you want it done.

But, seeing as how you blew off Slic3r as "crap", I suppose none of that really matters... [evil grin]

[jimc]

lmao!

[insta]