* Make Painted Multi-Material Slicing Deterministic
Painted (multi-material) models sliced to slightly different G-code on
every run: ±1 µm wall coordinates and reordered islands. Hashing each stage
of the segmentation across runs showed the projected painted lines and the
per-layer Voronoi segmentation were stable; the raw top/bottom projections
from slice_mesh_slabs() were not. Three causes, all thread-order dependent:
- slice_slabs_make_lines() appends each slab's intersection lines from a
parallel facet loop and never restored a canonical order, so the loop
start vertices and polygon order from make_slab_loops() depended on
scheduling. Sort every slab's lines with the same key slice_make_lines()
already uses.
- segmentation_top_and_bottom_layers() wrote a layer's shell projections
into neighbouring layers' vectors from the parallel loop, relying on a
parity double-buffer that assumes TBB ranges are exactly one group wide
and aligned, which blocked_range does not guarantee; two threads could
append to the same vector. Each source layer now records its projections
in its own slot and they are gathered per target layer in source order.
- The painted-line sort in post_process_painted_lines() was not a total
order: projections of one span from facets of different colours tied on
every key and the first one won the span. Colour and end points now break
the tie.
Three multi-threaded runs of each painted fixture now give one G-code;
unpainted output is unchanged.
* Test That Slab Slicing Does Not Depend on the Thread Schedule
Projects a dense, tilted sphere with slice_mesh_slabs() on one thread and
then three times multi-threaded, and requires the polygons to match exactly,
vertex order included. Fails without the canonical line sort, passes with it.
HanifKoh