Automatic internal bridge infill direction may cause full bridges with cross hatch sparse infill, and fail the top layers of the print #1035

New Issue

MrUnknownDE · 2026-04-05T16:43:18+02:00

MrUnknownDE commented

2026-04-05 16:43:18 +02:00

Originally created by @Archomeda on 1/19/2026

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

bazzite-dx 43.20260101

Additional system information

No response

Printer

Creality K1 Max

How to reproduce

Have a model, e.g. cube.zip
- This model is a simple cube with 30x30x29 mm, and rotated 45 degrees
- I used a different model myself, but this simple cube is a good reproduction without having to share my model
Set the sparse infill pattern to cross hatch and direction to 45
Set the internal bridge infill direction to 0 (auto)
Set top shell layers to 3, and bottom shell layers to 3
Slice
Check the sparse infill and the layers above

Actual results

The last sparse infill layer has a direction of 0 degrees in the following screenshot.
Additionally, this direction has been the same for at least a couple layers.

Going one layer up, showing the internal bridge infill, this layer follows the same direction of its lower siblings of 0 degrees.

This results in a full bridge that spans from one edge to the other edge of the model, which is not printed correctly, especially on bigger models. Additionally, depending on the number of layers (as is the case with a 30x30x29 mm cube), the first internal solid infill layer also follows the same direction. In my case, the bridge layer sagged, and the solid infill on top of that did not end up smooth, and the layers above caused the nozzle to heavily grind into the model.

Expected results

The internal bridge layer direction should not follow the last sparse infill layer direction, and instead cross it (ideally with 90 degrees).

Project file & Debug log uploads

cube.zip

Checklist of files to include

Log file
Project file

Anything else?

I realize that I could have changed the internal bridge infill direction to anything else than 0, however:

I was not aware that keeping it 0 (auto) would cause any problems until I printed my model (I was not even aware of this setting), and auto suggests that it chooses the best direction itself.
In the model that I printed, I have more internal bridges that would've been affected by setting the direction manually and may have caused a conflict because they all follow the same direction, instead of an automatic calculation per bridge

It seems that this is caused by the unique combination of rotating a model 45 degrees, using cross hatch infill, and having just enough layers that it slices the layers with this direction.

*Originally created by @Archomeda on 1/19/2026* ### 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 bazzite-dx 43.20260101 ### Additional system information _No response_ ### Printer Creality K1 Max ### How to reproduce 1. Have a model, e.g. [cube.zip](https://github.com/user-attachments/files/24699259/cube.zip) - This model is a simple cube with 30x30x29 mm, and rotated 45 degrees - I used a different model myself, but this simple cube is a good reproduction without having to share my model 2. Set the sparse infill pattern to cross hatch and direction to 45 3. Set the internal bridge infill direction to 0 (auto) 4. Set top shell layers to 3, and bottom shell layers to 3 5. Slice 6. Check the sparse infill and the layers above ### Actual results The last sparse infill layer has a direction of 0 degrees in the following screenshot. Additionally, this direction has been the same for at least a couple layers. <img width="1230" height="1222" alt="Image" src="https://github.com/user-attachments/assets/d1f5aa69-4b11-47c0-9b73-df0eee12f6df" /> Going one layer up, showing the internal bridge infill, this layer follows the same direction of its lower siblings of 0 degrees. <img width="1223" height="1212" alt="Image" src="https://github.com/user-attachments/assets/939fdbb1-fda8-491b-8097-23128d8c1406" /> This results in a full bridge that spans from one edge to the other edge of the model, which is not printed correctly, especially on bigger models. Additionally, depending on the number of layers (as is the case with a 30x30x29 mm cube), the first internal solid infill layer also follows the same direction. In my case, the bridge layer sagged, and the solid infill on top of that did not end up smooth, and the layers above caused the nozzle to heavily grind into the model. ### Expected results The internal bridge layer direction should not follow the last sparse infill layer direction, and instead cross it (ideally with 90 degrees). ### Project file & Debug log uploads [cube.zip](https://github.com/user-attachments/files/24699259/cube.zip) ### Checklist of files to include - [ ] Log file - [x] Project file ### Anything else? I realize that I could have changed the internal bridge infill direction to anything else than 0, however: - I was not aware that keeping it 0 (auto) would cause any problems until I printed my model (I was not even aware of this setting), and auto suggests that it chooses the best direction itself. - In the model that I printed, I have more internal bridges that would've been affected by setting the direction manually and may have caused a conflict because they all follow the same direction, instead of an automatic calculation per bridge It seems that this is caused by the unique combination of rotating a model 45 degrees, using cross hatch infill, and having just enough layers that it slices the layers with this direction.

MrUnknownDE closed this issue

2026-04-05 16:43:18 +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

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/OrcaSlicer#1035