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

[KuzuriAo]

Following up: the Squirtle case, and measuring the U1's actual height-to-rod

@zackaree-shen I finally had some time to try and close the loop on the Squirtle 3MF I posted above. Short version: it is not a regression or a gap in this PR. It's the "genuine collision" fallback doing exactly what it should, and I've now measured the U1's real nozzle-to-beam clearance to confirm the profile's 27.5 is right. Details below so nobody has to re-derive this.

What was actually going on with that plate

I pulled the geometry straight out of the 3MF instead of trusting the GUI readouts. Plate 1, with the U1 profile (extruder_clearance_height_to_rod 27.5, extruder_clearance_radius 72.5):

object	height	Y extent
shell brim	14.00	33 – 104
tail	27.52	22 – 54
shell	30.50	183 – 249
bottom	30.50	134 – 201

shell and bottom overlap each other in Y by 18 mm, and both are taller than 27.5. That's a two-way constraint: each one has to print after the other. No print order satisfies that, the topological sort correctly finds the cycle, and the code falls back to the original error. It's the same situation whether the file is opened at its original Bambu layout (overlap 21 mm there) or after my re-arrangement.

The part that fooled me was thinking two objects of equal height in the same Y band should be fine. They aren't. The beam sits at (nozzle Z + 27.5) and spans the full X width of the machine, so while the second 30.5 mm object prints its first ~3 mm, the beam runs straight through the top 3 mm of the first one, wherever it is in X. Equal heights don't cancel; the first-printed one is what gets hit. The only escapes are separate Y bands or the single "printed last" slot, and here two objects need it. "Y band" is wider than it looks, too: the check treats raw footprints within extruder_clearance_radius / 2 − 0.1 (36 mm on the U1) as overlapping.

My "+0.02 mm on height-to-rod fixes it" observation was a coincidence of margins, not evidence against the check. In that arrangement I had already put the two 30.5s in separate Y bands; the only remaining conflict was the tail (27.52) against one of them. Nudging the threshold to 27.52 dropped the tail out of the "taller than the rod" set and the cycle disappeared. It printed fine because the nozzle is at Z 0.2 on the first layer, which puts the beam at ~27.7, 0.18 mm above the tail.

Why the error "moves around" between objects depending on arrangement: when the fallback fires, the vertical check flags the first object in list order that has a later Y-overlapping neighbour. Which member of the cycle gets named is arbitrary. That's cosmetic, but it's what sent me chasing the tail instead of the two shells (see item 2 below).

Measuring the real height-to-rod

Since the whole thing hinges on whether 27.5 is physically right (upstream OrcaSlicer bumped it to 60 in OrcaSlicer#12824 and reverted to 27.5 in OrcaSlicer#14097 without a measurement being posted either time), I measured it.

First, what didn't work: my earlier "it printed fine with height-to-rod raised" tests were all inconclusive. On the U1 the X beam sits in front of the nozzle, so in every one of those layouts the beam passed over empty bed at the critical moment, not over the tall object. The nozzle is the lowest point on the toolhead.

So, even though in this test both towers are 30.5mm high and I got the "object too tall" error, when I bumped Height to rod to 30.5, sliced and it printed fine. It printed fine because the beam sits ahead of the nozzle and passed over empty bed, not because there was clearance:

30_5mm.3mf.zip

The gauge that did work (two prints, by-object, single filament):

• Comb, printed first, at the front of the plate: a row of free-standing fins, 8 × 1.7 mm (two wall loops, no infill, on a shared brim), each stepping up in height. Heights chosen on the 0.2 + n × 0.28 layer grid so they print exactly.
• Carrier, printed second, behind the comb and ≥ 73 mm away in X so the toolhead body can't reach the fins: a low slab whose only job is its first layer. With the nozzle at Z 0.2 the beam is as low as it ever gets, and it sweeps the full X width over the comb while that layer prints. The object-to-object travel itself can't hit anything: the G-code lifts to m_max_layer_z (the tallest thing printed so far) before moving.
• Height to rod set high in the project just so the plate can be sliced.

Results:

• Run 1: eight fins at 29.04, 29.88, 31.00, 32.12, 32.96, 34.08, 34.92, 36.04 mm: every fin hit on the carrier's first layer. Clearance < 28.8.

rod_gauge.3mf.zip

• Run 2: ten fins at 26.52, 26.80, 27.08, 27.36, 27.64, 27.92, 28.20, 28.48, 28.76, 29.04 mm (one 0.28 mm layer apart): 26.52, 26.80, 27.08 and 27.36 untouched; 27.64 and everything above it hit.

rod_gauge_low.3mf.zip

So the beam's underside is 27.2 to 27.4 mm above the nozzle tip on my U1. The profile's 27.5 is correct. If anything it's ~0.1–0.3 optimistic, but the 0.2 mm first layer covers most of that. The 60 mm value in OrcaSlicer#12824 would have been really unsafe.

What this means for the PR, and what I'd do next

1. The fallback is right. The Squirtle plate, as arranged, genuinely cannot be printed by object on a U1. Nothing to change in the ordering logic here. A layout that passes at 27.5 does exist (I found one by exhaustive search), but two of its clearances pass by under a millimeter, which is why no amount of hand-arranging found it and exactly why follow-up B below is worth having.

2. Follow-up A: name the whole cycle in the error. A genuine cycle currently reports one arbitrary object as "too tall", which reads just like the old false positive (it's what sent me chasing the tail). The old code couldn't do better because it never looked for an order; the topological sort this PR adds knows exactly which objects are stuck. Return those and word it for a normal user, e.g. "shell and bottom are both taller than this printer's Height to rod (27.5 mm) and overlap front-to-back, so the beam would hit whichever prints first. Move them at least 36 mm apart in Y, or print by layer." Small change, but it depends on this PR's code, so it's a follow-up rather than part of it.

3. Follow-up B: a "Move them apart" action on that error. Nobody should have to read that message, understand what a Y band is, and then fiddle with every object on the plate to find a layout that works. The fix is mechanical: tall objects need separate front-to-back bands (~36 mm apart on the U1) and every pair needs the toolhead-radius clearance. So: move only the cycle members, keep their orientation, move them as little as possible in whichever direction works, nudge any short object that now crowds one, and re-run the same check. One undo step. If the tall objects genuinely don't fit, say so with numbers instead of "X is too tall", and offer the ways out: rotate, split an assembly and repack its parts more compactly, or use another plate. This is not a second auto-arrange: arrange reshuffles the whole plate, and the whole point here is to not move what the user already placed. Depends on A.

4. Follow-up C: make auto-arrange agree with this check. Arrange already has a by-object height heuristic (Arrange.cpp, the row-height-conflict block), but it assumes a rows/left-to-right print order the check has never used, compares raw bounding boxes instead of the 36 mm band, and only soft-penalizes conflicts. That's why "arrange, then get told it's too tall" happens. Replace it with the same tall-vs-tall Y-band rule as a hard reject. Independent of this PR, but only really trustworthy once the checker is order-agnostic like it is here.

5. Follow-up D: apply the Y-band rule only to the material above Height to rod. The beam can only hit material that is physically above it, but the check uses each object's whole footprint. Pulling the numbers out of my files: the Squirtle tail's material above 27.5 mm is a 1 mm spike (the check treats it as a 32 mm deep tall object); the shells' above-rod caps are 28 and 37 mm deep, not 66 and 68; and on another plate of mine a 145 mm deep assembly has a 16 mm tip above the rod. With that rule, that plate, which the current check says needs 321 mm of front-to-back space on a 262 mm bed, solves with one object moved 66 mm. No rotation, no splitting. It's a change to the same function, computed from data the check already has, and it's exact for the beam (the ±36 mm reach stays as it is, still conservative). I think this is best done as a stacked PR on top of this one: it changes the physical model, so it deserves its own review and its own revert path, separate from this pure logic fix.

6. Separate, bigger topic: the beam is one-sided, the model isn't. The Y-overlap check is symmetric (±36 mm around the nozzle) but the U1's beam is in front of the nozzle only, so two tall objects side by side in X, in the same Y band, get flagged even though the beam never crosses the first one (that's exactly what my early tower tests showed; image 1). Bambu Studio has a separate extruder_clearance_dist_to_rod parameter, but it only sets the width of the same symmetric band. Neither slicer models which side of the nozzle the beam is on. For what it's worth, I eyeballed an X1C and its rod sits behind the nozzle by roughly the same distance the U1's sits in front. Same numbers, opposite sides, so the side can't be inferred from today's profile values and would have to be a new field. It also means the current symmetric band, while conservative on both printers, is at least conservative in the right direction on both; a one-sided guess would be dangerous on one of them. The upside of a directional model would be large (the safe order becomes "print away from the beam", and the constraint graph this PR adds handles that flip for free), but it's a profile change first and a code change second, and its own discussion.

Bottom line: the Squirtle case doesn't change anything about this PR. The fix does what it set out to do and that is find a valid print order when one exists, and when one doesn't, it fails the same way it always has, now for a reason I've physically verified rather than one we were guessing at. I'd consider #630 good to go as-is. The follow-ups above (naming the cycle, a one-click "move them apart", bringing auto-arrange in line with the checker, and only counting material above the rod) all build on the order-agnostic check this PR introduces, so this lays the groundwork for making print-by-object actually usable in both Snapmaker Orca and upstream OrcaSlicer. None of this is U1-specific: the check reads three numbers from any printer profile, and the U1 just happens to have the lowest one, so everything above applies to any printer that sets them. Once this PR is in, I think discussion on some of the next-steps would be in order and I would be happy to try and help out where I can.