FIX: order-independent overlap carving for multi-part objects#10383
Open
jomixlaf wants to merge 1 commit intobambulab:masterfrom
Open
FIX: order-independent overlap carving for multi-part objects#10383jomixlaf wants to merge 1 commit intobambulab:masterfrom
jomixlaf wants to merge 1 commit intobambulab:masterfrom
Conversation
When a ModelObject contains overlapping MODEL_PART volumes (e.g. a STEP file with embossed text extruded into a plate body, each assigned a different filament), the slicer's region carving in slices_to_regions iterates volumes in vector order and unconditionally diff-subtracts each MODEL_PART's slice from every preceding overlapping region. The "later wins" rule means a contained body listed before its container gets erased entirely by the container's later carve pass, and the body silently disappears from the slice and the gcode. The same scene with the contained body listed last slices correctly, which is why the "right-click -> change type to Negative -> change back to Part" workaround makes the issue go away: sort_volumes(true) runs a stable_sort by type that yanks the just-changed volume to a deterministic position, accidentally fixing the order. Because OCCT's STEP traversal order is not under user control (Fusion 360 in particular does not guarantee body order in exported STEP files), the bug is intermittent and has been chased for years. Resolve by making the carve order-independent: in any pair of overlapping non-negative MODEL_PARTs, the one with the smaller bounding-box volume always carves the larger, regardless of vector position. Negative volumes continue to always carve as before. Equal-bbox ties fall through to the previous "later wins" path, which is degenerate anyway. Behavior for non-overlapping volumes, single-part objects, modifiers, support enforcers/blockers, and negative volumes is unchanged.
2 tasks
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
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.
Summary
Fixes a long-standing intermittent bug where a contained MODEL_PART volume (e.g. embossed text extruded into a plate body, each assigned a different filament) silently disappears from the slice and the gcode whenever it happens to be listed before its container in the volumes vector.
Reproduction
The bug is intermittent because OCCT's STEP traversal order is not under user control and Fusion 360 does not guarantee a stable body order in exported STEP files. Sometimes the contained body lands first, sometimes last.
A known workaround: right-click the inner body → change Type to Negative Part → slice (it shows as a recess, proving the geometry is in the pipeline) → change Type back to Part → slice (now correct). The toggle works because
sort_volumes(true)runs astable_sortby type that deterministically yanks the just-changed volume to a particular position, accidentally fixing the order.Root cause
In
slices_to_regions(PrintObjectSlice.cpp), the carving loop iteratestemp_slicesin vector order and unconditionally diff-subtracts each MODEL_PART's slice from every preceding overlapping region:The "later wins" rule means a contained body listed before its container is fully carved out by the container's later carve pass and produces an empty region.
Fix
Make the carve order-independent for overlapping MODEL_PARTs: in any overlapping pair, the one with the smaller bounding-box volume always carves the larger, regardless of which appears first in the volumes vector. Negative volumes continue to always carve as before.
Test plan