Sequential print: only material above height-to-rod can collide with the beam (stacked on #630)

[KuzuriAo]

@zackaree-shen

Stacked on #630. The first commit in this PR is #630 unchanged; the second is this change. It builds on the constraint graph #630 introduces, so it can't land before it.

The practical result: with #630 and this change together, the plates that started this whole thread, the ones that sliced and printed fine on my X1C but were "too tall" on the U1 no matter how I arranged them, now slice and print on the U1. Objects or assemblies usually need to move a little, but only a little: no splitting assemblies and repacking them by hand, no rotating, no bumping height-to-rod. #630 finds the print order; this change stops counting material the rod can't reach. Those two are the slicer-check half. The physical half is #532, the toolchange G-code that lifts the head over already-printed objects, which is merged but not yet in a release; my prints were done with it in place. Each piece alone helps; all three together turn print-by-object on the U1 from something I fought with on every multi-part model into something that just works.

What this changes

Print::sequential_print_clearance_valid() decides which already-printed objects the X rod could hit while a later object prints by testing whether the objects overlap in Y. Today it uses each object's whole footprint for that test. But the rod sits extruder_clearance_height_to_rod above the nozzle, so the only material it can physically touch is the part of an object that reaches above that height. This PR computes that above-the-rod Y extent per instance and uses it, instead of the full footprint, for the object that could be hit. The later object (the one being printed, i.e. everywhere the nozzle can be) keeps its full footprint plus the extruder_clearance_radius / 2 reach, exactly as before.

In the same function:

• a per-instance above_rod_min_y / above_rod_max_y is computed from the transformed mesh (any triangle with a vertex above the rod contributes all three vertices, so it's conservative; modifiers, support blockers and negative volumes are skipped because they aren't printed);
• "is this object tall" becomes "does any of it reach above the rod" (same thing for objects sitting on the bed; correct for objects sunk into it);
• the ordering constraints from Fix sequential print collision check depending on object list order #630 and the final vertical check both test that extent, with the same 0.1 mm tolerance the footprint test already used.

Nothing else moves: the ±radius/2 reach of the rod is unchanged (still symmetric, still conservative), the height-to-lid rule is unchanged, the toolhead-radius "too close" check is unchanged.

Why

I measured my U1's actual nozzle-to-rod clearance with a printed gauge (details in #630): the rod's underside is 27.2 to 27.4 mm above the nozzle tip, so the profile's 27.5 is right. That also means the rod only ever meets the top few millimeters of a 30 mm object, and with most real models that is a small fraction of the footprint. Pulled from my own files:

object	height	full footprint depth	depth of material above 27.5 mm
Squirtle tail	27.52	32 mm	0.8 mm (a spike)
Squirtle shell / bottom	30.50	66 / 68 mm	28 / 37 mm
a two-part assembly from another model	31.18	145 mm	16 mm (one tip)
its neighbour on the same plate	52.82	140 mm	86 mm

With the current rule those last two need 321 mm of front-to-back space in separate bands on a 262 mm bed: impossible, and the only ways out were rotating them or splitting the assembly and repacking its parts by hand. With this rule the same plate slices after moving the 145 mm assembly 66 mm forward, no rotation, no splitting. The Squirtle plate's three tall objects go from needing 238 mm of Y to 138 mm.

What it does not do

• It doesn't make anything pass that the rod would actually hit. The extent is taken at the rod height itself (not rod height + first layer), triangles are counted if any vertex is above, and the rod's Y reach is unchanged, so every case this newly allows is one where the rod passes over material that is below it.
• It doesn't model which side of the nozzle the rod is on. That needs a per-printer field and is a separate discussion.

Cost

This runs in Print::validate(), the check that fires when an object is moved or a setting changes (it's what draws the red "too tall" plane) and once more when you press Slice. It never runs inside the slicing pipeline itself. What it adds is one extra pass over each printed instance's mesh (a transform per vertex, a comparison per triangle). The check already walks the same meshes to build the convex hulls, so this at most doubles a cost that isn't noticeable today. I haven't profiled it, but I ran every plate in the testing section below on both this build and the official 2.3.6, moving objects around and slicing, and if there is a difference it isn't noticeable by eye.

Testing

Built on Snapmaker Orca v2.3.6 + #630, macOS Apple Silicon.

aboverod_test.3mf.zip

• aboverod_test.3mf (attached above): two 40 x 30 x 2 mm slabs 25 mm apart in Y, each with one 32 mm fin on the edge facing away from the other. Stock 2.3.6 refuses it ("A back-fin plate is too tall": two tall objects whose footprints overlap in Y). This build slices it with the objects untouched, and it printed on the U1 with no contact. Minimal reproduction, ~8 g of filament.

Here is the aboverod_test.3mf loaded in Snapmaker Orca v2.3.6 (official):

Here is the aboverod_test.3mf loaded in Snapmaker Orca v2.3.6 (compiled with #630 and this height-to-rod patch):

Here is the video of aboverod_test.3mf successfully printing with the above patches:

https://photos.app.goo.gl/VGWgU8iyUwxpffFD8

• The real-world plate from the table above (not attached, licensed model): fails today ("Assembly is too tall"), slices clean with this change.
• The Squirtle plate from Fix sequential print collision check depending on object list order #630 as originally arranged: still fails (both shells' above-rod caps sit inside each other's sweep band), same message as before.
• Plates that pass today still pass: two by-object plates that slice in stock 2.3.6 (a two-tower test plate at height-to-rod 30.5, and the rearranged Squirtle layout at 27.5) slice clean on this build. No new failures are possible in principle either, since the tested extent is a subset of the old one.
• Rod gauge plates (rod_gauge.3mf, rod_gauge_low.3mf) slice clean, as before.

None of this is U1-specific; the check reads the same three profile values for every printer.

Related

• fix: update change_filament_gcode for all U1 nozzle sizes #532 (merged, not yet released) fixes the G-code side of print-by-object on the U1: the head lifts over the tallest printed object on toolchange instead of moving at 1.5 mm. Fix sequential print collision check depending on object list order #630 and this PR are the slicer-check side. The G-code fix stops real collisions; these two stop the check refusing plates that would not collide. They're independent and complementary.
• Improvement of collision detection on by object print sequence OrcaSlicer/OrcaSlicer#14435: this addresses the "check the actual geometry" half. The gantry-axis half is the directional model, which needs a per-printer field and is a separate discussion.
• Enhancement request: When using print by object, print tallest object last without collision detection and allow override OrcaSlicer/OrcaSlicer#12386 and Allow to slice even though colisions may ocur OrcaSlicer/OrcaSlicer#6601: fewer plates will hit the cases described there, but this adds neither a tallest-last option nor an override.

[zackaree-shen]

@KuzuriAo
I am very glad to see your enthusiasm and contributions on this matter, and I am also very sorry that we have been busy recently and unable to respond quickly.
I will take some time to look at this PR.
At the same time, we have also started to pay attention to existing issues; hearing everyone's voices and feedback helps us become better.

[KuzuriAo]

@zackaree-shen I know you all are really busy, I totally understand. Launching something like the U1 and Snorca is no small undertaking.

I figure if it's something that's causing me problems, it's probably doing the same for others (based on the Snorca/Orca issues, it seems to be the case). So, when I have time I try and solve the problem for myself and when successful, I open a PR.