SoftFever
Organic Tree Supports Printing in air
Is there an existing issue for this problem?
- [X] I have searched the existing issues
OrcaSlicer Version
1.9.1
Operating System (OS)
Windows
OS Version
Windows 10
Additional system information
No response
Printer
Sovol SV07
How to reproduce
Enable Support
Support Type: Tree(Manual)
Style: Organic
Layer Height 0.1 mm
Actual results
First 6 layers there are no trees printed. Then at layer 7 trees begin to appear. But since the print nozzle is quite far from the last printed layer, the trees don't print.
Expected results
Trees should be printing right from the build plate.
Project file & Debug log uploads
Checklist of files to include
- [ ] Log file
- [X] Project file
Anything else?
No response
Tweaking branch diameter seems to help a little. I hope organic tree supports will be getting some updates in the future. Cura seems to have a better (newer?) implementation in the current version. Also hoping for some more exposed parameters for organic tree supports (mabye support interface options, support infill, more diameter options).
Cube Support Issue.zip
this happens with the default settings as well which picks organic tree supports by default. 2.0.0 Dev Build as of 2024-03-03
This issue is not prioritized on my side at the moment. I've checked in PrusaSlicer and BambuStudio, and they both have this issue. It seems the bug is in the very upstream implementation (PrusaSlicer). I managed to mitigate/remove this issue by playing around with tree support parameters; you can also give it a try.
Orca bot: this issue is stale because it has been open for 90 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Probably won't be dealt with - as mentioned its an inherited problem coming in from PrusaSlicer code.
One thing I can confirm is that it doesn't matter if you use classic or aracne - it happens at the same place.
This issue is not prioritized on my side at the moment. I've checked in PrusaSlicer and BambuStudio, and they both have this issue. It seems the bug is in the very upstream implementation (PrusaSlicer). I managed to mitigate/remove this issue by playing around with tree support parameters; you can also give it a try.
"Playing around with settings" isn't really an option when some large items (targeting a giga printer or similar 1m³ volume) takes 30+ minutes to slice. Our items aren't little flexi lizards on a tiny Bambu 245mm machine. "Playing around" at 30mins a test can eat an entire day with just a few experiments and still get no where.
At the very least can you quantify what fields gave you the best results? Are these big organic supports more or less likely to split apart like this when the branch angle gets larger, for example. Does it get better or worse when using adaptive height? Or is just totally and completely random and the best someone can do is "jiggle the handle" like a runny toilet and hope they get lucky?
Orca bot: this issue is stale because it has been open for 90 days with no activity.
Please fix this. What's the point of supports if they aren't printable?
The supports get calculated almost as if they are layer shifted. The jump from one layer to the next is more than 5 perimeters distance with 2 perimeters as wall thickness resulting in unsupported supports: The irony abounds.
And we've all seen failed supports sometimes rebuild themselves thanks to bridging etc.
But not these - not when the path is circular. Its just a bloody mess.
managed to print one, didn't notice in the slicer (v2.30.0 build 70931e5), but remembered this issue any fix?
how has this not been fixed?
If I had to guess... Its a problem in upstream code inherited by OrcaSlicer. In the old days I'd guess it was in some kind of supports.dll that was already compiled and nobody downstream could work on. Today - I just don't know
Still happening with the latest version ❤️ 💙 💜 💖 💗 💘 ❤️ 💙 💜 💖 💗 💘 ❤️ 💙 💜 💖 💗 💘 ❤️ 💙 💜 💖 💗 💘
Just an observation...
while trying to find a specific thread about tree supports in mid air, I have realized just how many tickets there are for this problem - and how many people are subscribed to each one.
I think that really shows how significant this problem is and how many people are being badly impacted by it. It seems a bit less because the problem reports are 'spread around' across 10+ threads. if they were to be consolidated the real impact level might surprise the developers.