[CURA-13251] variable wall thickness for tree support#2347
[CURA-13251] variable wall thickness for tree support#2347Remco Burema (rburema) wants to merge 8 commits into
Conversation
NOTE: Applying another kind of smoothing would involve measuring wich areas touch which in subsequent layers (as opposed to just the branches -- branches can and will overlap, and there are even situations in which these shapes will diverge into clearly separated branches, only for another set of separations higher up to spread the now re-split branches wide enough that the areas overlap again) -- so this still can have some jumps in wall-thickness (on the splitting of larger brances), but should be smooth enough to be workable without making the code a lot uglier, or starting a large refactor. part of CURA-13251
Test Results31 tests 31 ✅ 5s ⏱️ Results for commit 1f6dda6. ♻️ This comment has been updated with latest results. |
Erwan MATHIEU (wawanbreton)
left a comment
Erwan MATHIEU (wawanbreton)
left a comment
There was a problem hiding this comment.
Some remarks and questions, maybe I also need some explanations
| [&support_part](const auto& res, const auto& elem) | ||
| { | ||
| return support_part.inside(elem.point) ? std::make_pair((elem.val.first * elem.val.second) + res.first, elem.val.second + res.second) : res; | ||
| }); |
There was a problem hiding this comment.
Would it be possible to do the wall thickness calculation earlier in the process ? This way you could use the TreeSupportElement structure, which contains the parent/children links between each unitary circle. That would save this (quite heavy) calculation completely, if I understand correctly.
There was a problem hiding this comment.
I'd love to, but instead of a single 'circle' or 'oval', for the resulting shapes, in practice, you get a blob representing different overlapping part of the tree that, from a data-structure perspective, don't even have to be 'adjacent' (but are in real 3D).
Take for instance two branches seeming to merge 'back' into each other higher up; they don't actually merge when it concerns the internal representation of the tree, but the shapes overlap (and thus are one 'unioned' shape).
Since we still want the shape to have one singular outline width, so the (weighted) average has to be taken somehow ... and because it can't come from the actual tree, the shapes have to be leading!
(I actually do calculate much of it earlier, just putting it into the locator; the 'nominal' wall width you see (later in the code, but earlier in the process) is just doing that, just instead.)
That said, I don't think the current solution is very elegant (for example, the way I relate the shapes to the center-points feels somewhat brittle, and as you say, it's not a cheap calculation), so please, if you have an idea for improvement, tell me.
There was a problem hiding this comment.
Well, I don't see the branches much overlapping higher after a previous split. Not saying that it cannot happen, but I think it is rare enough to be neglected (could definitely be proven wrong)
I think if you do neglect this aspect, then you can indeed base the whole calculation on the pure structural shape. But maybe I am missing something. Let's have a talk with drawing after the holiday, when this thing makes no more sense to us 😄
There was a problem hiding this comment.
Yes, let's get some paper when we're both back. Happy holidays!
part of CURA-13251 Co-authored-by: Erwan MATHIEU <erwan.mathieu@ultimaker.com>
- rename setting values - use clamp - remove 'reason' for header inclusion - add missing or 'missed' documentation in various places part of CURA-13251
2 participants
The general idea is that you don't want a lot of walls near the tips (and bottom, since we're going to have chamfered bases there, and the size of the branches there is wider anyway), but you do want the extra sturdiness with thicker/more walls more down (but again, not all the way down) in the tree -- without losing too much speed.
To that end, have a nominal wall-thickness and an 'enlarged' wall-thickness, the number of layers from either the bottom, or the top, and a number of walls to smooth out transitions.
(For these settings, see the front-end PR: Ultimaker/Cura#21717)
NOTE:
Since the trees' branches can overlap in the sense that the circles/ovals that are drawn can (and will frequently) get merged to larger shapes, and (because we want to keep the use of arachne to a minimum for helper structures where the shape doesn't need to be perfect) we want to keep the number of walls the same for each entire disconnected shape (which possibly contains a number of branches), there's at least one complication, for which I've made a compromise.
Most notably, the smoothing as is implemented is in essence quite simple, and can still induce more hard transitions when shapes of branches are finally split to distinct shapes. These jumps will usually not be quite as harsh, since the previous (lower) shape was the weighted average of the now distinct shapes. Furthermore, since branching happens upward, and while branches do merge, this happens more rarely, the branch more close to the tip (and therefore likely smaller), will have had less influence on the larger shape, and therefore make the larger 'jump' in wall-width; which is mostly OK actually , since a smaller wall (width) can go fine on a larger one. The jump from a smaller to a larger wall-width won't be quite as pronounced.
A typical case:
On the bottom, there's a gradient, until the shapes become distinct. On the left-side, the jump isn't quite as noticeable as on the right side. The jump on the right side isn't too bad in practice, since it jumps from larger to smaller walls instead of the other way around.
There are ways to fix this, but it would require either doing some quite messy things (like making a new 'tree' out of where the shapes actually overlap ... with all kinds of edge-cases like sometimes two distinct shapes can merge back) -- or there will have to be a refactor that is out of scope of this ticket.