--- name: feedback-coping-haunch-rebar-method description: Validated modeling method for coping/cap-beam haunch rebar (e.g. C12/C18-type marks) with dimensions that vary along a sloped underside — user confirmed to keep reusing this approach on future pier rebar work metadata: node_type: memory type: feedback originSessionId: d49157ae-9661-437c-a1d1-639728d3fff0 modified: 2026-09-21T02:31:23.248Z --- For coping (두부보) haunch-region rebar marks whose leg lengths vary along the pier length (following a sloped/stepped underside), use this method. Confirmed correct and to be reused going forward, on [[project_p1_pier_structure]] (대호지교 P1) and future similar pier projects. **Why:** the coping sits at real survey coordinates that are rotated/skewed relative to global X/Y (the pier is not aligned with the survey grid), so naive X/Y-based reasoning about "length direction" and "width direction" is wrong. Text-based DXF archaeology (parsing TEXT/DIMENSION entities to infer bend geometry) is slow and error-prone — several rounds of wrong shapes resulted from guessing at shape topology from DXF dimension text alone. **How to apply:** 1. **Get the true local frame from the 3D model, not the DXF.** Query the coping's own Brep faces via `TryGetPlane()` — flat "shelf" faces give the width axis as their in-plane X/Y axes; vertical "riser" faces give the length axis as their face normal. Cross-check against the known coping width (should come out to a clean round number, e.g. 3500mm) and the known pile spacing. 2. **Use ray-casting for exact underside elevation**, not manual face/vertex topology reasoning: `Rhino.Geometry.Intersect.Intersection.RayShoot(ray, [brep], 10)` shot upward from below the brep at any (station, width) point gives the exact underside Z at that point — far more reliable than reconstructing the stepped-haunch profile from face bounding boxes. 3. **A "closed box (ㅁ)"-looking mark is often two overlapping open pieces, not one closed loop or one diagonal-following bar.** For this project's "V" shape (양곡) family: a "lid" piece (⊓, short FIXED leg length, opens downward from the main top-bar level) + a "base" piece (⊔, variable leg length computed from the ray-cast underside + cover, opens upward) — placed coincident/overlapping at the design stage; the physical front/back offset to avoid bar clash is a construction-detail-stage decision, not a design-stage one. 4. **Multiple such boxes can be nested/overlapping across the width** (e.g. a 1005mm box near each edge + a 1250mm box further in, overlapping each other and mirrored left/right) rather than laid edge-to-edge — check whether the sum of box widths exceeds the actual member width before assuming edge-to-edge placement. 5. **Longitudinal spacing is often two different CTC zones** (e.g. wider spacing far from a support, tighter spacing near it) rather than one uniform spacing. Always cross-check `(stations in zone 1 × boxes per station) + (stations in zone 2 × boxes per station)` against the material table quantity — an exact match confirms the station count/zone split is right. 6. **Reuse an already-built neighboring mark's level as a datum** when the drawing says a piece "ties in" to it (e.g. the lid piece's Z level = the existing C1 top-bar block's own bounding-box Z, read directly off the block instance geometry, not assumed). 7. **Iterate visually at one station before mass-generating.** Build one full cross-section (all boxes at one station) as raw pipes, isolate the relevant layers + coping in Wireframe display (Shaded mode hides embedded rebar inside solid concrete), and get explicit sign-off before looping over all stations. 8. **Bundle each unique station's geometry into its own named block** (via `rs.AddBlock`) rather than trying to reuse one shared block across stations when leg lengths differ per station — block instancing only pays off for genuinely identical repeated geometry. See [[feedback_ironpython_exec_scoping]] for the RhinoMCP `execute_rhino_code` scripting gotchas hit while implementing this (no nested `def`/comprehensions, Z must be set explicitly since local L/W axes here are horizontal-only).