---
name: project-p1-pier-structure
description: "Structural facts about the P1 pier (대호지교) being modeled in Rhino — column/pile configuration, coordinate placement basis, cap-beam rebar status incl. C12/C18 haunch marks"
metadata: 
  node_type: memory
  type: project
  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
  modified: 2026-10-06T00:50:32.902Z
---

P1 is one pier in a set (P1, P2, P10, P11, P12) being modeled from real construction drawings (교각도, 두부보 도면). **Bridge name: 대호지교** (corrected — this is NOT 평강1교, a separate project; see [[project_pyeonggang1_modeling_standard]] for that one). Rhino file: `D:\★Pier 자료\클로드로 모델그리기\대호지교 P1\대호지교 교각 model.3dm`. Drawing files (DXF) and a project-local `notes.md` live in the same folder. See [[reference-pyeonggang1-dxf]] for the separate 평강1교 drawings (do not confuse the two).

- P1 is a **2주식 교각** (two-column pier) with **no separate footing** — two Φ3.0m cast-in-place pile-columns (현장타설말뚝기둥) at 13.0m center spacing, continuous from pile tip straight up to the cap beam (두부보/코핑).
- Placement basis: real survey coordinates from the pile coordinate table (말뚝좌표표) — left/right X, Y — and real elevations (H, H1, H2, ground level, EL "CL"/"CR"/"PB"). **The coping is rotated/skewed relative to the global X/Y survey axes** — do not assume global X = pier length direction; see [[feedback_coping_haunch_rebar_method]] for how to get the true local frame.
- The coping (두부보/코핑) Brep is ~24.45m long end-to-end, 3500mm wide, with a stepped/haunched underside (deepest near each column, shallower toward mid-span and the outer ends) already modeled into the Brep's faces.
- Cap-beam rebar: SD400, bar marks C1~C26 (+more per material table), shape legend I~VIII per the P1/P3/P5/P8 cap-beam drawings (I=straight, II=single-bend, IV=symmetric-hook-ends, V=see below, VI/VII/VIII=stirrup/hook/complex variants).
- **Terminology (user's own naming, use consistently)**: **주철근** ("main rebar") = C1~C11, the 1CYCLE/2CYCLE top/bottom mat bars. **수직전단철근** ("vertical shear-transfer rebar") = C12~C18 (and by extension C26's own family), the haunch-region ⊓+⊔ box assemblies. **수평전단철근** ("horizontal shear rebar") = C19~C25 (built 2026-10-02). Don't conflate them when discussing "which rebar" needs a change.
- **User added (2026-10-02): 수직전단철근 C12~C18 — 이음장(lid/base lap) 부분과 뚜껑(lid) 부분 must be re-checked against the drawing** (lap length/location, lid top z & width, how the +124 raised zones are handled, coincident lap representation, bend radii lid R≈42.7 / base R≈47~63 vs KDS H22 3db → centerline 77.7). Recorded as section 3-A of `261002_수정해야할 부분.md`.
- **DONE 2026-10-06 (user: "삭제하고 재료표처럼 다리 C=510으로, 엇갈린 것은 지워줘")**: all off-axis stubs in C13~C17 removed (144×124mm in C13 09-13/C15/C17 v2_09-13, 80×12.9mm in C14/C16; 112 box-defs, backups `<name>_bk1006`) AND base(⊔) legs extended coaxially up to the lid-top centerline (+124 / +118.1) → all 224 C12~C18 box-defs now: lid leg C=510, base B=full height, lap 510. C12/C18 (76 defs) base tops then trimmed 7.2 via `Brep.Trim(plane z=lidtop, +Z normal)` → lap 510 everywhere (same day, user request). Extensions are separate coaxial pipes (base = 3 pieces; Brep join fails because the original base's rim edges are not naked). File saved. This closes items 3-1/3-2/3-3 and pending decision #4 of the to-do md; the stub/lap notes further below are now historical. MCP gotcha: `execute_rhino_code` returns only the variable `result`, `print` output is not returned.
- **COVER CHECK vs DXF 2026-10-06** (report `261006_피복 체크(도면 대조).md` in drawings folder; user: 간섭은 모델 완성 후, 지금은 피복만). Key finding: **the model coping Brep's top steps are wrong** — both 구조도 and 일반도 front views have symmetric 62mm steps at s=±3100/±6200/±9300; model has them at −7750/−4650/−1550/+4650/+7750/+10850 (shifted +1550; left ones sit on the bearing centers ±1550/4650/7750/10850). This is the cause of the top cover 58 on C26/C13/C14 — rebar is right, concrete is wrong (fix not yet requested). Everything else matches the drawing except the known items (1CYCLE outer bars ±1617.3 vs ±1630, C24 end 44.2, C23 99.3 = table A vs front view, hoops 20.65 long, C25 9 bars, stirrups not wrapping main bars). `교각도(1)(P1~P2,P10~P12).dxf` is actually a binary DWG (AC1024): copy to a `.dwg` name and read via `RhinoDoc.CreateHeadless(None).Import`. Structural DXF front-view origin: s = x − 876439.2, z = y − 316296.8 + 7738.
- **COVER-120 FIX DONE 2026-10-06 (user: "구조도랑 같이 피복을 120에 맞춰서 수정")**: outer 1CYCLE bars (C1/C2/C3/C8/C10/C9/C26) moved to w=±1630; C19/C21/C23 hoops rebuilt with ends ON the 120 offset line (no 20.65 wrap; C23 ends ±11980, A 23.960 ≠ table 24.001 — user chose drawing/cover over table); C20/C22/C24 rebuilt so the hook bulge ends at the hoop end (straight end = hoop end − 60). Re-check: every mark top/bottom/end/side center cover = 120.0 against the DRAWING concrete outline. Backups `<mark>_bk1006` idefs. Idefs C1~C11 are SHARED with the P2/P10/P12 instances (UseCount 4) — idef edits change those piers too. Offset-line formulas: s_end(z)=11980−(9321.16−z)/0.375 (z<9321.16), s_in(z)=4919.47−(z−7858)·3. C25: the 9 piercing bars were flipped legs-UP (⊔, mirror about the top-bar centerline z; user chose "방향을 바꿔줘" 2026-10-06), other 105 stay legs-down; backup `C25_bk1006`. **Coping Brep top FIXED 2026-10-06** (user: "코핑 중심에서 대칭이 되어야"): rebuilt as profile extrusion with steps at ±3100/±6200/±9300 (62 each, 10738→10924), same GUID d7b51436 kept via Objects.Replace, bottom/ends/width/volume unchanged; old Brep kept on hidden layer `P1_두부(코핑)_백업_261006`. C26/C13/C14 top cover now 120 against the model too. Exact length angle = 19.1053°. STILL OPEN: stirrup-wraps-main-bar question. File saved (saved with only P1 layers visible, P2/P10/P12/CHECK/PIER_LABELS off).
- **2026-10-06 later**: material table written as `261006_철근재료표.dxf` (비고 column = diffs vs original table; C1~C11/C26 lengths re-measured = table exactly). C1/C2/C3 (Rc 76.2→88.9) and C26 (Rc ~58→66.85) rebuilt with KDS centerline radius (inner 3db + r), dims/end positions unchanged, flat caps; backups idefs `C1/C2/C3_bk1006r`, C26 originals on hidden layer `P1_C26_백업_261006`. Gotcha: sampling `BrepFace.PointAt` on flat CAP faces reads the untrimmed plane (points outside the bar) — skip planar faces in cover/extent checks.
- **END OF DAY 2026-10-02 — START HERE NEXT SESSION.** Model saved 13:46. Authoritative to-do list: `D:\★Pier 자료\클로드로 모델그리기\대호지교 P1\261002_수정해야할 부분.md` (done list, exposed/low-cover items, drawing mismatches, 4 pending user decisions: C25 9 bars / box bars outside main bars / coping top camber basis / C13~C17 leg split). Clash summary: `261002_간섭 부분.md` (118 mark pairs, 13,522 bar pairs, re-checked AFTER the hook fix and C12/C18 stub removal; CSVs regenerated to current state). `261002_철근 간섭 및 피복 체크.md` is the superseded first pass. Rhino `P1_CHECK_*` layers are still the pre-fix version.
- **Offset "short stub" fillers in 수직전단철근 (found 2026-10-02, user spotted "이상한 짧은 철근")**: every 4-piece box-def has 2 filler pipes built from SURFACE vertices → ~11.1 off the leg axis (look like separate stubs). Top stubs 14.9 (C12/C18) / 12.9 (C14/C16) at base-leg tops; mid 124 (C13/C15/C17) at lid-leg bottoms. Box heights (top/bottom z, station s) match the 정면도 for ALL stations (≤1mm z, ≤6mm s). Leg split vs drawing (B=full height, C=510): **C12/C18 MATCH** (base cap already at lidtop+7 → stubs are pure junk, removing them changes nothing); C13/C17 raised + C15 (base short by 124, lid 634) and C14/C16 (lap 392) do NOT match → user said leave those. **C12/C18 stubs REMOVED 2026-10-02 (user permitted)**: all 76 box-defs now 2 pieces (lid+base), ColorFromParent intact, lap 517; originals backed up as un-inserted idefs `<name>_bk1002`; file saved, view restored. C13/C15/C17 (124 mid stubs) and C14/C16 (top stubs) intentionally LEFT (legs don't match drawing split).
- **DONE 2026-10-02: VIII hooks (C20/C22/C24) re-oriented HORIZONTAL** per user ("갈고리 방향이 수평으로 되어야해 지금 코핑상면으로 향해있어"). Hook plane = horizontal, curling toward the OUTSIDE of the width (sign of w; inward would make the ±106 bars' hooks cross each other). A/L unchanged. Center cover now: C20/C22 min 93.3 (hook tips toward haunch diagonals), C24 43.9 at end faces (hook bulges 60 past straight end — still open). File saved. CHECK layers/CSVs are from BEFORE this change. Rule for future VIII bars: hooks horizontal, never up/down.
- **(was) NEXT TASK (user, 2026-10-02): fix the 수평전단철근 (C19~C25) FIRST — user says one of today's bars has a wrong bar DIRECTION ("철근 방향이 오늘 만든것중에 있어").** Which mark/what direction was not yet specified — ask at the start of the next session (candidates to look at: VIII hook orientation (turned UP by me, legend shows down), C25 ⊓ leg direction/the 9 piercing bars, hoop/bar orientation). This comes before the other pending fixes (C14/C16 lap, 1CYCLE outer ±1630, box bars vs main-bar centerline).
- **C1~C11 status**: top-mat rebar, already modeled as block instances under layers `P1_두부_주철근_1CYCLE::C{n}_H25` / `..._2CYCLE::C{n}_H25`. C1 is a 14-bar array at H25, top level Z≈10618 (block instance bbox top ≈10630.7, i.e. bar-surface top) — this Z level is the datum other marks (e.g. C12's lid) tie into. Colors currently by CYCLE (1CYCLE=red, 2CYCLE=blue), **not yet converted to the diameter-based scheme** — still needed: H25 and H29 ACI color numbers (not on the color chart image seen so far, which only covered H10/H13/H16/H19/H22 — ask the user again if picking this up).
- **Shape V (양곡) family = "⊓ lid + ⊔ base" overlapping box, NOT a single diagonal-following bar.** Icon (user's `V.철근형상.png`): top segment "a"(=table col A) oriented along the 3500mm width, left leg "b"(=table col B, variable) down, right leg "c"(=table col C) — but the *physical* construction (confirmed by user) is two separate overlapping pieces: a fixed-length "lid" (⊓, legs = the SHORT fixed value, opens downward from the C1 top-bar level, "뚜껑") + a variable "base" (⊔, legs = the value that grows with haunch depth via ray-cast underside+120mm cover, opens upward) — both symmetric (same length both legs), coincident/overlapping at this design stage (front/back offset to avoid physical clash is a construction-detail-stage decision, not modeled). Multiple such boxes nest across the width (e.g. C12's 1005/1250/1250/1005mm pattern, overlapping, cover120/625mm from each edge).
- **C12/C18 (H22) — left/right haunch, DONE.** Layers `P1_두부_주철근_1CYCLE::C12_H22` / `...C18_H22`, each a single top-level block instance (nested: mark block → per-station block `C12_XX` → per-box-type block `C12_1005_XX`/`C12_1250_XX` → leaf pipes). C12 = near END_A (coping's s_min end), C18 = mirror near END_B. **Final corrected station schedule** (measured from the coping end face, first bar at cover120+130=250mm): **7@300mm=2100mm (8 stations) then 11@150mm=1650mm (11 stations) = 19 stations total**, ×4 width-boxes = 76 boxes matching the material table qty exactly (152 physical bars incl. both lid+base pieces). Box widths 1005/1250/1250/1005mm as above.
- **C13/C17 (H22) — continue right after C12/C18's last station.** 13 stations each (S=4150~7150 from END_A for C13): 3@150=450mm (3) + 8@300=2400mm (8) + 2@150=300mm (2), starting one gap after C12's/C18's final station (S=4000). Same 4-box width pattern as C12.
- **C14/C16 (H22) — continue right after C13's/C17's last station** (corrected — earlier "starts from C26" was wrong/caused overlap with C13; user corrected this). 10 stations (S=7300~8650 from END_A for C14): 10@150=1500mm, starting one gap after C13's final station (S=7150).
- **C15 (H22) — continues right after C14's last station**, standalone/centered (no mirror pair — its own 26 stations already span the full center gap). 26 stations (S=8800~15400 from END_A): 4@150=600mm (4) + 19@300=5700mm (19) + 3@150=450mm (3), starting one gap after C14's final station (S=8650). 26×4=104 boxes, matches material table qty exactly.
- **IMPORTANT: do not reuse the DXF's combined dimension-chain numbers directly for C13/14/15 without care.** The actual coping structural drawing has ONE continuous symmetric dimension chain per side (120|7@300=2100|14@150=2100|8@300=2400|16@150=2400|19@300=5700(center)|...mirrored...) where individual segments often combine TWO adjacent marks' gap counts into one drawn dimension (e.g. "14@150" = C12's remaining 11 gaps + C13's own 3 gaps, drawn as one line) — attributing DXF segments to marks by callout proximity alone is unreliable; the user's direct verbal station/spacing statements (as recorded here) are what was actually built and are authoritative for this model.
- **C26 (H19, shape III) — DONE.** Centered ㄷ-shape (⊓, both legs equal — NOT the asymmetric lid+base pattern): straight span A=12.160m centered on the coping's longitudinal midpoint (S≈12100mm from END_A), with a 90° hook B=350mm bending down at each end (total developed length 12.160+2×0.350=12.860m, matches material table exactly). Flat straight-portion Z = **10742mm** (= coping's center-plateau top EL10924 minus 182mm cover — NOT the C1/global-lowest datum of 10618, since C26's span sits entirely within the higher central portion of the coping's stepped top camber and never reaches the coping's absolute lowest edge; using the global-lowest datum put it noticeably too low). General lesson: **the "flat bar, cover120 from lowest point" rule must use the lowest point actually crossed by THAT bar's own span, not automatically reuse another mark's datum** — check the top-camber profile (ray-cast) over the specific S-range before picking a Z. 15 bars across the width, center-out at 250mm CTC (matching C1's own array method: pure grid, outermost pair snapped inward to maintain cover120+radius from each edge). Layer `P1_두부_주철근_1CYCLE::C26_H19`, color magenta (ACI 210).
- **C13/C14/C15/C16/C17 (H22) — datum-raise fix DONE (2026-09-21, corrected).** These marks were originally built with every station's lid top at the same low datum as C12/C18's lid (centerline Z=10618, surface Z=10629.1 for H22's r=11.1) — but the portion of the coping they sit under is the same elevated center plateau C26 already used (centerline Z=10742, surface Z=10753.1 for H22). **User-specified exact scope** (decided in an earlier session, previously lost — write scope decisions down immediately): only the C14-ward/center-ward tail of C13 and C17 — stations **09,10,11,12,13** (last 5, counting inward from the C14 side) and mirrored C17 stations **v2_09..13**; C14, C15, C16 raised **in full** (all 10/26/10 stations), since their whole span sits within the plateau ("C14,15,16은 전부 다 C26 위치에서부터 시작").
  - **First attempt (WRONG, reverted the same session): rigid +124mm Z-translate of the whole station sub-block.** This was wrong because these marks are the SAME lid(⊓)+base(⊔) overlapping-box construction as C12/C18 (see the Shape V bullet above), not a single uniform-height box — rigidly translating the whole station moves the **base** piece too, which must stay exactly where it was (its bottom ties to the ray-cast underside+cover, independent of the top datum). The "uniform Zmin/Zmax across stations" observation that seemed to justify a rigid shift was a red herring — it just meant those particular stations' base leg happened to be constant-height, not that the lid+base split didn't apply.
  - **Correct method: extend only the lid, leave the base untouched.** Per box-def (e.g. `C14_1005_01`, holding exactly 2 leaf Breps): identify the **lid** as the Brep with the smaller Z-span (base has the larger/varying span); get its `.Vertices` (exactly 2, both sitting at the lid's own Zmin — these are the two leg-bottom tie-in points, since the lid is an open-ended ⊓ pipe with its bend at the top and its two open ends at the bottom); duplicate the lid Brep and translate the duplicate by `(0,0,+124)`; for each of the 2 bottom points, build a straight filler pipe from the original (fixed) point up to `point+124` in Z via `Rhino.Geometry.Brep.CreatePipe(LineCurve(Line(p, p+dz)), radius, False, Rhino.Geometry.PipeCapMode.NONE, False, tol, angleTol)` (note the enum member is spelled `NONE`, not `None` — `PipeCapMode.None` is a Python syntax error since `None` is a keyword); replace the box-def's geometry list with `[shifted_lid, base_brep_unchanged, filler1, filler2]` via `InstanceDefinitions.ModifyGeometry(idef.Index, newlist)`. This exactly preserves the lid/base overlap length (510mm here) and genuinely lengthens the lid's bar (matches the user's own framing: "위에 510[mm] 부분은 고정이니 철근이 더 길어져야 한다" — the fixed short lid dimension doesn't change, the bar just gets a longer straight run before its bend). Box-def naming convention confirmed general across these marks: `<mark>_<width:1005|1250>_<stationsuffix>` where stationsuffix is the station block's own name with the `<mark>_` prefix stripped (e.g. station `C17_v2_09` → box-defs `C17_1005_v2_09` / `C17_1250_v2_09`).
  - Verified post-fix (world-space, via the mark's outer instance bbox): all 5 raised marks now read Zmax=10753.1 (lid's new top), while **Zmin is exactly unchanged from the pre-fix value for every mark** (C13/C17=7846.9, C14/C16=7880.2, C15=8346.9) — proof the base pieces were untouched. Un-raised C13 01-08 / C17 v2_01-08 stations remain at the original Zmax=10629.1.
- **C4/C6/C5/C7 (2CYCLE tier1/tier2, H25) cover-convention fix — DONE (2026-09-22).** These 4 marks had been built using CLEAR/SURFACE cover (bar surface exactly 120mm/220mm below the coping top surface) while C1 (1CYCLE) was already built using CENTER cover (bar centerline exactly 120mm below) — an inconsistency the user caught by inspection. Root-cause check: coping top surface's real minimum Z within each mark's own footprint (ray-cast, both C4/C5's span and C6/C7's span independently checked) = 10738.000 in both cases (matches the coping-wide global minimum too, i.e. the low point recurs near both columns symmetrically). Fix: moved each of C4/C5/C6/C7's single doc-level instance object by `(0,0,+12.7)` (exactly one H25 radius) via `rs.MoveObject` — a plain rigid translate, no rebuild needed since these are simple flat un-nested single blocks (unlike C12-C18's per-station nested structure). Verified post-fix: center-to-surface cover reads exactly 120.000 (C4/C6) and 220.000 (C5/C7).
- **C2/C3/C8/C9/C10/C11 cover-convention audit — DONE (2026-09-22), user confirmed scope "주철근 및 수직전단철근 까지 전부다 포함".**
  - **C2, C3**: already correct (center-cover, exactly 220.000mm) — no fix needed. Each is a single-bend (hook) shape: one long flat main span (world Z=10518.0) + a short hook dropping to Z=0 at one end only. The hook doesn't affect the cover check on the main span.
  - **C9 (H29), C11 (H25)**: simple flat single-tier arrays (bbox Z-span exactly = bar diameter, confirms non-bent). Both were surface/clear-cover 120mm from the coping's BOTTOM surface (EL 8238.0, confirmed via ray-cast at C9/C11's own footprint). Fixed via plain `rs.MoveObject` rigid shift **toward** the reference surface (DOWN, since surface is below) by exactly one bar radius: C9 by -14.3 (H29), C11 by -12.7 (H25) — **mistake made and caught**: first applied C9's H29 radius (-14.3) to C11 too by copy-paste error; caught via post-fix verification (center didn't land on the expected clean value) and corrected with a +1.6mm follow-up move. **Lesson: always use each mark's own bar diameter for its shift — never reuse a shift constant computed for a different-diameter mark.** Both now read exactly 120.000mm center-cover.
  - **C8, C10 (H25) — the hard case, DONE.** Not simple bars: each of the 14 parallel bars per mark is a single Brep with **11 real topological vertices** and 9 Faces, tracing hook→diagonal-down→flat "valley"→diagonal-up→hook (the bar physically follows the coping's stepped haunch underside profile, unlike C12-18's simple 2-leg V/⊔ boxes). Root cause: the flat "valley" span (~3133mm long) was built at clear/surface-cover 120mm from the coping's absolute-lowest bottom plane (EL 7738.0, same global-min plane used elsewhere in this project), not center-cover.
    - **Automated path/segment extraction (reusable for any future multi-vertex bent-bar fix)**: collect `Brep.Edges`, keep only "travel" edges where `start.DistanceTo(end) > 1.0` (filters out the small circular "rim/seam" edges at each joint, length ≈ pipe circumference `2·π·radius` but start≈end), dedupe reversed-duplicate edges (same edge often appears twice, once per adjacent face), build a node/adjacency graph from survivors, find the 2 degree-1 nodes (the bar's true open ends), walk the graph between them for the ordered vertex path. Reliably reconstructed the identical path for all 28 bars (14×C8, 14×C10) with zero manual coordinate entry.
    - Identify the target "flat" segment generically: the consecutive path pair with `|dz| < 2.0` AND horizontal length `> 500` (filters out short bend/joint edges that happen to be locally near-flat).
    - **Gotcha: which side of the pipe a vertex represents (top surface vs bottom surface) is NOT assumed — it flips between mirrored bars.** For C8, the flat segment's vertices sit at local Zmin (bottom surface, confirmed by matching the segment's own tight bbox minimum). For C10 (a mirror of C8), the *same-role* path vertices instead sit at local Zmax (**top** surface) — confirmed because C10's overall leaf bbox still bottoms out at local Z=0.0 while the detected flat-segment vertices read Z=25.4 (=2×radius, the far/top side of the same physical line). A vertical downward ray-cast from the raw vertex therefore read a confusingly-different "cover" number for C10 (145.4) vs C8 (120.0) even though **the correct fix (shift by exactly one radius, -12.7, toward the coping surface) was numerically identical for both** (145.4 − 2×12.7 = 120.0, consistent once you account for which surface the vertex is on). **Always verify a multi-vertex bar's vertex-to-surface convention per mark via its own bbox before trusting a raw vertex-based ray-cast number at face value — mirrored geometry can flip which side of the pipe a same-role vertex sits on.**
    - **Fix method — extract-shift-refill, not full rebuild**: match the flat segment's 2 neighboring "transition" sub-segments to their corresponding `Brep.Faces` entries by checking which face's bounding box contains both segment endpoints' X,Y (robust — same face indices `[3,4,5]` for all 28 bars). Duplicate the whole leaf Brep and `Faces.RemoveAt` the 3 target face indices (highest index first) + `.Compact()` to get the "unchanged" remainder (hooks + both long diagonals, byte-for-byte original). Separately `Faces[i].DuplicateFace(False)` the 3 target faces and `.Translate(0,0,-12.7)` as one rigid group (preserves exact relative shape, sidesteps needing to determine true centerline offset direction at the bend joints — key insight avoiding a much harder "recompute centerline via local pipe tangent" problem). Bridge the two new gaps (unchanged-anchor D/G ↔ shifted D'/G') with a fresh `Brep.CreatePipe(LineCurve(Line(anchor, shifted)), radius, False, PipeCapMode.NONE, ...)` filler each. Final leaf = `[unchanged_remainder, shifted_face×3, filler×2]` (6 Brep pieces replacing the original 1), submitted via `ModifyGeometry` with each piece's attributes = `Duplicate()` of the ORIGINAL leaf's own (unmodified) attributes — **for C8/C10 specifically the correct `ColorSource` is `ColorFromLayer`, NOT `ColorFromParent`** (unlike C12-18's deeply-nested mark→station→boxtype→leaf structure; C8/C10 are shallow doc-instance→leaf, same as untouched C1/C9 — don't blindly force ColorFromParent on marks with different nesting depth).
    - `Brep.JoinBreps` on freshly-`CreatePipe`'d segments returned them unjoined (no-op, same count in/out) — don't rely on it; multiple separate Brep pieces per leaf (as already established for C12-18) is the working pattern.
    - Verified post-fix (both marks, all 14 leaves each): shifted flat segment's own bbox = `[-12.70, 12.70]`, true center-to-coping-surface cover reads exactly 120.000mm. Visual wireframe check (coping hidden, C8+C10 isolated) shows smooth continuous hook→diagonal→valley→diagonal→hook profile, no gaps/spikes. ColorFromLayer confirmed intact (84 pieces × 2 marks).
- **Diameter-based color scheme (from user's `직경별 철근 색상표.png`, ACI color index numbers)**: H10=74, H13=74 (olive-green, RGB 0,129,0), H16=5 (blue, 0,0,255), H19=210 (magenta, 255,0,255), **H22 and every diameter above it (H25, H29, and any future larger mark) = ACI 246, dark red/maroon RGB(104,0,25), all the SAME color** — confirmed by user 2026-09-23: "H25,H29는 H22색상을 따라간다고 이전에도 말했는데 저장을 안했구나... H22이상은 전부 같은색상이야" (told in an earlier session, lost because it wasn't written down — reminder to save color/spec statements immediately, not just geometry facts).
  - **Applied and DONE (2026-09-23)**: set `rs.LayerColor(layer, (104,0,25))` on all 11 C1~C11 H25/H29 mark layers (1CYCLE: C1,C2,C3,C8,C9,C10; 2CYCLE: C4,C5,C6,C7,C11). Found the layers were **already** at (104,0,25) before this edit — meaning the earlier memory note "colored red/blue by CYCLE" was stale (fixed directly in Rhino at some point without being recorded); this edit was a harmless confirm/no-op. Verified: every leaf object within each of these idefs has its OWN `LayerIndex` pointing at that same mark's own layer (not an incidental one) with `ColorSource=ColorFromLayer` — **for C1-C11 (shallow doc-instance→leaf structure, same depth as C8/C10) `ColorFromLayer` set on the mark's own layer is the correct/working mechanism, NOT `ColorFromParent`** (that only matters for C12-C18's deep mark→station→boxtype→leaf nesting). Visual wireframe check (C1,C9,C4,C11 isolated) confirms all four show the identical maroon color.
- **Cover convention (user-confirmed 2026-09-22, applies project-wide): "피복 120mm" means the REBAR'S CENTERLINE sits exactly 120mm from the concrete surface — not clear/surface-to-surface cover.** User's exact words: "항상 철근의 중심을 피복에 놓고 그려줘 120이라하면 120위치에서 원의 중심이 시작되는거야" (always place the rebar's center at the cover distance — if it's called 120, the circle's center starts at the 120 position). This matches how cover was already being measured in this project (centerline-to-surface, e.g. C1's "cover120" and the C12 base ray-cast measurement below) — this is a confirmation/lock-in of the existing convention, not a change, but write it down explicitly since it deviates from the textbook KDS definition of 피복 (clear cover to nearest bar surface) and must not be "corrected" to clear-cover in some future session.
- **TODO #1 scope confirmed 2026-09-22: base-leg cover fix applies to the ENTIRE C12~C18 haunch family** (C12, C13, C14, C15, C16, C17, C18 — all stations, both 1005/1250 width box-defs each), not just C12. User's exact instruction: "C12~C18까지 전부다 반영이야" (C12 through C18, apply to all of them).
- **C12~C18 base-leg underside cover fix — DONE (2026-09-22).** All 224 box-defs across the 7 marks (C12=38, C13=26, C14=20, C15=52, C16=20, C17=26, C18=42) checked; 188 needed correction (now 4-leaf: lid + shifted-base + 2 fillers) and 36 were already exactly 120.000mm (skipped, left as original 2-leaf — mostly C13/C17 stations 01-08, which sit on the coping's flat absolute-lowest plane EL7738 and were already exactly right; also C18's 2 end stations). Post-fix spot-checks (C15_1005_05, C18_1250_10, plus the full C12 set) all read exactly 120.000mm. ColorFromParent verified intact on all 224 idefs' leaf objects after the fix (0 broken).
  - **Cover must be measured as the SHORTEST/PERPENDICULAR distance to the real coping Brep (`Brep.ClosestPoint`), not a blind vertical ray-cast** — the underside near a haunch is often sloped, and a straight-up/down ray can miss the true nearest face and either hit nothing (travel hundreds/thousands of mm before hitting an unrelated distant face) or land on a coincidentally-round wrong number. `Rhino.Geometry.Brep.ClosestPoint(testPoint)` against the whole real coping Brep (id `d7b51436-d411-4ed6-be00-5af9d2058029`) is the reliable method.
  - **Ray/cover direction gotcha: the coping's underside is BELOW the rebar, not above.** The rebar sits inside the concrete just above the bottom-facing exposed surface; cover = rebar.Z − surface.Z (positive), found via `closest_on_coping.DistanceTo(rebar_point)`, not by shooting a ray "up looking for concrete." Shooting up from the bar point (an early wrong attempt) sailed past the whole rebar cage and found the coping's TOP surface far away instead — a strong red flag if seen again.
  - **A box-def's bottom "bend" point (for a ⊔/V-shaped base leg swept as a single pipe with no vertex at the bend) is NOT any bounding-box corner** — bbox min/max X,Y,Z are independently-minimized per axis and do not correspond to a real point on a curved/bent pipe surface. Find the true point via `face.ClosestPoint(probe)` where `probe` = (local bbox X/Y center, bbox.Min.Z − large margin) — i.e. closest-point-from-straight-below the shape's own center; the result's Z should exactly equal the brep's own bbox.Min.Z when correct (sanity check). Then centerline point = that surface point + radius (11.1mm for H22) in local Z.
  - **Fix method (mirrors the lid-extend pattern, flipped top/bottom): keep the TOP (open-end vertices, the fixed lap point with the lid) anchored; rigidly translate a DUPLICATE of the whole base Brep by the needed delta vector (computed in world space via the closest-point/target-120mm math, then converted to local space via the box-type instance's inverse `Xform` applied to the delta as a Vector3d — exact even under the coping's in-plane skew, no flat/no-tilt assumption needed); then bridge the gap at the TOP with 2 new filler pipes (`Brep.CreatePipe`, same radius, `PipeCapMode.NONE`) from each original (now-abandoned) top vertex to its shifted counterpart.** Final leaf list = `[lid_unchanged, shifted_base, filler1, filler2]`, submitted via the 3-arg `ModifyGeometry(idef.Index, geometryList, attributesList)` with every new/duplicated attribute's `ColorSource` forced to `ColorFromParent` (do not use the 2-arg overload — see [[feedback_ironpython_exec_scoping]]'s color-break root cause).
  - **To get a real WORLD transform for a deeply-nested box-def instance (mark→station→box-type→leaf) without manually chaining transforms**, duplicate the mark's doc-level instance, `rs.ExplodeBlockInstance(id, False)` one level (→ station instances, now placed at correct WORLD transforms), find the target station by its idef name, duplicate + explode that one level too (→ box-type instances, also now correctly WORLD-placed) — the resulting object's `Geometry.Xform` IS the correct full world transform for that box-def's own local content. Much simpler and more reliable than composing `InstanceReferenceGeometry.Xform` values by hand. **Always delete every duplicated/exploded temp object afterward** (leaf-level dedup by idef name first — a station typically instances each unique box-type idef twice, mirrored left/right at the same cover, since they share one idef).

- **TODO #2 — DONE (2026-09-22): re-applied correct color to every C13/14/15/16/17 box-def touched by the 2026-09-21 lid-extend fix.** Fixed via the 3-arg `ModifyGeometry(idef.Index, geometryList, attributesList)` overload with each attribute's `ColorSource=ColorFromParent`. All 112 box-defs (C14 01-10, C15 01-26, C16 01-10, C17 v2_01-13 — wait, only v2_09-13 + all C14/15/16 were in scope, ×2 widths 1005/1250) verified post-fix: every leaf object's `ColorSource == ColorFromParent`, 0 mismatches, 0 not-found. **Naming gotcha found during this fix: C13's box-defs (and only C13's) carry an extra `_r3` suffix** — actual names are `C13_1005_09_r3`..`C13_1250_13_r3`, not the plain `C13_1005_09` pattern used by C14/15/16/17's otherwise-identical box-def names. Always check actual `InstanceDefinitions` names (don't assume the documented naming pattern is 100% uniform across marks) before batch-targeting by constructed name strings. **User's own framing of why this keeps happening**: "자꾸 새로 철근 수정할 때마다 직경별 색상이 안 맞아" (every time rebar gets newly modified, the diameter-based color stops matching) — this is a recurring pattern across sessions; treat ANY future `ModifyGeometry` call on these box-defs as color-breaking by default and always pair it with the attributes-list fix in the same call.
- **How the two TODOs interact**: the C12-cover-fix TODO (#1 above) will itself call `ModifyGeometry` on C12's box-defs — when doing that fix, use the 3-arg attributes-preserving form from the start so it doesn't create a THIRD round of color breakage on top of the two above.

- **C8/C10 bend-radius (R) rebuild — DONE (2026-09-23).** User flagged that the cover-fix session's C8/C10 geometry (and likely the ORIGINAL pre-existing geometry too) had no real KDS bend radius anywhere — every corner (hook-tip kinks, the D/G diagonal-to-flat transitions) was a sharp/mitered joint between short straight `CreatePipe` segments, several of which (18-32mm) were physically too short to ever hold a real R=76.2mm(inner)/88.9mm(centerline) H25 fillet. **User-directed simplification**: no hook geometry to build (hook tips I and J keep their exact existing positions, "갈고리 없음 — 현재 훅 끝점 위치만 그대로 유지"); collapse the whole bar down to just 4 centerline points **I → E → F → J** (E,F = the already cover-fixed flat-valley endpoints) and put real R=88.9mm fillets at the two interior corners (E and F). Rebuilt via `Curve.CreateFilletCornersCurve` + single `Brep.CreatePipe` sweep — see [[feedback_kds_rebar_bend_radius]] for the full reusable method/gotchas (this is where to look next time any bent-rebar R needs building, not here). Result: each of the 28 bars (14×C8, 14×C10) went from a fragmented 6-piece assembly down to **one single clean Brep** (5 faces: 2 straight cylinder sections + flat section + 2 torus fillet patches). Verified post-fix: cover still exactly 120.000mm at the flat segment for both marks (bbox now identically `[-12.70, 2159.83]` for C8 and C10 — this symmetry check is what caught a mid-fix bug where C10's mirrored vertex convention caused the first attempt to add the bar radius in the wrong direction, landing the flat segment 25.4mm too high; fixed by using bbox-center instead of vertex+radius for the centerline, see the linked memory). ColorFromLayer preserved. Visual check: both marks show a clean, simple, symmetric hook→smooth-diagonal→flat→smooth-diagonal→hook silhouette.
- **CLASH / COVER CHECK 2026-10-02 (no model edits; user: "수정은 추후에")** — report `261002_철근 간섭 및 피복 체크.md` + CSVs (`261002_철근 간섭 목록.csv`, `261002_철근 피복부족 및 튀어나옴 목록.csv`) in the drawings folder; Rhino layers `P1_CHECK_튀어나옴_피복부족` (TextDots, cover<100) and `P1_CHECK_간섭` (point cloud). Key results: exposed = only C25 ×8 (+1 cover 37); C24 hooks bulge 60 past straight ends → end cover 43.9; C26/C13/C14 tops at 10742 have only 58 cover on s<0 side (model top 10800 there — asymmetric camber); C23 ends 99.3. Clashes: box bars C12~C18 sit ON main-bar centerlines (pen 23.8) and ON hoop/C25 legs at w±1630 (19.0); C1×C2/C3 hook, C1×C8/C10 a-leg (lap), C8/C10×C9, C26×C4~C7, VIII-end×hoop 15.7, C25×side bars 15.9. Method: centerline segments via isocurve ToPolyline(tol 0.3) + opposite-param midpoint, RTree.SearchOverlaps (RTreeEventArgs.Id/IdB, handler via System.EventHandler[RTreeEventArgs]), Line.MinimumDistanceTo fallback for parallel; cover via 2D section polygon + |w| (coping is a w-extrusion) — 7s for all marks.
- **SESSION STATE 2026-10-02 12:31 (user: "좀이따가 보자")**: model file SAVED with all layers visible. Later (13:30) all layers turned back on and saved again — no isolation pending. Pending user decisions: (a) C25's 9 piercing bars (shorten / flip ⊔ / keep), (b) fix C14/C16 lap 392→510, (c) move 1CYCLE outermost bars ±1617.3→±1630, (d) coping top step layout vs 구조도. Material-table DXF does NOT yet include C19~C25 — regenerate after decisions.
- **C19~C24 BUILT 2026-10-02** (layers `P1_두부_주철근_1CYCLE::C19_H16`..`C24_H16`, blue (0,0,255) ColorFromLayer, one idef per mark at identity, geometry in world coords). Hoops: closed polyline started mid-side, CreateFilletCornersCurve Rc=2db+r=39.75, pipe r=7.95, w=±1630; s-ends = 120-offset line + WRAP 20.65 (outside C8/C10 diagonals or C1 end legs) → A exactly = table. VIII bars: A = hoop A − 9 (4.5 inside each end), hook = 135° arc centerline R60 (=b 141 arc length) + 100 ext, **hooks turned UP** (down-hooks pierced the haunch diagonals — first C20 build was wrong and rebuilt). Counts 4/24/5/30/6/36 = table. Covers: sides 120 exact; diagonal ends ~112.7; C23 end faces 99.4 (consequence of table A=24.001 wrap). **C25 BUILT 2026-10-02 per user's definition**: ⊓ across width (top A=3260 at w=±1630, legs 300 DOWN at both sides), one bar per CSBSEC1 dot in the 코핑구조도 정면도 (x0=876439.2 → s=x−x0, NOT mirrored; y0=316296.8 ↔ z=7738): rows z=10742 (8 @1200 s−2850..5550), 10495.5 (32 @600, |s| 2250..11550 in two groups), 10258 (20 @1200), 9658 (19), 9058 (19), 8458 (16) = 114 = table. Fillet 2db, L 3.860. **OPEN: 9 bars' legs pierce/under-cover the underside** (z=8458 row s=−3450..3750 center bottom 8238, s=−9450 z8458, s=−11250 z9058) — asked user how to treat (flip/shorten/keep). Mesh-based cover checks gave a bogus 108.5 — verify with Brep.ClosestPoint on a few points; full Brep sampling of long bars times out.
- **C19~C25 (H16) drawing review** — drawing review 2026-10-02 (sections A-A end / B-B over column / C-C center of 코핑구조도).** Drawing marks = C1~C26 exactly = 재료표 (no extra marks). Side-face horizontal bars at 200 vertical spacing, levels (model z, bottom-over-column 7738): 8058, 8258 | 8458…9258 | 9458…10458 (13 levels in B-B).
  - VI = closed rectangular hoop, L=2A+2B, B=3.260 (w=±1630; drawing dots shown at ±1594 = symbol offset inside box legs). C19: 2 levels × 2 column regions (bounded by end-haunch & inner-haunch diagonals, A 5.466~4.333) = 4. C21: 5 levels 8458~9258 full length bounded by end diagonals (A 23.664~19.397) = 5. C23: 6 levels 9458~10458, A=24.001 (=end-face cover 23.96 + wrap outside C1 legs) = 6.
  - VIII = straight bar + 135° hooks both ends (b=141, c=100, r=60; L=A+0.483). 6 per level at interior w = ±89, ±661, ±1089 (just inside the inner box legs). C20 = C19 levels (2×6×2=24), C22 = C21 levels (5×6=30), C24 = C23 levels (6×6=36). A ≈ matching VI A − 9.
  - C25 (III, A=3.260 ⊓ across width, legs B=300, 114 ea, "H16 @ 600"): seen as 3260 lines in sections at ~600 vertical spacing + plan "38@600=22.800" (120|730|…|430|120) — exact placement still UNCERTAIN, confirm with user.
  - Correction to the +47 finding below: the sections draw C12 box legs at w=±1630/±1125/±625/±125 with widths 1250/1005 — SAME as model. So table A/B (+47) is the table's dimension convention, not a model error.
- **Full audit vs DXF 2026-10-02 (output: `261002_철근재료표 작업중.dxf` in the drawings folder, R12/ANSI_949, same columns as 원 재료표 + 비고 column).** C1~C11: count, dims, longitudinal s-ranges all = DXF/table exactly. Findings NOT yet fixed (await user): (1) 1CYCLE outermost bars (C1,C2,C3,C8,C10 at w=±1617.3; C9 ±1615.7; C26 ±1620.4) use surface-cover 120 at the side faces — DXF plan puts them at centerline 120 (w=±1630); 2CYCLE ±1500 is correct. (2) C12~C18 table A=1.297/1.052 and box heights are exactly model+47 (=2×(12.7+11.1)) → drawing has stirrups wrapping OUTSIDE the main bars; model stirrups sit on main-bar centerlines. Table V convention verified: L = 2A + 2B + 2C, B = full box height, C = 510 lid lap. (3) C14/C16: ALL box-defs lost the 124mm lid-extension fillers (the later base-cover fix rewrote the geometry list as [lid,base,2 tiny fillers]) → lid–base lap 392 < 510. C13/C17/C15 kept their fillers (C=634). (4) C26 A=12.165 vs 12.160. (5) Model coping-top step positions (±1550/4650/7750/10850, asymmetric) differ from the 구조도 front view (symmetric ±3100/6200/9300) — likely 일반도 vs 구조도 difference, ask user. Measurement tricks: pipe centerline length = average of two opposite rail isocurves (fast); Brep area via AreaMassProperties times out over MCP.
- **C8/C10 rebuilt AGAIN 2026-10-02 to the drawing's shape VII (supersedes the 09-23 I→E→F→J rebuild).** Source: 코핑구조도 ①CYCLE assembly (C8 polyline in DXF: a=630 vertical leg UP at the end-face cover line, b=4167.1 diagonal along end haunch, c=3158.8 flat over column, d=2331.1 diagonal UP along inner haunch, continuing past the haunch into the center region as anchorage) + 재료표 X1=159°/X2=162°. Coping section in local frame (u=19.105°, origin=coping bbox center 480714926,153833329.5): s=±12100 end face z9238~10738, end diagonal to (±8100,7738), flat to ±4900, inner diagonal to (±3400,8238), center flat. Offsetting every face 120mm inward gives centerline pts (s>0 side): (11980,9951.16)-(11980,9321.16)-(8078.24,7858)-(4919.47,7858)-(2708.09,8595.13) — b and c lengths fall out EXACTLY equal to the drawing (validates drawing = 120 centerline offset). In this frame C8 is on s>0, C10 on s<0. Built per bar (kept old w positions, ±1617.3 outer / 250 CTC) with CreateFilletCornersCurve Rc=88.9 + single CreatePipe, ModifyGeometry with original attrs (ColorFromLayer). Verified: bar-surface clear cover 107.34 everywhere = 120 centerline. Old geometry kept as un-inserted idefs `C8_backup_20261002` / `C10_backup_20261002`. Gotcha: FastRenderMesh-vertex cover checks gave bogus low numbers (91~104) — sample BrepFace.PointAt grid instead.
- **2026-10-02 color fix #3 (station level):** C13~C17 still drew tan (coping layer color) because their STATION-level instances inside the mark idef were `ColorFromLayer` on layer `P1_두부(코핑)` (C12/C18 stations were already `ColorFromParent`). Fixed by `ModifyGeometry(markIdef, geoms, attrs)` forcing station attrs to ColorFromParent for C13..C17 — all 3 nesting levels (station/box/leaf) must be ColorFromParent. Also found 7 stray C18 box instances (C18_1250_01/C18_1005_01/_19) floating at Z≈17000~21300 on the coping layer — leftovers; DELETED 2026-10-02 with user approval (coping layer now holds 3 objs: coping Brep + 2 curves).
- Views: "Left" viewport camera rotated to coping long axis (19.105° from world X); the 4th viewport (was a 2nd Perspective) converted to parallel, renamed "Front", looking along 109.105°, Wireframe. Geometry untouched.
- **RESOLVED 2026-10-02 via DXF (`철근재료표 및 상세(P1~P3,P5~P8).dxf` + `코핑구조도(P1~P3,P5~P8).dxf`): C8/C10 have NO 2CYCLE counterpart — standalone by design.** Material table 주철근 group = only C1~C11 (C8, C10 = shape VII, H25, 14EA each, A=630/B=4.167/C=3.159/D=2.331, X1=159°/X2=162°, L=10.287m; no other VII mark). 주철근 조립도 ①CYCLE view labels C1,C2,C3 (top) + C8,C9,C10 (bottom); ②CYCLE view labels C4,C5,C6,C7 (top) + C11 only (bottom). Every mark's own callout is "@250" (14 bars across 3.5m), so 250 is per-mark spacing, not a 1+2CYCLE interleave result. Remaining unbuilt marks from table: C19(VI,H16,4), C20(VIII,24), C21(VI,5), C22(VIII,30), C23(VI,6), C24(VIII,36), C25(III,114) — all H16. Original question history follows: does C8/C10 have a missing 2CYCLE counterpart mark? User asked to re-verify why bottom main rebar's 1CYCLE/2CYCLE marks show "250mm spacing" — investigation found: (a) 2CYCLE layer only has C4,C5,C6,C7,C11 — no mark shaped like C8/C10 exists in 2CYCLE at all; (b) C8's own 14 bars are independently spaced at ~250mm CTC on their own (measured via consecutive-leaf tip-point distances, consistently 242-250mm), and C1's own 14 bars show the exact same self-sufficient ~250mm pattern — i.e. neither C1 nor C8 actually NEEDS a 2CYCLE partner to reach 250mm (contradicts an initial assumption that 1CYCLE alone would be at 500mm, needing 2CYCLE interleaved to densify to 250mm); (c) meanwhile C9(1CYCLE)+C11(2CYCLE) ARE an explicit interleaved pair (C11's own description literally says "interleaves between 1CYCLE bars"), and C1(120mm cover)+C4/C6(120mm cover) / C2,C3(220mm cover)+C5/C7(220mm cover) match up by cover value too. Given this mixed pattern, **could not determine from Rhino geometry alone whether C8/C10 are correctly standalone (no 2CYCLE partner by design) or are missing a not-yet-modeled 2CYCLE counterpart** — needs the user to check the material table/배근도 directly.

**Why:** these are drawing-derived facts and hard-won modeling corrections not re-derivable from the Rhino scene alone — several rounds of wrong shapes/positions occurred before landing on the above (see [[feedback_coping_haunch_rebar_method]] and [[feedback_ironpython_exec_scoping]] for the mechanics/gotchas). Re-deriving any of this from scratch would repeat the same mistakes.

**How to apply:** when continuing P1's cap-beam rebar (C15 not yet done — its own B value is a single 2.431m, not a range, per the material table; other marks beyond C26 not yet started), reuse the exact station/box/color conventions above rather than re-deriving. Always verify new block-instance placements by comparing bounding-box X against the expected world coordinate before trusting it (see [[feedback_ironpython_exec_scoping]] on `AddBlock`'s unreliable re-basing).