You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(geometry): IfcReinforcingBar rendering for 3D directrix (#641)
* fix(geometry): IfcReinforcingBar rendering for 3D directrix and Revit trim params (#631)
Two issues, both surfacing as broken IfcSweptDiskSolid geometry on rebar:
1. **3D IfcIndexedPolyCurve directrix support** (no spec deviation). The 3D
curve dispatcher in `get_curve_points_with_depth` had no arm for
`IfcIndexedPolyCurve`. Inputs fell through to the 2D path, which only
reads `IfcCartesianPointList2D` — Z coordinates were silently dropped
and 3D stirrups collapsed onto z=0 as a degenerate line. Add
`process_indexed_polycurve_3d` that reads `IfcCartesianPointList2D` /
`IfcCartesianPointList3D` verbatim and fits `IfcArcIndex` segments via
circumcircle in the plane of their three control points.
2. **SPEC DEVIATION (Revit rebar)** — `IfcSweptDiskSolid.EndParam` as arc
length. IFC4 / IFC4.3 parameterises `IfcCompositeCurve` over
`[0, num_segments]` (each segment contributes 1.0). Revit and other AECC
tools emit `EndParam` in the directrix's length unit instead, typically
the bar's swept length. Honouring it verbatim clamps to `num_segments`
and renders the entire curve, making bars 10–100× their real length.
`get_composite_curve_points_trimmed` now detects
`EndParam > num_segments + ε` (impossible under the spec parameterisation),
re-interprets `StartParam` / `EndParam` as cumulative arc length along the
sampled directrix, and trims accordingly. Spec-conformant inputs
(`EndParam ≤ num_segments`) take the unchanged segment-index path. The
deviation is flagged in the method doc comment and at the branch point.
Tests:
- `test_swept_disk_indexed_polycurve_3d` — Z extent preserved on 3D arc directrix.
- `test_swept_disk_revit_arclength_trim_fallback` — Revit-style trim clips
the directrix to the requested arc length.
- `test_swept_disk_segment_index_trim_unchanged` — spec-conformant trim
parameters still produce the segment-index result.
WASM rebuilt via `scripts/build-wasm.sh`. Includes the cosmetic
`__wasm_bindgen_func_elem` renumber that also appears in #638.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* revert: drop Revit arc-length trim heuristic — was regressing Rebar2.ifc
Visual verification on the issue's Rebar2.ifc showed the heuristic was
trimming the directrix too aggressively: bars rendered as a tiny straight
stub instead of the full hooked shape. Re-checking the numbers, EndParam
≈ 228.99 for that file matches the sum of each segment's natural
parametric contribution (4 polylines × 1 + 110° + 70° + 45° ≈ 229), not
arc length in mm. The existing segment-index path clamps to `num_segments`
and renders the whole curve, which is what the authoring tool intended.
Revert the spec-deviation branch added in ba6fca8:
- `get_composite_curve_points_trimmed` returns to the original
segment-index clamp behaviour, with a short doc-comment note about why
out-of-range EndParam values are clamped rather than reinterpreted.
- Remove the now-unused `trim_polyline_by_arclength` helper.
- Drop the `test_swept_disk_revit_arclength_trim_fallback` and
`test_swept_disk_segment_index_trim_unchanged` tests; the
segment-index path is unchanged from main and already covered.
The 3D `IfcIndexedPolyCurve` directrix fix (sample 1, the stirrup) is
unaffected and visually confirmed working.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(geometry): read RefDirection from index 2 on IfcAxis2Placement3D
The 2D placement helper used by `process_trimmed_conic` always reads
attribute index 1 as `RefDirection`. That is correct for
`IfcAxis2Placement2D` (`Location, RefDirection`) but wrong for
`IfcAxis2Placement3D` (`Location, Axis, RefDirection`) — index 1 there is
the Z-axis, which has no useful x/y components for an in-plane rotation.
Every arc trimmed over a 3D-placed `IfcCircle` came back with rotation 0°
regardless of the file's authored direction.
Concrete impact: in `Rebar2.ifc` from issue #631, each bend in the
composite curve uses a different `RefDirection` (135°, 245°, 315°), so the
rebar's arc segments were rotated to the wrong direction and the
directrix looked visibly distorted. Detect `IfcAxis2Placement3D` and read
attribute index 2 in that case.
Added `test_trimmed_circle_3d_placement_reads_ref_direction` to pin the
behaviour: a 90°-rotated 3D placement must produce arc geometry above the
centre, not below.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0 commit comments