Slicing error 'Coordinate outside allowed range' with sparse gyroid infill and fill_aligned_z

[mozotech]

What happened?

Slicing a simple box shape (30x60x15mm) generates an error ‘Coordinate outside allowed range’ when using gyroid for sparse infill with ‘aligned’ (fill_aligned_z) enabled. The problem also occurs with both of the honeycomb infills. (Problem does not occur with any infill pattern except gyroid, honeycomb and £D honeycomb). When sparse infill aligned is not selected the error does not occur.

Running SuperSlicer on Mac OSX 13.6.6 (22G630)

Used a clean installation of Superslicer (deleted and removed /Applications/SuperSlicer.app, ~/Library/Application Support/SuperSlicer, ~/Library/Preferences/org.SuperSlicer) Installed SuperSlicer_2.5.59.9_2024-04-30 Used configuration assistant to configure for ‘Creality Ender-3 BLTouch’ Used unmodified System Presets Print Settings: 0.20mm NORMAL Filament Settings: Reality PLA Printer Settings: Creality Ender-3 BLTouch 0.4mm

Problem occurs with latest successful nightly build ‘SuperSlicer_2.5.59.9_2024-03-22’ and produces a more informative error message

Project file & How to reproduce

To reproduce the error clear all remnaments of any previous SuperSlicer install. Download and install SuperSlicer_2.5.59.9_2024-04-30 Use configuration assistant to configure for ‘Creality Ender-3 BLTouch’ Use unmodified System Presets Print Settings: 0.20mm NORMAL Filament Settings: Creality PLA Printer Settings: Creality Ender-3 BLTouch 0.4mm Add 30x60x15.stl to platter Click 'slice now' Soon after the error dialog box will be displayed (stl model and 3mf attached in zip file)

Version

2.5.59.9

Operating system

macOS 13.6.6 (22G630)

Printer model

Ender 3 Pro (with SKR 1.3 mainboard and BLTouch)

[supermerill]

can't see the zip file.

[mozotech]

Added missing zip file (hopefully) 30x160x15.zip

[supermerill]

can't reproduce on windows, maybe a mac-only issue. will try on linux before.

[McFuzz89]

Can reproduce as well on a M1 Mac Studio trying both the ARM and Rosetta versions. Reverted back to 2.5.59.7 and no issues.

Steps to repro:

1. Blank canvass
2. Attempt to create a simple box sized 30x30x3 mm
3. Attempt to slice -> will see error.

However if you try doing a 30x30x2 mm sized box, it will slice fine. Possible related to layer height? I haven't tested that theory but worth trying it out.

[supermerill]

I understand where it crash: in the only intersection_pl call, as it's a clipper library error. but I don't understand why it crash only on macos. This intersection_pl call is also extensively used for overhangs detection: can you try to slice a becnhy with various overhangs_width_speed and overhangs_width (like 50% -100%, then 100% - 200%, then 25%-150% ....) (without gyroid infill, use rectilinear)

If you manage to crash it with overhangs, then I know what fix to revert as a stop-gap.

[McFuzz89]

I understand where it crash: in the only intersection_pl call, as it's a clipper library error. but I don't understand why it crash only on macos. This intersection_pl call is also extensively used for overhangs detection: can you try to slice a becnhy with various overhangs_width_speed and overhangs_width (like 50% -100%, then 100% - 200%, then 25%-150% ....) (without gyroid infill, use rectilinear)

If you manage to crash it with overhangs, then I know what fix to revert as a stop-gap.

Will in the AM and advise.

[mozotech]

I understand where it crash: in the only intersection_pl call, as it's a clipper library error. but I don't understand why it crash only on macos. This intersection_pl call is also extensively used for overhangs detection: can you try to slice a becnhy with various overhangs_width_speed and overhangs_width (like 50% -100%, then 100% - 200%, then 25%-150% ....) (without gyroid infill, use rectilinear)

If you manage to crash it with overhangs, then I know what fix to revert as a stop-gap.

Problem does not occur when sparse_infill is changed from Gyroid to Rectilinear (using SuperSlicer_2.5.59.10_2024-05-21, intel Mac Ventura 13.6.7) and setting permutations listed below. Benchy sliced successfully with all of them

Bridge Speed and Fan: (overhangs_width_speed)	Bridge Flow: (overhangs_width)
25%	50%
50%	50%
100%	50%
125%	50%
25%	100%
50%	100%
100%	100%
125%	100%
25%	150%
50%	150%
100%	150%
125%	150%
25%	200%
50%	200%
100%	200%
125%	200%

[supermerill]

will be hard to solve.

[McFuzz89]

Apologies for the delay - life, lol. I've taken a cue from mozotech and also can confirm that on the arm version, Gyroid fails. But I've gone a step further and the following infills all fail:

• Honeycomb
• 3D Honeycomb
• Gyroid

I've tried the three above with different permutations of overhangs_width_speed and overhangs_width (as a negative test) and they all fail regardless of the combination; the other infill options all seem to work fine.

[Icenowy]

Failed on a self-built Linux build, with gyroid/honeycomb infill.

[Icenowy]

I'm running SuperSlicer 2.5.59.10 inside GDB, and when the error pops up, I found the FillParams struct has max_sparse_infill_spacing as 140735984, which is quite weird.

[Icenowy]

The problem seems to be related to optimization here, with optimization flags of the compiler removed the failure do not happen.

[Icenowy]

It seems that the atomic_int64_t in PrintObject::_compute_max_sparse_spacing() isn't properly initialized. Add a (0) after its definition to initialize it seems to solve this problem.

[Icenowy]

See https://github.com/supermerill/SuperSlicer/pull/4279 .

[mozotech]

Rebuilt SuperSlicer_2.5.59.10_2024-05-25 on intel Mac,Ventura 13.6.7 incorporating Icenowy's pull request #4279. This resolves the problem on MacOSX, slicing with gyroid / honeycomb / honeycomb3d infill work and no longer generate the error.