Cura: [4.6.1] Tree Support inconsistent placement

[Asterchades]

Application version
Tested with 4.6.1, and Master 20200610.

Platform
Windows 10 x64 Pro (2004)

Printer
Custom profile (attached in full)

Reproduction steps
1) Enable Tree Supports
2) Slice model
3) Refresh and slice model again (without changing settings)
4) Repeat 3 as necessary

Screenshot(s)
(Image showing the problem, perhaps before/after images.)

Actual results
Note that the two above images have identical settings. The only difference between them is that the model has been refreshed (F5, unchanged source file) and re-sliced. It took about 5 attempts to reproduce for the purposes of this report.

Expected results
The results should be the same every time - ideally more towards the second picture, since that's providing additional support where it is actually needed.

Project file
space_marine_-_assault_cannon.3mf.zip
Profiles.zip

Log file
(See https://github.com/Ultimaker/Cura#logging-issues to find the log file to upload, or copy a relevant snippet from it.)

Additional information
I realise that Tree Supports are still experimental, thus this is unlikely to be a high priority. However I feel they're worth pursuing - on this model they save around 30 minutes of overall print time. Might not seem like a lot, but that's 45 minutes with trees and 1:15 hours with regular supports, so it's a fairly big time saving in relative terms.

I'm also wondering whether it would be worth independently calculating an Interface if it's used. Tree Supports yield a very irregular Interface, which can have substantial gaps in some circumstances. I can't help but feel if the Interface were calculated the same as traditional supports than the trees would allow for more even support with more sparse tree settings.

[Ghostkeeper]

Seems to be some sort of race condition in there.

[Ghostkeeper]

Actually, no, the effect is still there if I disable OpenMP.

Maybe it's accessing uninitialised memory somewhere? Got to run it through Valgrind...

[mahtDFR]

This is on our backlog as CURA-7547. Thanks for the report.

[Asterchades]

Trying out the 4.7 beta tree supports and touching back on this one.

So far, the consistency is much improved. I've not observed any variation at all when slicing and refreshing. However, I have noticed a couple of things:

Firstly, I'm not getting the tree up to the chin at all any more - on either side. It's still showing as being of an appropriate angle to receive supports but it's not having a branch reach up there. What makes this particularly weird is if I set the Branch Diameter to between 2.9mm and 3.0mm, I get the branch that comes up from the model's right arm to the right-hand side of the chin. It will then return once going past 4.5mm, but starts to get weird in the high 7s before disappearing at 8.0 and returning nearer to 10mm.

Secondly, the new trees don't appear to play nicely with the Support Interface; at least on the top. The interface doesn't get anywhere near as close to the model as the underlying supports do , which is likely to cause problems on the more organic-type models that the trees are better suited to. The following pictures show what I mean:


You can see beside the gun barrel(s?) that the interface is leaving a very large gap around the model. I suspect this is some kind of minimum horizontal offset which isn't being exposed in the settings or is being incorrectly applied from the set value.

Same model is in use for these tests with the same profile as at the start of this report. The only changes are that I've corrected the missing Support Wall since the "tree_support_enabled" condition is no longer valid, the layer height is at 0.12mm, and I reduced the Support Interface Line Width to 0.4 (matching the supports) in case this was causing the issue.

[Ghostkeeper]

We still have an open bug that the Z distance at the top is incorrect: https://github.com/Ultimaker/Cura/issues/5759

We also know of a bug that the X/Y/Z distance priority isn't held correctly, so also the X/Y distance is different from how the original support works (depending on the priority set for normal support). This wasn't reported from Github so you can still report it here if you like to track it.

The original issue in this thread was fixed. (Thanks for the report! We hadn't noticed this ourselves until you reported it.) To prevent having an all-encompassing bug report, please refer to the other bug or create a new one if it doesn't apply!

[Asterchades]

Fair call. I'll await the next beta (changelogs withstanding, of course) to make any additional reports, since it seems like you may already know about what I'm seeing anyway as something of an "in progress" change already.