mirror of
https://github.com/OrcaSlicer/OrcaSlicer.git
synced 2026-09-23 17:02:39 +00:00
Tommaso BianchiandClaude Opus 4.8
0100c95ed1
Until now move and rotate lived only in the GUI as m_body_xform, a display transform. That made them a correctness hole, not a missing tool: a moved body recomputed and booleaned at its ORIGINAL position, and the move was not in the recipe at all, so it vanished on save/reload. Only export_step consulted the transform, which is why the discrepancy stayed hidden. CadFeatureType::Transform makes it a real feature: rotate angle_deg about xf_axis through xf_pivot, then translate by xf_translate, applied to the target body with BRepBuilderAPI_Transform. xf_copy=true keeps the source and appends the transformed body instead of mutating in place, which covers Onshape's Transform/copy in the same feature. Rotation is composed before translation (trsf = tr * rot) so the pivot means what a user expects — the point the body turns about, not a point that then drifts with the translation. A rotation with a degenerate axis is refused rather than silently skipped; a zero angle skips the rotation entirely so a pure move needs no axis at all. The decisive test is not the bbox arithmetic but "moved body participates in a later boolean at its new position": two coincident boxes, one moved to partial overlap, fused. The fused volume must be strictly greater than one box (the move took effect in the kernel) and strictly less than both (they still intersect). With a display-only transform the first assertion fails. Serialization stays append-only; recipe version unchanged at 2. Golden fixture regenerated with a GoldenTransform feature carrying distinctive literals so a field reorder shows up as obviously wrong values. Also fills in the Helix arm of feature_type_name(), missing since the helix commit. Kernel suite 51 -> 57 cases, 985 -> 1054 assertions, green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BVzKmX6Y1aEteit1HTXG4Q