Fix sequential print collision check depending on object list order

[KuzuriAo]

Hi @zackaree-shen,

I believe this is a solid fix for issue #586 that we were discussing.

Fix sequential print collision check depending on object list order, not actual geometry

The bug

I ran into this with models designed for Bambu printers, mostly 3mf files pulled from MakerWorld. They'd slice and print fine in Bambu Studio on an actual Bambu printer. But opening the same file in Snapmaker Orca (or Orca) and switching the printer profile over to a Snapmaker U1 would sometimes throw "Assembly is too tall, and collisions will be caused.", error.

That's was the hint that this isn't a real geometry problem. If a file slices and prints cleanly on in Bambu Studio on a Bambu printer, there's no physical reason it shouldn't also slice cleanly on a Snapmaker U1 or any other printer. Swapping the printer profile doesn't change the objects' heights or positions relative to each other. So the error had to be coming from the slicer's own collision check, not from an actual collision.

That's what turned up in sequential_print_clearance_valid() in src/libslic3r/Print.cpp. It's supposed to check whether a sequential print's object heights and positions can actually be printed without the toolhead colliding with already-finished objects. Instead, it just sorts objects by their raw position in the object list (object_index) and checks clearance against that order. If the list order happens to put a tall object before a short one it shouldn't, you get the "too tall" error, even when a valid, non-colliding print order exists. Since a 3mf's object-list order is just an artifact of how the file was authored (Bambu Studio, MakerWorld, whatever produced it), and not something the printer profile changes, this made the error effectively random with respect to which printer profile you picked.

The workaround right now is cutting an object out of the model and pasting it back in, which reshuffles its position in the object list and sometimes gets you a list order that happens to work. That's luck, not a fix, and it's easy to end up with a file where no amount of cut/paste helps because the check was never actually looking for a valid order in the first place. It was just checking the one it was handed.

There's also a disabled (#if 0) block above the current logic that tried to solve this properly with a score-propagation heuristic, but it wasn't guaranteed to converge and was turned off.

Where "the object list" actually is

The object list lives in 3D/3dmodel.model, in two places that stay in lockstep: a <resources> block with one <object id="N"> entry per top-level printable object, and a <build> block with one <item objectid="N" transform="..."> entry per instance placed on the plate. Whatever order those entries appear in the XML is the order libslic3r assigns as each object's object_index when it loads the file. It's just file order, with no geometric meaning at all. (Each <object> can itself be a multi-part "Assembly": several sub-meshes with their own per-part extruder/color assignments merged into one printable item, which is exactly what the "Assembly is too tall" wording refers to; that's a separate, unrelated feature from the ordering bug.)

I confirmed this directly on one of my failing files, saved twice from the same project: once with a Bambu printer profile selected (worked fine) and once after switching to the Snapmaker U1 profile (threw the error). Diffing the two 3dmodel.model files, the geometry, transforms, and part assignments are identical. The only thing that changed is which of the two top-level "Assembly" objects (a shorter Hilt assembly and a taller Body assembly with arms and wings) is listed first:

Bambu-profile save:  <resources> order = [ Hilt (extruder 6), Body (extruder 3) ]
                      <build> order    = [ item objectid=Hilt, item objectid=Body ]

U1-profile save:      <resources> order = [ Body (extruder 3), Hilt (extruder 6) ]
                       <build> order    = [ item objectid=Body, item objectid=Hilt ]

Same two objects, same everything else, just swapped in the list. Under the old code, only the object printed last gets the full printable_height allowance; whichever one lands earlier is capped at extruder_clearance_height_to_lid. So depending purely on which of these two saves you opened, either the taller Body assembly got the "last" slot (fine) or the shorter Hilt did (Body then gets capped and throws "too tall"). Nothing about switching the printer profile changes this ordering. It's an incidental side effect of when and how the file gets re-saved (cut/paste, re-export, whatever). Bambu Studio's own sequential-print handling clearly doesn't treat that raw list order as the print order, or the same 3MF file would have thrown the same false collision on the Bambu printer it was designed for, and it didn't.

The Fix

Replace the list-order sort with an actual search for a valid print order. The constraint is: every instance except the one printed last is capped at extruder_clearance_height_to_lid, or the stricter extruder_clearance_height_to_rod if some later-printed instance overlaps it in Y. So at most one instance can need the "last slot," and among the rest, any two instances that overlap in Y and are both taller than the rod-clearance height need the taller one scheduled first.

That's a topological sort over a "must print before" constraint graph. The fix builds that graph and runs Kahn's algorithm, breaking ties by the original object index so the result is the smallest reordering of what you already had, not something arbitrary. If a valid order exists, it's used. If it genuinely doesn't (a real, unavoidable collision), it falls back to the original object-list order so the vertical-clearance check below still fires the same descriptive error it always has. The goal here is to stop false positives, not to hide real ones.

Testing

Test files:

The following was a 3mf that sliced cleanly and printed with no problems in Bambu Studio on a Bambu X1C:

Z-bambu.3mf.zip

You can see it will slice cleanly in Bambu Studio:

However, this is the same file opened in Sn(orca) and had the printer profile changed to Snapmaker U1:

Z-U1 2.3mf.zip

Here is by macOS (Apple Silicon) build with the patch applied and no error, slices cleanly:

Here is by Ubuntu 25.10 (questing) build with the patch applied and no error, slices cleanly:

Tested Builds

Built and tested locally against both OrcaSlicer and Snapmaker Orca on:

• macOS Tahoe, Version 26.3 (25D125), Apple Silicon
• Ubuntu 25.10 (questing)

Results:

• Files that previously failed with "Assembly is too tall, and collisions will be caused" now slice cleanly with no manual reordering.
• No cut/paste workaround needed anymore. The object list order is left as-is and the fix finds a valid print order on its own.
• Genuine collisions (verified with a case that has no valid order) still produce the same error as before.
• Confirmed on both macOS and Linux.

This is a pure logic change in one function. No platform-specific code, so it should behave identically everywhere.

Other bugs

While I don't really see any issues opened on Snapmaker/Orcaslicer (other than mine that I think this applies to), I did find a bunch on the main OrcaSlicer github repository that seem like are referring to this bug:

On OrcaSlicer/OrcaSlicer:

#6876: the same false "too tall" warning, reported in 2024 and closed as completed. It clearly came back (or was never fixed at the root), which lines up with what's in this repo now: a disabled #if 0 heuristic block that looks like an earlier, half-working attempt at this exact problem, later turned off in favor of the naive list-order sort that reintroduced the bug.
#14435: a feature request making essentially the same diagnosis, that using height-to-rod/height-to-lid as blind cutoffs "without checking actual geometry is too crude." Its proposed fix is more ambitious than this one (axis-based bounding-box sectors instead of a height plane), but the root-cause framing matches.
#12386: a cruder version of the same idea, force the tallest object last and skip the check for it. This fix effectively derives that outcome as a special case when it's actually needed, instead of asserting it unconditionally, and without giving up the check for genuine unavoidable collisions. Links its own related cluster: #6601 and #6828.
#12505: the mirror-image bug, where the slicer doesn't warn when it should and a real collision gets through during abort or end-of-print parking. Not something this PR touches (that's end-of-print G-code behavior, closer to the Snapmaker #453 family above), but it's a good reminder that getting the ordering logic right matters in both directions.

• Issue #6876 - False object "too tall" warnings in By Object print mode
• Issue #14435 - Improvement of collision detection on by object print sequence
• Issue #12386 - print tallest object last without collision detection and allow override
• Issue #6601 - Allow to slice even though collisions may occur
• Issue #6828 - Print Order: By Color
• Issue #12505 - Printing in "Print by Object" order breaks printed objects after print

[KuzuriAo]

/bot add-label bug-fix

[zackaree-shen]

Hi, @KuzuriAo

I am very glad to see your root cause analysis and fix attempts.
I will review and verify it locally as soon as possible. If I have any feedback, I will contact you promptly.
Thank you again for your contribution.

[KuzuriAo]

Follow-up: when this fix still isn't enough

@zackaree-shen I wanted to bring this up, since I ran into it myself right after posting this PR: this fix resolves the case where a valid print order exists but the old code never searched for it. It does not, and should not, silence a genuinely unavoidable collision. If two objects are both taller than extruder_clearance_height_to_rod and overlap each other in Y, there is no print order that avoids one of them being in the toolhead's way while the other prints. The fix correctly detects that (it's a real cycle in the ordering constraint graph, not a false one) and falls back to the same "too tall" error instead of pretending it's safe. That's intentional, not a bug.

So if you hit the error after this fix and reordering, cutting/pasting, or nudging objects around doesn't clear it no matter what you try, don't assume the fix is broken. It probably means the printer's clearance settings genuinely can't be satisfied by the current plate layout.

How to actually fix a genuine one

The check only cares about Y position, not X. Two tall objects can sit anywhere in X without conflict, they just can't occupy overlapping Y bands (specifically, within extruder_clearance_radius of each other) if both exceed the height-to-rod threshold. Repositioning along Y so the tall objects land in separate bands is a legitimate fix.

In practice this is fiddlier than it sounds if the objects are large: I tried it on a real case and the two conflicting objects each needed to span nearly the plate's full Y depth, leaving only a few mm of margin to work with after finding a split that satisfied both directions of the constraint.

A much easier and more reliable fix, if the flagged object is a merged multi-part "Assembly": split it apart and reposition the pieces individually.

1. Right-click the assembly, Split -> To Objects.
2. Reposition the resulting pieces as needed. Auto-arrange is fine for this if you don't care where the seams between parts end up.
3. Select all of the pieces you just split and rearranged.
4. Right-click, Assemble, to regroup them back into a single multi-part object now that they're laid out differently.
5. Re-slice.

Why this works: the collision check uses print_object->height(), which for a merged assembly is the height of the combined bounding box across all its sub-parts, not any individual part's height. A tall assembly can end up flagged even when most of its individual pieces are well under the clearance threshold, if just one sub-part is tall enough to push the combined bounding box over the line. Splitting means each piece gets auto-arranged on its own footprint instead of being dragged around as one large rigid block, which gives the arranger a lot more freedom to land on a layout where the genuinely tall piece isn't sitting in another tall object's Y band. In a real case I checked, a merged assembly measured 31mm tall overall, but of its six sub-parts, only one was actually over the printer's 27.5mm height-to-rod threshold; the rest weren't fighting for placement at all. Re-assembling afterward just bakes that new, collision-free layout back into one printable item, so you get the convenience of a single grouped object again without reintroducing the problem.

Quick summary

• Reordering fixes it: the object-list order was arbitrary and this fix finds a valid order automatically. No manual steps needed anymore.
• Reordering doesn't fix it, and the flagged object is a plain single object: it's a genuine collision under your printer's clearance settings. You'll need to move it in Y (not X) relative to whatever else it conflicts with, or accept the fewer-objects-per-plate tradeoff, or revisit the printer profile's clearance values if you believe they're overly conservative for your actual hardware.
• Reordering doesn't fix it, and the flagged object is a merged multi-part "Assembly": split it to objects, reposition (auto-arrange is fine), select the pieces and Assemble them back together, then re-slice. This is usually the easiest path, since it turns one large, hard-to-place footprint into several smaller ones during arrangement, most of which likely don't need to be separated from anything at all, then regroups them once a working layout is found.

[zackaree-shen]

Hello! @KuzuriAo
We are very glad to see the PR you submitted and the detailed explanation.
Recently, I have taken the time to thoroughly understand your algorithm and modifications. We believe this fix is feasible, and we have also conducted some local software testing. Although there are still a few minor interaction issues, we approve of the overall change.

Next, we will proceed with actual print tests to evaluate edge cases under different conditions. At the same time, we will discuss internally the appropriate timeline and version for incorporating this bugfix.

We will not merge this PR directly, but once we officially include a fix that contains your contribution, we will definitely link your current PR in the release notes and explicitly express our gratitude to you.

If there is any progress, I will contact you. You are also welcome to reach out to me anytime if you have any questions.

Thank you again for your support and contribution – let's work together to make things even better!

[KuzuriAo]

Hi @zackaree-shen

Thank you for the update. I'm happy that the PR seems to be of help. It certainly has fixed this particular issue for me, but it has also uncovered another deeper issue that I have no had the time or the resources to dig into. It is very peculiar and at first glance, almost appears as if it's the same issue that this PR fixed, but I don't think it is.

Over the next few days I hope to have the time to document this issue for you. But, would you like for me to append my findings in this PR or open up a bug?

Let me know your preference.

[zackaree-shen]

Hi, @KuzuriAo
You can continuedly append your finding to this PR, and when we finally set up our PR, we will attach this link of this PR.
I will be honestly present your contributions on that PR.

[KuzuriAo]

@zackaree-shen This is a 3MF that I found that triggered this condition after this PR fix has been applied. I have also tested this in the official Snapmaker Orca v2.3.5, without this PR applied and the result is exactly the same.

So, it feels like it's a similar issue that this PR fixed, but it's appears that it's deeper than that and there is something really strange that's going on with the Height to rod and it's not consistent as you'll see the Z height plane error move around to different objects, depending on how you arrange the plate.

This is the part where I haven't had the time or resources to investigate deeper, however I have outlined the exact steps to reproduce this behaviour below.

Summy of Steps

1. Downloaded a model off of MW as a 3MF.
2. Opened it in the macOS Snapmaker Orca compiled with this PR applied.
3. Clicked through the various errors and settings mismatch from Bambu Studio to Snapmaker Orca (for reference I have also painstakingly converted all settings to match as close as a 1:1 from BBS to Snorca and that does not change the result)
4. Rearranging the objects on the plate so the X bands don't overlap and a clean slicing order can be found.
5. The blue object (the tail 27.52mm) still shows the Z bounding box error, even though it is ~3mm shorter than the tallest objects (30.50mm)

By all accounts, this should slice cleanly and with no problem. It does not.

Summary of Fix

1. Edit the Height to rod clearance by adding exactly 0.02mm in the printer settings.
2. Slice the plate
3. Print successfully

Detailed steps

Download the AMS 3MF profile for this model:

Click OK:

Click OK:

Switch the printer profile from Bambu Lab P1S to Snapmaker U1:

Click Discard:

This is the plate in it's default configuration. However, a few things to consider:

1. The two taller objects (brown and tan, the top and bottom halves) are both exactly 30.50mm tall.
2. So, once all of the objects were spread out just enough not have their X/Y bounding bubbles touching, a clean slicing order should have been present:

After the objects were spread out just enough, the brown shell still shows it's too tall, even though it's exactly the same height as the tan bottom half:

So, I rearranged the plate so the two 30.50mm objects were in the same Y path, so a clean slicing order should be found:

Interestingly, now the blue tail (27.52mm) is now the object that is "too tall", even though it's in the X path with the 30.50mm tan bottom section:

It got me curious why there would even be an object that is still hitting the Z bounding error at all, and why it would be the shorter of the two. So, I decided to test adjusting the Height to rod setting which in the printer profile which is 27.5mm:

I simply added 0.02 Height to rod for a final value of 27.52mm and closed the printer configuration, I didn't even save it as a new profile, just let it apply it to the current plate:

The Z bounding error plane disappears:

The plate slices cleanly:

Finally, I sent the print and it printed with no errors at all:

[zackaree-shen]

Thanks a lot! @KuzuriAo I will check that these day