Pier_v1/context-migration/memory/feedback_kds_rebar_bend_radius.md

name, description, metadata

name	description	metadata
feedback-kds-rebar-bend-radius	Rebar bend rule = KDS 24 14 21 Table 4.5-1 ONLY (KDS 14 20 50 not used) + validated Rhino method for building bent rebar	node_type type originSessionId modified memory feedback 3f00c5a2-89d3-4ff6-bce0-294eebc0a639 2026-09-22T05:31:31.332Z

Rebar bend geometry follows KDS 24 14 21 4.5.2.1 Table 4.5-1 (min inner bend diameter, not radius). KDS 14 20 50 (building code) does NOT apply to this project - user ruled it out 2026-10-22.

• Deformed bar: D16 or less 2db / D19 or more 3.5db (inner radius 1db / 1.75db). Plain bar: 1.25db / 2.5db.
• Standard hook (4.5.4.2): 90-150 deg bend, extend >= 5db past the bend; >=150 deg also >= 5db.
• Nominal bar diameters (KS D 3504): H16=15.9mm (commonly 16), H19=19.1, H22=22.2, H25=25.4, H29=28.6.
• Already-built P1 models used R=3db (H25 R=76.2mm) / 4db (H29 R=114.4mm): old values, larger than the KDS 24 14 21 minimum, so not violations - but they are NOT the standard.
• Which R to use for NEW modeling (code minimum vs previous practice) is the user's decision - [미확정], ask before building.

Why: user wants only the bridge code (KDS 24 14 21) carried in this project; the earlier 14 20 50 table was a building-code carry-over that does not fit.

How to apply: compute inner radius from Table 4.5-1 (or the user-confirmed value), then centerline fillet radius = inner radius + db/2. See reference_kds_24_14_21 and project-pyeonggang1-modeling-standard.

How to actually build a real KDS-compliant curved bend in Rhino (method validated 2026-09-23, project_p1_pier_structure C8/C10 rebuild)

Do not build bent rebar as multiple straight Brep.CreatePipe segments joined at sharp/mitered corners — this was the original (wrong) construction found in C8/C10: many tiny straight sub-segments (some as short as ~18-30mm) meeting at sharp vertices with zero bend radius. A real KDS bend needs an actual circular fillet arc at the corner, and short straight segments physically cannot fit a realistic bend radius (e.g. R=76.2mm for H25 needs the arc's two tangent legs to each have that much straight room on both sides — a corner between two ~20-30mm segments cannot hold it at all). If straight segments were pre-built that short, first simplify the path to only its真正 structural corners (e.g. collapse "hook tip → tiny kink → tiny kink → long diagonal" down to just the long diagonal's own two endpoints) before fillet-ing — don't try to fillet every pre-existing micro-corner.

The actual working method — one clean call, not manual arc/tangent-point math:

1. Build the full centerline path as an ordered list of Point3d (the bar's true corner/anchor points — hook tips, bend points, straight-span ends). Convert to a Rhino.Geometry.Polyline then .ToPolylineCurve().
2. Centerline fillet radius = KDS inner radius R + bar radius (db/2) — e.g. (past P1 case, old value, not the standard) H25: R_inner=76.2mm + db/2=12.7mm → centerline radius = 88.9mm. (The inner radius is the radius of the bend's inner face, not the centerline — always add the bar radius to get the sweep-rail radius.)
3. Call Rhino.Geometry.Curve.CreateFilletCornersCurve(polylineCurve, centerlineRadius, tolerance, angleTolerance) — this single static method fillets every interior corner of the polyline in one call and returns a PolyCurve with the true endpoints preserved exactly (start/end untouched, only interior corners rounded). Far simpler and more robust than manually computing per-corner tangent points and building/trimming arcs by hand.
4. Sweep one single pipe along the whole resulting smooth PolyCurve via Brep.CreatePipe(filletedCurve, barRadius, False, PipeCapMode.NONE, False, tol, angleTol) — this gives ONE clean Brep for the entire bent bar (not a fragmented multi-piece assembly), since the curve itself is already one continuous smooth path.
5. Verify the fillet radius actually landed correctly by sampling curvature along the filleted curve before piping it: loop t across curve.Domain, call curve.CurvatureAt(t).Length (=kappa), and check 1.0/kappa at its minimum equals the intended centerline radius (88.9 in the H25 example) — this was the actual validation step used and it matched to 5 decimal places. (Checking curvature on the final pipe's boundary edges afterward is unreliable — pipe edges mix in the cross-sectional circle's own curvature; always validate on the rail/centerline curve itself, pre-pipe.)
6. If the corner spacing is too tight for CreateFilletCornersCurve to succeed (returns None), that's the signal the point list still has micro-segments — go back to step 1 and simplify the path further, don't lower the radius to force it to fit.

Gotcha carried over from the cover-fix work: when re-deriving centerline points from an already-built (possibly mirrored) Brep, don't assume a vertex read via .Vertices is on any particular side (top/bottom) of the pipe — use the bounding-box center of the relevant flat/straight piece ((bbox.Min.Z + bbox.Max.Z) / 2.0) to get the true centerline Z robustly regardless of which side the vertex happens to sit on for a given (possibly mirror-reflected) bar; this was mixed up once (added the bar radius in the wrong direction for the mirrored C10) and caught only by comparing C8/C10's post-fix bounding boxes and finding them asymmetric when they should have matched.