Support interface layer doesn't properly support edges or higher angle surfaces with low "Top Z Distance" #1643

Open
opened 2026-04-05 18:51:16 +02:00 by MrUnknownDE · 0 comments
Owner

Originally created by @novirium on 11/12/2025

Is there an existing issue for this problem?

  • I have searched the existing issues

OrcaSlicer Version

2.3.1

Operating System (OS)

Linux

OS Version

Arch, latest

Additional system information

No response

Printer

Bambu Lab P1S

How to reproduce

  • Add a model with an angled overhang (either a bottom curved surface, or a primitive cube rotated 25 degrees)
  • Enable normal supports, with a second filament for the support interface material, accepting the recommended changes.
  • Set the support threshold angle a little higher to 30 degrees (as is often used with a separate support material)
  • Set the "Top Z Distance" to 0 (like you would if using a separate support material)
  • Set the "Support/object xy distance" to 0.35mm (the default)
  • Slice the object

Actual results

There is a gap on each layer between the support interface and the object above it (caused by the "Support/object xy distance").

Expected results

The vertical gap between the support interface and the object above should be 0mm (the "Top Z Distance") - as this is the whole point of the support being there.

Project file & Debug log uploads

Support Interface Test Cube.zip

Checklist of files to include

  • Log file
  • Project file

Anything else?

I've seen this raised before, but these are now stale and closed - here and here.

The issue is particularly apparent when trying to use support material on a bottom curved surface, as the support interface pulls away as the angle from horizontal increases. For the default X-Y support distance of 0.35mm, at 0.2mm layer heights it doesn't touch at all past 30 degrees. For 0.12mm layer heights it's even worse - it doesn't touch at all past 19 degrees from horizontal.

In these situations (say, the bottom of a sphere or cylinder, or other organic curved surface) this issue is the difference between a support material interface leaving a perfectly smooth surface or a droopy mess (I've had prints fail due to this issue).

Bambu Studio has introduced a "Z overrides X/Y" parameter to deal with this, though I'm not confident it's implemented particularly well.

I do wonder if a simpler solution may be to apply the XY and Z distance limits separately to the support body, and the support interface layers, introducing a "Support interface/object xy distance" parameter? After all, that's the root cause of the problem - the main body of the support and its interface layers are being printed as different materials, and we'd like separate control of the parameters (the main support body needs to be further from the main object to avoid sticking, but the interface should often be touching directly)

*Originally created by @novirium on 11/12/2025* ### Is there an existing issue for this problem? - [x] I have searched the existing issues ### OrcaSlicer Version 2.3.1 ### Operating System (OS) Linux ### OS Version Arch, latest ### Additional system information _No response_ ### Printer Bambu Lab P1S ### How to reproduce - Add a model with an angled overhang (either a bottom curved surface, or a primitive cube rotated 25 degrees) - Enable normal supports, with a second filament for the support interface material, accepting the recommended changes. - Set the support threshold angle a little higher to 30 degrees (as is often used with a separate support material) - Set the "Top Z Distance" to 0 (like you would if using a separate support material) - Set the "Support/object xy distance" to 0.35mm (the default) - Slice the object ### Actual results There is a gap on each layer between the support interface and the object above it (caused by the "Support/object xy distance"). ### Expected results The vertical gap between the support interface and the object above should be 0mm (the "Top Z Distance") - as this is the whole point of the support being there. ### Project file & Debug log uploads [Support Interface Test Cube.zip](https://github.com/user-attachments/files/23497968/Support.Interface.Test.Cube.zip) ### Checklist of files to include - [ ] Log file - [x] Project file ### Anything else? I've seen this raised before, but these are now stale and closed - [here](https://github.com/SoftFever/OrcaSlicer/issues/6014) and [here](https://github.com/SoftFever/OrcaSlicer/issues/2162). The issue is particularly apparent when trying to use support material on a bottom curved surface, as the support interface pulls away as the angle from horizontal increases. For the default X-Y support distance of 0.35mm, at 0.2mm layer heights it doesn't touch at all past 30 degrees. For 0.12mm layer heights it's even worse - it doesn't touch at all past 19 degrees from horizontal. In these situations (say, the bottom of a sphere or cylinder, or other organic curved surface) this issue is the difference between a support material interface leaving a perfectly smooth surface or a droopy mess (I've had prints fail due to this issue). Bambu Studio has introduced a "Z overrides X/Y" parameter to deal with this, though I'm not confident it's implemented particularly well. I do wonder if a simpler solution may be to apply the XY and Z distance limits separately to the support body, and the support interface layers, introducing a "Support interface/object xy distance" parameter? After all, that's the root cause of the problem - the main body of the support and its interface layers are being printed as different materials, and we'd like separate control of the parameters (the main support body needs to be further from the main object to avoid sticking, but the interface should often be touching directly)
MrUnknownDE added the bugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbugbug labels 2026-04-05 18:52:02 +02:00
Sign in to join this conversation.
No Label bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug bug
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1643