bounded_half_space has no independent in-plane frame for the boundary; cannot represent IfcPolygonalBoundedHalfSpace.Position

[GeneralPawz]

Problem

axiolid_construct::half_space::bounded_half_space(boundary, plane, agreement, margin, tolerance) has no parameter through which an independent in-plane orientation for boundary can be supplied.

Internally, the function derives the boundary's 3D placement frame entirely from plane.normal (picks Vec3::X or Vec3::Y as reference depending on which is less parallel to the normal). There is no way to override that pick with an authored in-plane direction.

Why this matters (IFC consumer context)

IfcPolygonalBoundedHalfSpace.Position is an IfcAxis2Placement3D that is explicitly independent of BaseSurface: schema-wise the two need not share an origin or an orientation. PolygonalBoundary is a 2D curve lying in Position's XY plane, extruded along Position's +Z to build the clipping prism.

SolidOperation::BoundedHalfSpace (the graph relationship) does carry a placement: Transform3 field, but the compiler applies it only to the output mesh, after bounded_half_space already ran with only plane.normal to build the boundary's local basis (crates/execution/compile/src/compiler.rs, SolidOperation::BoundedHalfSpace arm). That post-hoc transform cannot retroactively fix the boundary's in-plane rotation relative to the clip plane -- by the time it runs, bounded_half_space has already committed to its own guessed X/Y.

Reproduction

Signature check against axiolid HEAD c144808d76ebf653b2183d6895192514d1838bfd:

pub fn bounded_half_space(
    boundary: &Rings,
    plane: Plane3,
    agreement: bool,
    margin: ClipMargin,
    tolerance: Tolerance,
) -> GeomResult<TriMesh>

plane carries only origin+normal (2 DOF of orientation). There is no third parameter for the boundary's in-plane rotation about that normal, so any consumer whose source format authors an independent boundary frame (like IFC's Position) cannot round-trip it.

Acceptance criteria

• bounded_half_space (or BoundedHalfSpace's graph contract) gains a way to supply an explicit in-plane basis/frame for the boundary, independent of the clip plane's own normal-derived guess.
• A test with a rotated boundary and a fixed clip plane produces a mesh footprint that follows the supplied frame, not the internal Vec3::X/Vec3::Y heuristic.
• Existing callers that do not supply an explicit frame keep their current behavior (backward compatible default).

[GeneralPawz]

Landed the construction-level half in 55bef60.

What is done

bounded_half_space_in_frame(boundary, plane, frame, agreement, margin, tolerance) takes an explicit PlaneFrame for the boundary. The authored x axis is projected into the clip plane and re-orthonormalised against the sweep normal, so the frame contributes exactly its rotation about that normal and nothing else. An authored axis parallel to the normal fixes no in-plane direction and is refused by name rather than silently falling back to the heuristic.

bounded_half_space keeps the derived Vec3::X/Vec3::Y default, so existing callers are unchanged. All 7 pre-existing half-space tests still pass.

Acceptance criteria 1 and 3 are met. Criterion 2 is covered by an_authored_in_plane_frame_orients_the_boundary, which asserts the footprint lands where the authored frame predicts:

let want = rotated.lift(Point2::new(1.0, 1.0));
assert!(turned.positions.iter().any(|p| (*p - want).length() < 1e-9));

Worth noting for anyone testing this area: volume cannot detect the bug. Rotating a profile about the sweep axis preserves both area and depth, so a volume assertion passes whether or not the frame is honoured. The test pins a vertex position instead. Mutation-checked -- forcing the authored frame to be ignored fails the test with the authored in-plane frame was ignored: both footprints are identical.

What is NOT done, and why

The graph/compiler path still does not carry an authored frame, so the IFC consumer path is not yet fixed end to end.

I started wiring SolidOperation::BoundedHalfSpace's placement into the new parameter and backed it out. The compiler already applies that same placement to the output via transform_mesh, so also passing its rotation as the boundary frame would rotate the geometry twice. Correcting it means deciding what placement actually means -- whether it is the boundary's own frame (in which case the post-hoc transform must drop its rotation) or a separate model-space placement (in which case the contract needs a distinct field for the boundary frame).

That is a graph contract change with a compatibility question attached, not a mechanical follow-on, so I left it rather than guess and ship a double-rotation. Keeping this issue open for that half.

Verification: workspace 1114 passed / 0 failed, GATE PASSED.

[GeneralPawz]

Closed by 5d59ed7, completing the work started in 55bef60.

All three acceptance criteria

1. An explicit in-plane basis, independent of the plane's normal-derived guess

bounded_half_space_in_frame(boundary, plane, frame, agreement, margin, tolerance) takes a validated PlaneFrame. The authored x axis is projected into the clip plane and re-orthonormalised against the sweep normal, so the frame contributes exactly its rotation about that normal. An axis parallel to the normal names no in-plane direction and is refused by name rather than silently falling back to the heuristic.

2. A rotated boundary with a fixed clip plane follows the supplied frame

crates/execution/compile/tests/bounded_half_space_frame.rs and the construction-level test in crates/algorithms/construction/construct/tests/half_space.rs.

Two notes on making this test actually meaningful:

• Volume cannot detect the bug. Rotating a profile about the sweep axis preserves area and depth, so the obvious assertion passes either way. The tests pin a footprint vertex against the position the frame predicts.
• A flat +Z clip plane also cannot detect it. For that normal the internal heuristic happens to pick the world x/y axes, so its guess coincides with the authored frame and post-hoc transforming is genuinely equivalent. The compiler test therefore tilts the plane, which is the case real files hit.

3. Existing callers keep their behaviour

bounded_half_space retains the derived default. All 7 pre-existing tests pass untouched.

The graph/compiler half

The compiler arm passed only the clip plane to the construction and applied placement to the finished mesh afterwards -- exactly as this issue describes. It now builds a PlaneFrame from the placement and constructs through the framed entry point, so the authored frame orients the profile before the slab is built.

placement is now documented on the variant as the boundary's own frame. It previously had no documented meaning and no producer anywhere in the workspace, so settling the semantics breaks no existing caller.

Verification

Mutation-checked at both levels: restoring the post-hoc transform_mesh makes the compiler test fail, placing the profile corner where the authored frame never names it; forcing the construction to ignore its frame argument fails with both footprints are identical.

Workspace 1118 passed / 0 failed, GATE PASSED.