Fix support interface semantics, gap handling, behavior; fix bottom interface generation for organic trees; fix non organic tree interfaces #1203

New Issue

MrUnknownDE · 2026-04-05T17:00:36+02:00

MrUnknownDE commented

2026-04-05 17:00:36 +02:00

Originally created by @kisslorand on 1/2/2026

Part I

Description

This PR fixes incorrect handling of zero-gap (direct-contact) interfaces for supports and raft by making contact semantics explicit, side-aware, and interface-aware.

Previously, a single soluble_interface flag derived from Support Top Z Distance = 0 was used to control multiple asymmetric behaviors. This was both functionally incorrect and semantically misleading: zero-gap contact is a geometric contact mode, not a material property. For example, non-soluble materials such as PETG can be used as separation interfaces for PLA prints due to low adhesion, even though no material is soluble.

Observed bugs

The bottom of supports could be forced into zero-gap contact with the object even when no bottom interface layers were present, causing supports printed with non-soluble or bonding materials (e.g. organic/tree supports without base interfaces) to be placed directly against the model.
When Support Top Z Distance was set to 0 but no top interface layers were used, the layer above was incorrectly assumed to sit on a dense interface and therefore was not printed in bridge mode, even though it was actually unsupported.
Non-soluble base interface layers were not consistently treated as interface layers, causing them to be skipped by interface interlacing logic and leading to incorrect stacking and interaction with surrounding support layers.

These issues stemmed from applying zero-gap behavior without checking whether interface layers were present and from coupling top, bottom, and raft contact logic through a single global flag.

What zero-gap contact controls

Zero-gap contact is a geometric mode that determines several behaviors beyond the Z distance itself:

whether supports or raft are printed in direct contact with the object (no air gap),
whether interface layers actually participate in separation or are effectively bypassed,
whether non-soluble base interface layers are required to support dense interfaces,
whether bridging behavior should be enabled or suppressed at a given contact surface.

What this PR changes

This PR replaces the global flag with explicit, independent zero-gap detection for:

top support contact (support → object),
bottom support contact (object → support),
raft contact (raft → object).

The rules are now:

Top contact is zero-gap only when top interface layers are present and Support Top Z Distance is 0.
Bottom contact is zero-gap only when bottom interface layers are present and either Bottom Z Distance is 0 or top contact forces contact mode.
Raft contact preserves legacy behavior: it is zero-gap when either Raft Contact Z Distance is 0 or Support Top Z Distance is 0.

Gap values are always explicitly initialized and only overridden when true zero-gap contact applies.
Generation of non-soluble base interface layers, interface heights, and bridging behavior is now handled independently per side, based on the actual zero-gap conditions rather than a single global assumption.

Non-soluble base interface layers are now also included in the interface interlacing logic, ensuring they follow the same stacking and interaction rules as regular support interface layers without introducing new layer types.

Tooltips for Raft Contact Z Distance, Support Top Z Distance, and Support Bottom Z Distance were updated to reflect the corrected zero-gap semantics and clearly indicate when values are ignored and direct contact is used.

Result

Supports without interface layers are no longer forced into zero-gap contact.
Bridging behavior is correctly applied when no dense interface is present.
Top, bottom, and raft contacts behave independently and predictably.
Legacy raft behavior is preserved.
Contact geometry is cleanly separated from material properties.
Non-soluble base interface layers correctly participate in interface interlacing.

Part II

Additional fixes and robustness improvements

While addressing zero-gap interface semantics, several related and previously hidden issues were uncovered and fixed, primarily affecting support interface spacing, smoothing, and organic tree support generation.

Interface spacing and density correctness

Top and bottom support interfaces were previously coupled in several places, causing bottom interfaces to inherit spacing, density, and smoothing behavior from the top interface, even when different settings were configured.

This addition:

separates top vs bottom interface spacing and density throughout support parameter propagation,
ensures bottom interface smoothing and toolpath generation use the correct bottom-specific values,
preserves existing behavior where ironing still forces solid top and raft interfaces, without affecting bottom interfaces.

This fixes incorrect parameter coupling and makes bottom interface behavior predictable and independently configurable.

Organic tree support fixes

Several bugs were identified in organic/tree support generation, particularly around bottom interfaces and non-zero bottom Z gaps:

Bottom interface contacts could be dropped entirely when base polygons were empty, causing supports to lose their intended interface layers. These contacts are now preserved through merge paths even when base slices are empty.
Bottom interface layers could disappear when Support Bottom Z Distance > 0, because contacts were incorrectly clipped using placeable-area logic intended only for direct-contact cases. This is now corrected so bottom interfaces are preserved when a gap exists.
Trimming empty slices at the start or end of organic branches could cause layer index drift, leading to misaligned geometry. Leading empty slices are now trimmed before indexing, and layer bounds are recomputed after trimming.
Degenerate polygon boolean operations (Clipper edge cases) could cause instability or failures. Additional safety offsets and tiny-area cleanup were added to make organic support generation more robust.

In other words, organic tree supports can now generate bottom interface layers when configured to do so. Previously, these were often suppressed by implementation issues, which led to the widespread assumption that organic supports had no bottom interface by design.

Result

Together with the zero-gap fixes, these changes:

restore correct bottom interface behavior across support styles,
ensure interface spacing, density, and smoothing follow the intended top/bottom settings,
prevent organic supports from silently losing bottom interfaces,
improve robustness against degenerate geometry in complex support trees.

Part III

Additional interface correctness fixes for non-organic tree supports

While validating the earlier interface fixes, several additional issues were discovered and resolved in non-organic tree support interface handling. These fixes address bottom interface generation edge cases, deterministic interface interlacing, and correct handling of mixed-material interfaces.

Bottom interface generation for supports starting above the model

Non-organic tree supports that start above the build plate (e.g. resting on internal surfaces or intermediate geometry) could generate missing or misplaced bottom interface layers. The previous logic incorrectly limited the number of bottom interface layers based on the object’s underlying layer numbers rather than the requested interface configuration.

As a result, valid configurations could silently lose bottom interface layers when supports did not originate from the build plate.

This logic has been refactored so the requested number of bottom interface layers is honored regardless of where the support begins relative to the object’s layer stack. This restores correct bottom interface generation for non-organic tree supports placed on internal geometry.

Deterministic interlacing of interface layers

Interlaced interface layers in non-organic tree supports could occasionally or always lose their intended alternation pattern, resulting in multiple consecutive interface layers sharing the same orientation.

The root cause was non-deterministic interface layer identification combined with shared state across layers.

This fix:

normalizes interface identifiers to the layers that actually generate roof and floor interfaces,
avoids shared mutable state by using per-layer fill instances,
explicitly computes interface alternation (e.g. 0° / 90°) from normalized layer indices.

As a result, interlaced interface layers are now generated deterministically and maintain the intended alternation across non-organic tree configurations.

Mixed-material interface handling

When different materials are configured for the support base and support interface, interface layers were previously always printed using the interface material alone. This ignored cases where contact (base-interface) layers are required.

Contact (base-interface) layers are interface layers printed with the base support material that sit between the support base and the dense interface printed with the interface material (soluble or not).

This change makes mixed-material interface handling aware of the relevant configuration inputs, including:

top and bottom Z gap conditions,
interface layer counts,
interface mode (zero-gap / separation),
and base vs interface material selection.

As a result, non-organic tree supports now generate the correct interface stack and material assignment instead of unconditionally printing the entire interface region with the interface material.

Non-organic tree support interface layer count semantics with independent support layer height

Previously, interface layer counts were interpreted as a fixed number of support layers, even when independent support layer height was enabled. This caused the effective interface height to vary unintentionally depending on the support layer height configuration.

Interface layer counts are now interpreted as a height expressed in multiples of the regular layer height, ensuring that the resulting interface thickness remains consistent and predictable regardless of whether independent support layer height is enabled.

This behavior is now correctly applied to non-organic tree support interfaces, restoring the intended interpretation of interface layer counts and aligning their behavior with established interface handling expectations.

Result

Together, these fixes:

restore correct bottom interface generation for non-organic tree supports starting on internal geometry,
ensure deterministic and reliable interlacing of interface layers,
make mixed-material interface behavior predictable and configuration-driven,
ensure interface layer counts represent consistent interface height even with independent support layer height enabled,
further eliminate cases where interface behavior depended on layer numbering rather than actual contact geometry.

Part IV

Further bugs were found and fixed:

organic tree support bottom interface layers didn't respect the number of layers set by the user -> fixed
non-organic tree support top interface layers didn't respect the number of layers set by the user -> fixed
non-organic tree support top interface layers had the 2nd layer overlapped/doubled -> fixed

Fixes #8887
Fixes #10763

Screenshots

Organic Tree Support with bottom interface layers defined (see bottom interface layer presence)

Before
After

Slim-Tree support, 25 bottom interface, independent layer height on (see interface height and placement)

Before
After

Slim-Tree support, 8 bottom base, multimaterial support (interface is soluble), rectilinear interlaced pattern for interface (check presence of base support material in the interface and the interlace of the support interface)

Before
After

Top interface spacing: 0.2mm, Bottom interface spacing: 2mm

Before
After

*Originally created by @kisslorand on 1/2/2026* ## **Part I** ### Description This PR fixes incorrect handling of **zero-gap (direct-contact) interfaces** for supports and raft by making contact semantics explicit, side-aware, and interface-aware. Previously, a single `soluble_interface` flag derived from Support Top Z Distance = 0 was used to control multiple asymmetric behaviors. This was both **functionally incorrect and semantically misleading**: zero-gap contact is a **geometric contact mode**, not a material property. For example, non-soluble materials such as PETG can be used as separation interfaces for PLA prints due to low adhesion, even though no material is soluble. ### Observed bugs - The **bottom of supports could be forced into zero-gap contact with the object even when no bottom interface layers were present**, causing supports printed with **non-soluble or bonding materials** (e.g. organic/tree supports without base interfaces) to be placed directly against the model. - When Support Top Z Distance was set to 0 **but no top interface layers were used**, the layer above was incorrectly assumed to sit on a dense interface and therefore **was not printed in bridge mode**, even though it was actually unsupported. - **Non-soluble base interface layers were not consistently treated as interface layers**, causing them to be skipped by interface interlacing logic and leading to incorrect stacking and interaction with surrounding support layers. These issues stemmed from applying zero-gap behavior without checking whether interface layers were present and from coupling top, bottom, and raft contact logic through a single global flag. ### What zero-gap contact controls Zero-gap contact is a geometric mode that determines several behaviors beyond the Z distance itself: - whether supports or raft are printed in direct contact with the object (no air gap), - whether interface layers actually participate in separation or are effectively bypassed, - whether non-soluble base interface layers are required to support dense interfaces, - whether bridging behavior should be enabled or suppressed at a given contact surface. ### What this PR changes This PR replaces the global flag with explicit, independent zero-gap detection for: - top support contact (support → object), - bottom support contact (object → support), - raft contact (raft → object). **The rules are now**: - Top contact is zero-gap only when top interface layers are present and Support Top Z Distance is 0. - Bottom contact is zero-gap only when bottom interface layers are present and either Bottom Z Distance is 0 or top contact forces contact mode. - Raft contact preserves legacy behavior: it is zero-gap when either Raft Contact Z Distance is 0 or Support Top Z Distance is 0. Gap values are always explicitly initialized and only overridden when true zero-gap contact applies. Generation of non-soluble base interface layers, interface heights, and bridging behavior is now handled independently per side, based on the actual zero-gap conditions rather than a single global assumption. Non-soluble base interface layers are now also included in the **interface interlacing logic**, ensuring they follow the same stacking and interaction rules as regular support interface layers without introducing new layer types. Tooltips for Raft Contact Z Distance, Support Top Z Distance, and Support Bottom Z Distance were updated to reflect the corrected zero-gap semantics and clearly indicate when values are ignored and direct contact is used. ### Result - Supports without interface layers are no longer forced into zero-gap contact. - Bridging behavior is correctly applied when no dense interface is present. - Top, bottom, and raft contacts behave independently and predictably. - Legacy raft behavior is preserved. - Contact geometry is cleanly separated from material properties. - Non-soluble base interface layers correctly participate in interface interlacing. ## Part II ### Additional fixes and robustness improvements While addressing zero-gap interface semantics, several **related and previously hidden issues** were uncovered and fixed, primarily affecting **support interface spacing, smoothing, and organic tree support generation**. ### Interface spacing and density correctness Top and bottom support interfaces were previously coupled in several places, causing **bottom interfaces to inherit spacing, density, and smoothing behavior from the top interface**, even when different settings were configured. This addition: - separates **top vs bottom interface spacing and density** throughout support parameter propagation, - ensures bottom interface smoothing and toolpath generation use the correct bottom-specific values, - preserves existing behavior where **ironing still forces solid top and raft interfaces**, without affecting bottom interfaces. This fixes incorrect parameter coupling and makes bottom interface behavior predictable and independently configurable. ### Organic tree support fixes Several bugs were identified in organic/tree support generation, particularly around bottom interfaces and non-zero bottom Z gaps: - Bottom interface contacts could be **dropped entirely when base polygons were empty**, causing supports to lose their intended interface layers. These contacts are now preserved through merge paths even when base slices are empty. - Bottom interface layers could **disappear when Support Bottom Z Distance > 0**, because contacts were incorrectly clipped using placeable-area logic intended only for direct-contact cases. This is now corrected so bottom interfaces are preserved when a gap exists. - Trimming empty slices at the start or end of organic branches could cause **layer index drift**, leading to misaligned geometry. Leading empty slices are now trimmed before indexing, and layer bounds are recomputed after trimming. - Degenerate polygon boolean operations (Clipper edge cases) could cause instability or failures. Additional safety offsets and tiny-area cleanup were added to make organic support generation more robust. In other words, organic tree supports **can now generate bottom interface layers when configured to do so**. Previously, these were often suppressed by implementation issues, which led to the widespread assumption that **organic supports had no bottom interface by design**. ### Result Together with the zero-gap fixes, these changes: - restore correct bottom interface behavior across support styles, - ensure interface spacing, density, and smoothing follow the intended top/bottom settings, - prevent organic supports from silently losing bottom interfaces, - improve robustness against degenerate geometry in complex support trees. ## Part III ### Additional interface correctness fixes for non-organic tree supports While validating the earlier interface fixes, several additional issues were discovered and resolved in __non-organic tree support interface handling__. These fixes address bottom interface generation edge cases, deterministic interface interlacing, and correct handling of mixed-material interfaces. ### Bottom interface generation for supports starting above the model Non-organic tree supports that start above the build plate (e.g. resting on internal surfaces or intermediate geometry) could generate missing or misplaced bottom interface layers. The previous logic incorrectly limited the number of bottom interface layers based on the object’s underlying layer numbers rather than the requested interface configuration. As a result, valid configurations could silently lose bottom interface layers when supports did not originate from the build plate. This logic has been refactored so the requested number of bottom interface layers is honored regardless of where the support begins relative to the object’s layer stack. This restores correct bottom interface generation for non-organic tree supports placed on internal geometry. ### Deterministic interlacing of interface layers Interlaced interface layers in non-organic tree supports could occasionally or always lose their intended alternation pattern, resulting in multiple consecutive interface layers sharing the same orientation. The root cause was non-deterministic interface layer identification combined with shared state across layers. This fix: - normalizes interface identifiers to the layers that actually generate roof and floor interfaces, - avoids shared mutable state by using per-layer fill instances, - explicitly computes interface alternation (e.g. 0° / 90°) from normalized layer indices. As a result, interlaced interface layers are now generated deterministically and maintain the intended alternation across non-organic tree configurations. ### Mixed-material interface handling When different materials are configured for the __support base__ and __support interface__, interface layers were previously always printed using the interface material alone. This ignored cases where __contact (base-interface) layers__ are required. Contact (base-interface) layers are interface layers printed with the __base support material__ that sit between the support base and the dense interface printed with the interface material (soluble or not). This change makes mixed-material interface handling aware of the relevant configuration inputs, including: - top and bottom Z gap conditions, - interface layer counts, - interface mode (zero-gap / separation), - and base vs interface material selection. As a result, non-organic tree supports now generate the correct interface stack and material assignment instead of unconditionally printing the entire interface region with the interface material. ### Non-organic tree support interface layer count semantics with independent support layer height Previously, interface layer counts were interpreted as a fixed __number of support layers__, even when _independent support layer height_ was enabled. This caused the effective interface height to vary unintentionally depending on the support layer height configuration. Interface layer counts are now interpreted as a __height expressed in multiples of the regular layer height__, ensuring that the resulting interface thickness remains consistent and predictable regardless of whether independent support layer height is enabled. This behavior is now correctly applied to __non-organic tree support interfaces__, restoring the intended interpretation of interface layer counts and aligning their behavior with established interface handling expectations. ### Result Together, these fixes: - restore correct bottom interface generation for non-organic tree supports starting on internal geometry, - ensure deterministic and reliable interlacing of interface layers, - make mixed-material interface behavior predictable and configuration-driven, - ensure interface layer counts represent consistent interface height even with independent support layer height enabled, - further eliminate cases where interface behavior depended on layer numbering rather than actual contact geometry. ## Part IV Further bugs were found and fixed: - organic tree support bottom interface layers didn't respect the number of layers set by the user -> fixed - non-organic tree support top interface layers didn't respect the number of layers set by the user -> fixed - non-organic tree support top interface layers had the 2nd layer overlapped/doubled -> fixed Fixes #8887 Fixes #10763 --- ## Screenshots ### Organic Tree Support with bottom interface layers defined (see bottom interface layer presence) - __Before__ <img width="902" height="351" alt="image" src="https://github.com/user-attachments/assets/0fa34ee2-721d-41ce-81a0-6a4c7525d58b" /> - __After__ <img width="908" height="350" alt="image" src="https://github.com/user-attachments/assets/44efa11b-2f6e-4926-82e8-b69827c7b820" /> ### Slim-Tree support, 25 bottom interface, independent layer height on (see interface height and placement) - __Before__ <img width="765" height="605" alt="image" src="https://github.com/user-attachments/assets/accffa36-79c2-4dc6-bc6d-0d01b407584b" /> - __After__ <img width="807" height="593" alt="image" src="https://github.com/user-attachments/assets/f0845ab1-dd01-47d6-9d38-f49a2388df4d" /> ### Slim-Tree support, 8 bottom base, multimaterial support (interface is soluble), rectilinear interlaced pattern for interface (check presence of base support material in the interface and the interlace of the support interface) - __Before__ <img width="900" height="631" alt="image" src="https://github.com/user-attachments/assets/43156724-d870-4e96-85a3-d72f584c2b87" /> - __After__ <img width="918" height="648" alt="image" src="https://github.com/user-attachments/assets/9411a59f-6e42-4b5e-971c-2e1aa98f8955" /> ### Top interface spacing: 0.2mm, Bottom interface spacing: 2mm - __Before__ <img width="1150" height="551" alt="image" src="https://github.com/user-attachments/assets/01f3ff72-e4cb-4bba-9e4d-f956655592c6" /> - __After__ <img width="1129" height="545" alt="image" src="https://github.com/user-attachments/assets/a189f841-eead-4d0a-8a4d-2d3d9ff05855" />

Sign in to join this conversation.

No Label bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix bug-fix

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1203