Replies: 1 comment
-
One additional observation why proper support for that type of modifier would be better than the hack described above - Orca might still try to generate supports anchored on top of the "hack" volume with no shell or infill. Unfortunately, they are unlikely to work if started in thin air (if it was possible we wouldn't need supports at all 😁) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
After messing a bit with paint-on supports, and support blockers and enforcers, I realized that they all control where the supports will attach to (or, in other words, what they will support). But there is no way to control where the support will "grow out" from. E.g. excluding parts of build plate, or parts of the model itself. This is actually a somewhat frequent problem for functional parts (hinges, brackets etc) - let's say you have a (relatively small) vertical hole in your model, and somewhere above that hole, an overhang needing support. You of course mark the overhang as needing support, and then Orca will absolutely insist on printing supports inside the hole. Where they will be a royal pain to remove, and also quite useless (the hole does not have enough top surface to contribute to the support in a meaningful way).
There is no intended way to block this. Support blockers can't control where the supports can't grow out from, only where they can't attach to. Negative parts are applied before support generation, so the supports will happily grow into spaces created by them. I have found a hack to achieve what I want - I can add a positive part, and set it to 0 walls, 0 infill, 0 top shell, 0 bottom shell. This results in empty space but Orca will consider it part of the model and not print anything inside it, including supports. But it's still very much a hack - it cannot intersect with the real parts of the model, or it will cut holes through it (EDIT: it can actually, just need to change the order in object tree); also it's a total pain to manage (it just looks and acts like any other part of the model, and you can't visually distinguish it from the rest).
I'm wondering if anyone else sees it as a problem worth creating a feature request for. I think the hack described above could be rather easily adapted into a proper new modifier type, called "support excluder" or something (of course I don't know Orca's code so I might be grossly overoptimistic) - it would just have to be applied before the actual model parts, not after (so it does not cut holes in them; EDIT: I just realized I can reorder objects in the object tree and it's literally a matter of proper order), and have some proper UI controls (like showing it in a different color in the "Prepare" tab ;) )
Beta Was this translation helpful? Give feedback.
All reactions