[CURA-13251] variable wall thickness for tree support - #2347
Open
Remco Burema (rburema) wants to merge 13 commits into
Open
[CURA-13251] variable wall thickness for tree support#2347Remco Burema (rburema) wants to merge 13 commits into
Remco Burema (rburema) wants to merge 13 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
Contributor
Test Results31 tests 31 ✅ 5s ⏱️ Results for commit f12896d. ♻️ This comment has been updated with latest results. |
Erwan MATHIEU (wawanbreton)
left a comment
Erwan MATHIEU (wawanbreton)
left a comment
Contributor
There was a problem hiding this comment.
Some remarks and questions, maybe I also need some explanations
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
Erwan MATHIEU (wawanbreton)
approved these changes
Aug 13, 2026
part of CURA-13251 Co-authored-by: Erwan MATHIEU <erwan.mathieu@ultimaker.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.