Simplify3D User Forum

That example file is just that: A terribly obvious explanation of the issue to expose it. I'm not printing stuff that exposes the bug as directly as that, and you're right, without additional support on the sides it would probably tip before connected. And in that case I'd be happy to go in and manually place some support pillars to hold it up.

What I'm printing is akin to a cave roof with stalactites : S3d Won't catch any of the stalactite tips, so you have to manually place support for them all: If you miss any, you get spaghetti pouring from the roof of your cave. And sometimes this is non-trivial based on how the model was created, with external bits occluding the interior, and the already-existing support blocking your view as well (see below).

I encounter this issue infrequently, but that's where the problem lies: It's infrequent enough that I forget it's a problem. I expect the slicer to place supports where it should: If something is suspended in the air, and you tell your slicer to provide auto-supports, it's ironic it supports everything but the feature that need it most.

Here's another example:

Best model evar! Time to print! Auto-added supports. Super supported no doubt: Wait, why is part of it completely unsupported? So trying to find all these unsupported areas while surrounded by valid support becomes a real pain on an asset more complex that this.

I haven't tried it myself but am guessing you would still need to change the minimum support angle. Just because it is upside down doesn't mean it isn't still below the minimum threshold, which that upside down cone looks to be. I will have to try it myself to see. But I could see how that would be frustrating.

Like mentioned previous, those are perfectly valid angles to print, far within most printers tolerance for overhang. I shouldn't have to globally create more support than is needed to resolve an issue with a feature missing from the software, considering other slicers already do this.

This post isn't about how "How can I print this successfully in S3D?": Sure, I can add manual support based on visually inspecting the model (inaccurate because a human is doing it), or drop the support threshold so much that everything is supported, whether it needs it or not (waste of print time/material). My goal is to illustrate this bug (and I considering it a bug) to S3D so they'll update their slicer to address it automatically.

Here's a perfect example: A cube, suspended in space, rotated 45 degrees on two axes. It could be part of some larger print, connected beneath it. (Based on default values) S3D will generate no automatic support beneath it, since the 45 deg angles are completely valid for print: But obviously this print would end up like a pile of spaghetti.
Of course if you modify the overhang angle to something much lower the supports will show up, but again, you're wasting material at this point to compensate for the software's blindness to the problem.

I supposed I see it your way and I can see it the way the computer is looking at it. If you say not to print support under a certain threshold then its not going to. It either is or it isn't...yes or no...its a computer 1 or 0. I fooled around a little with some cubes suspended and not with flat bottoms and not rotated so there are not equal angles on every side. This factory file is set with support threshold of 38 degrees and you can see some sides get support and others don't. If you lower it you see that flat bottom get support only under the flat area and the pointed don't. Again...I understand where you are coming from...and I understand these are very simple models...so I am limited to seeing what you may be seeing in a more complex print...but it seems like depending on what way you are looking at it from, that it is working properly.

I agree that the software is looking at it very black and white. The problem is, it's colorblind: It doesn't know it's missing this feature, thus it's not computed. S3D only deals with overhang, it appears to have no concept if an item is touching the build platform or not.
Let's compare against other slicers: Makerware, Cura, and Slic3r can all do this, easily. No crazy tweaking is needed. No compensating for overhang angles, because this isn't an overhang issue. This is an 'unsupported floating feature' issue.

This either falls into a bug category, or missing feature category. I really don't care which, but I'd sure like it to be "supported" (get it? )

AK_Eric wrote:This either falls into a bug category, or missing feature category. I really don't care which, but I'd sure like it to be "supported" (get it? )

I vote bug...

I tried your model with Kisslicer and got the same results as S3D. Can you do the same and post results?

I've never used Kisslicer before, but I gave it a shot: Looks like (unless we're both missing it) it suffers from the same problem S3D has, and wouldn't support that feature either. I couldn't find any setting to make it work. Updated the image:

To add insult to injury, ReplicatorG passes the test. Man I forgot how slow that slicer is, and reminds me how much I love S3d

Anyone have a chance to check if this was one of the bug fixes in 3.01?