[4.9.0] Tree Support Roof not Complete

[CCS86]

4.9.0 / Win10 x64

When using tree supports and enabling support roof, the support roof area seems defined by all the little tree branches, rather than by the actual part geometry being supported, as I would expect:

This generates a ton of tiny print and travel moves, leaving a very incomplete support roof.

SupportRoofBug.3mf.txt

[fvrmr]

Hi @CCS86 thank you for your report. I will discuss this with the team. Keep you posted!

[Ghostkeeper]

This is currently expected behaviour. The support interface is part of support and being split off from the support areas, not generating interface area if there is nothing to interface with below.

We can consider changing this behaviour, but implementation-wise this is a bit like mixing the two support structure types. You'd have to generate the area support for the support interface, split off the support interface and delete the rest, then modify the collision areas for tree support to pretend that the generated support interface is part of the model and generate the tree support. It can certainly be done, but it's a bit of an architecture change.

[Ghostkeeper]

This change wouldn't solve the need for those travel moves. If the support interface would be generated as an area rather than as part of tree support, you'd have the tree support supporting that support interface, and you would have the same sort of travel moves in the last layer of tree support.

[Ghostkeeper]

After a quick discussion we've decided that this change is not worth the effort for now. I do think it would be somewhat better if we want to support PVA interfaces with tree support. For now, it's really just best to use tree support only with PLA for which it was designed. The small dots were explicitly designed for PLA.

[CCS86]

You certainly know more than I about how this is implemented. But, my personal experience says this is not some intrinsic part of the tree support algorithm. Here is the arachne beta build:

[Asterchades]

We can consider changing this behaviour, but implementation-wise this is a bit like mixing the two support structure types. You'd have to generate the area support for the support interface, split off the support interface and delete the rest, then modify the collision areas for tree support to pretend that the generated support interface is part of the model and generate the tree support. It can certainly be done, but it's a bit of an architecture change.

Surely it doesn't have to be that complicated. Both support structures will need to be generated (it's basically unavoidable) with the non-interface portion of the regular supports being discarded, but wouldn't it be possible to simply discard the tops of the trees? I can't imagine anyone caring whether the interface is too well adhered to the trees as a result of the larger contact point/s.

I can of course see one particular situation which might be problematic: simply discarding tree tops wouldn't stop a branch trying to go through an interface on top of another branch in the event a either a thicker interface is used or smaller X/Y/Z distance requirements are set. I'm unsure exactly how much of an issue this would present if left alone (how many times would this actually come up with 1-3 layer interfaces?) or how expensive it would be computationally to try and prevent it.

Note that I could be a little biased in wanting to see this implemented. I've recently been printing miniatures (in PLA) and have found trees give much better results in terms of horizontal intrusion and print times (plus they're worlds easier to remove), but the interface (3 layers) gives much better supported area results (and isn't as hard to remove as it possibly should be). Even PETG gives better results with the interface than without.

[Ghostkeeper]

You certainly know more than I about how this is implemented. But, my personal experience says this is not some intrinsic part of the tree support algorithm. Here is the arachne beta build:

If the tree support branch diameter comes close to or exceeds the distance between the branches, they merge together and indeed form a completely filled shape. That has the disadvantage though that the middle of these shapes is often not properly filled. Support interface can help with that, as in your picture. That doesn't really have anything to do with Arachne, but with some tweaking of the tree support settings you can get the effect you describe, yeah. Arachne makes the outline around support (the single wall of tree support) a variable-width wall, so maybe something changed because of that, if you've kept your settings the same?

For clarity, Cura will first generate the areas that are to be filled with support, then separates the interface from it, and then fills those areas with lines. The only difference between tree support and normal support is currently in that first step; tree support generates curvy areas. Afterwards, the interface is separated from that curvy area (everything N layers below the model) and then these are filled with lines. We just change the default fill density for support to 0% and set the support to have 1 outline by default if tree support is enabled, in the default profile. That's how it currently works.

To make the interface generate in different areas requires a re-think of this high-level process. You'd need to generate both of them, cut away everything more than N layers below the model for the normal support, and cut everything less than N layers below the model for the tree support. It can certainly be done, but it will need a significant change. You're welcome to give it a try, and I can give pointers as to where to start looking in the code. I don't think it's all too easy to get a maintainable solution though.

Currently the tip of a tree support branch also becomes thinner just before the branch reaches the model. This was designed with just a single wall in mind rather than the support also having an infill pattern. But maybe changing that is an easier solution.

[CCS86]

If the tree support branch diameter comes close to or exceeds the distance between the branches, they merge together and indeed form a completely filled shape. That has the disadvantage though that the middle of these shapes is often not properly filled. Support interface can help with that, as in your picture. That doesn't really have anything to do with Arachne, but with some tweaking of the tree support settings you can get the effect you describe, yeah. Arachne makes the outline around support (the single wall of tree support) a variable-width wall, so maybe something changed because of that, if you've kept your settings the same?

I'm not saying it is specific to Arachne (though, it could be), but something appears to have changed in the code base, between the point that the arachne build was forked, and the 4.9.0 release, because the arachne build behaves correctly, and 4.9.0 does not.

I uploaded the project file, so it should be easy enough to test in different releases, to get a better idea of where exactly the behavior changed. I tested in 4.8.0 and the interface is very fragmented, just like 4.9.0. I don't have anything older installed at the moment.

[CCS86]

Here is an example where the support roof gets more fragmented from start to end:

SupportRoofFrag.3mf.txt

https://user-images.githubusercontent.com/12439543/117592120-03afcf00-b0fd-11eb-8504-428c680df3ce.mp4