ahnyongjooandClaude Sonnet 5.5
964a841de1
- Code\rebar_pipeline, review_pipeline, pier-program을 정션에서 실제 폴더로 전환 - Code\rhino_mcp 및 CLAUDE_rhino배경.md 추가, .mcp.json은 PYTHONPATH로 새 위치 사용 - pier-program 내부 .git 제거(이력은 backup\pier-program_20261028.bundle에 보관) - worktree 가이드 반영(CLAUDE.local.md, HANDOFF.md) - D:\Rhino-MCP 경로 참조를 새 위치로 치환 Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
4.1 KiB
name, description, metadata
| name | description | metadata | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| feedback-coping-haunch-rebar-method | 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 |
|
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:
- 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. - 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. - 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.
- 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.
- 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. - 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).
- 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.
- 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).