Tree Support very rough causing printer vibrations

[jbalat]

Version 4.5.0 & 4.6.1

Windows 10 64bit

Geeetech A30 based on CR-10 profile

Experimental Tree Support Concentric 1 wall line 5% support density

The generated tree structure has a rough zig zag wall finish which makes the printer shake. The same wall can easily be approximated with a smooth path which will make it smoother, quicker and cause less stress to the printer.

[discip]

Good morning everyone, this is an issue I have been experiencing a lot and often I thought it would be a really nice thing, if the tree support would consist of smooth tangentially connected curves rather then steps. I use this feature frequently, because of its benefits of supporting overhangs without touching the actual print. I am aware of the fact that tree support is an experimental feature and I would not dare to state it a bug. Its just the fastest way to compute this kind of support. But as mentioned by @jbalat I and my printer too, would very much appreciate a smoother iteration of this almost vital feature.

thank you in advance kind regards

[Ghostkeeper]

This is somewhat inherent in the way that Tree Support creates branches. It does this by drawing octagons (as approximation of circles) around certain points. These points start at the top of the support, where the model has overhang, and traverse downwards and towards each other so that the branches join together as you go down. If these points are fairly close to each other but not too close, you get two "circles" that overlap for 99% with each other, and at the joints of these circles is a corner. What you're seeing is a bunch of these corners next to each other.

It already applies some smoothing to the result afterwards, which removes most of the corners. However if you smooth too much you get parts that hang in mid-air.

[kurtd5105]

This is somewhat inherent in the way that Tree Support creates branches. It does this by drawing octagons (as approximation of circles) around certain points.

Here is a clear demo of this (pretty cool): on a bladeless fan from thingiverse. I'm printing at 100mm/s and 1k accel which is normally fine but this is producing a violent vibration. Kinda my fault though I suspect even stock speeds it will still vibrate quite a bit which is obviously not ideal.

It already applies some smoothing to the result afterwards, which removes most of the corners

Is there any data on this? I'm seeing lots of rough edges, even worse if we take the z-axis into account. I get that it's experimental and I think in general it provides great results with minimal filament waste and the easiest possible supports to remove. However, the smoothing applied to it definitely lacks polish. Increasing the "Tree Support Collision Resolution" helps, but only goes so far: this is 0.5mm for the setting, 0.2mm is default. @jbalat and @discip you might have luck increasing this value, but at larger values the octagon supports degrade (can lower poly count, which isn't actually smoother).

One example on how to fix the smoothing: the colliding octagons could have the edges with collisions removed, and then have smoothing applied between the remaining points (between closest edge vertices). If many connect, it could interpolate between them. It could also do this for the z-axis to overall have a smooth surface. Playing with the collision resolution in Cura it appears like the current implementation drops the poly count? That's only smoother when they collide close together, when they don't collide they're even worse.

[Ghostkeeper]

It already applies some smoothing to the result afterwards, which removes most of the corners

Is there any data on this?

I can generate some anecdotal data for you. I sliced a file using default Tree Support settings for the Ultimaker S5 (collision resolution 0.175mm). I set the infill to 0%, wall thickness to 0mm, top/bottom thickness to 0mm and disabled adhesion, so the only g-code generated is the tree support. This resulted in a file of 489.3kB, estimated printing time of 29 minutes. Then I removed this line of code from CuraEngine and sliced again. Now it produces a file of 1.6MB, which takes an estimated 37 minutes to print. So it appears that in this case, it removed about 70% of the lines. Likely it was slightly more, accounting for overhead and travel moves between support pieces.

I'm seeing lots of rough edges, even worse if we take the z-axis into account.

This is the problem really: The more smoothing is applied to the layer, the more it will deviate from the previous layer. The current smoothing limits the deviation to the "collision resolution" setting. This is not really the intention of the collision resolution; as the setting documents, it's intended to determine how precisely the collision volumes are being calculated. But it's probably what the user wants, since the collision resolution must also be at least precise enough to prevent lines in subsequent layers from deviating by an entire line width; they would be placed next to each other instead of on top of each other. Set the collision resolution too high and you'll see that the jitter in these lines causes gaps to appear in the support wall, which compromises its stability greatly.

What we'd need is a smoothing function that doesn't just remove vertices but actually smooths polygons using curves. And one that still guarantees a certain maximum deviation.

[kurtd5105]

So it appears that in this case, it removed about 70% of the lines. Likely it was slightly more, accounting for overhead and travel moves between support pieces.

Thanks for taking the time to generate that data. That definitely proves it takes out a lot of vibrations already but as you mentioned it has its limitations, particularly in the z-axis which would compromised integrity.

What we'd need is a smoothing function that doesn't just remove vertices but actually smooths polygons using curves. And one that still guarantees a certain maximum deviation.

Agreed, and as I mentioned it likely could be applied across the remaining vertices in all directions instead of relying on the generated polygon shape itself. Essentially it would look like the faces of the generated supports are smoothed.

When my print completed the supports looked like they had ghosting, but it was actually just trying to follow a very jagged line. This didn't mess with the print itself, but the support was actually vibrating back and forth as it printed, no idea how it actually managed to stick. In the future I can try and tune the value so there's reduced likelihood of the support failing due to it vibrating itself while printing. I just think that to make tree supports functionality more polished, smoothing should ideally prevent these outright.

I also agree the user probably doesn't care about the technical definition of things. These supports are a very useful but complicated tool, since they're optimized to reduce the amount of supports required to a bare minimum. End users just want the feature to work and not produce side effects like massive vibrations. These could cause the supports to fail or the part to break free, granted it doesn't help if you print at high speed or accel. Perhaps just a warning when using accel control or setting to a high speed while using tree supports would be a simple quick fix while it's determined if a different algorithm is worth implementing.