Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

overlaping models when using "duplicate" option with support_material_buildplate_only=1 #13464

Open
2 tasks done
el-bart opened this issue Oct 4, 2024 · 1 comment
Open
2 tasks done

Comments

@el-bart
Copy link

el-bart commented Oct 4, 2024

Description of the bug

when enabling support_material_buildplate_only=1 and adding --duplicate 2 command line option, resulting objects overlap, causing segv from slicer:

$ ./run 
10 => Processing triangulated mesh
20 => Generating perimeters
30 => Preparing infill
45 => Making infill
65 => Searching support spots
69 => Alert if supports needed
70 => Generating support material
Error: Potentially lost branch!, critical: 1
89 => Calculating overhanging perimeters
88 => Generating skirt and brim
[2024-10-04 18:58:14.428396] [0x00007f866e526d40] [error]   gcode path conflicts found between model.stl and model.stl
90 => Exporting G-code to model.gcode
Segmentation fault (core dumped)

looks like outside-of-model supports are not taken into account when calculating object size.
overlap_region

Project file & How to reproduce

download the model and config:
colliding_objects.zip
call ./run to build. observe segv. check output gcode.

Checklist of files included above

  • Project file
  • Screenshot

Version of PrusaSlicer

PrusaSlicer-2.8.0+linux-x64-GTK3-202406270929

Operating system

Debian/12

Printer model

Voron 2.4 with stealthburner

@neophyl
Copy link

neophyl commented Oct 4, 2024

No they are not. This has been reported multiple multiple times and a warning was added to the gui version. But the user still has to space the objects further apart. Either that or you merge all the objects into 1 object and the supports will then take that into account. This is the intended operation at the moment.
I wouldn't expect the command line to be any different.

For example
#10464
#10451
#10376
#10032
#9861
#9860
#9835
#9685
#9517
#9510
#8012
(list taken from a previous issue, now closed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants