docs: finalized wiki integrity maintenance (v3.0 standard) - pruned 1400+ stubs and fixed 11k+ ghost links

10_Wiki/Topics/Programming & Language/Overdraw.md

@@ -1,5 +1,5 @@
 ---
-id: [[P-Reinforce]]-AUTO-421E43
+id: [[P-Reinforce|P-Reinforce]]-AUTO-421E43
 category: "10_Wiki/💡 Topics/Programming & Language"
 confidence_score: 0.90
 tags: [auto-reinforced]
@@ -7,10 +7,10 @@ last_reinforced: 2026-04-20
 github_commit: "[P-Reinforce] Continuous Worker - Overdraw"
 ---
 
-# [[Overdraw]]
+# [[Overdraw|Overdraw]]
 
 ## 📌 한 줄 통찰 (The Karpathy Summary)
-> 오버드로우(Overdraw)는 렌더링 파이프라인의 프래그먼트 셰이딩([[Fragment Shading]]) 단계에서 동일한 픽셀 위치에 렌더링 연산 및 쓰기 작업이 여러 번 중첩되어 GPU 자원이 낭비되는 현상입니다. [[InstancedMesh]]를 사용할 때 개별 인스턴스에 대한 자동 정렬([[Sorting]]) 기능이 부재하여 깊이 테스트([[Early-Z]])를 통한 최적화가 무력화되면서 막대한 오버드로우가 발생할 수 있으며, 이는 심각한 렌더링 프레임 지연의 핵심 원인이 됩니다[1, 2].
+> 오버드로우(Overdraw)는 렌더링 파이프라인의 프래그먼트 셰이딩([[Fragment Shading|Fragment Shading]]) 단계에서 동일한 픽셀 위치에 렌더링 연산 및 쓰기 작업이 여러 번 중첩되어 GPU 자원이 낭비되는 현상입니다. InstancedMesh를 사용할 때 개별 인스턴스에 대한 자동 정렬(Sorting) 기능이 부재하여 깊이 테스트([[Early-Z|Early-Z]])를 통한 최적화가 무력화되면서 막대한 오버드로우가 발생할 수 있으며, 이는 심각한 렌더링 프레임 지연의 핵심 원인이 됩니다[1, 2].
 
 ## 📖 구조화된 지식 (Synthesized Content)
 *   **오버드로우의 발생 원리:** 
@@ -20,14 +20,14 @@ github_commit: "[P-Reinforce] Continuous Worker - Overdraw"
 *   **드로우 콜 최적화의 역설 (성능 저하 사례):** 
     실제 벤치마크 사례 연구에 따르면, 5,000개의 구체를 렌더링할 때 드로우 콜이 1회인 InstancedMesh 방식의 FPS가 드로우 콜이 5,000회인 일반 개별 메쉬 방식보다 오히려 더 낮게 측정되는 현상이 보고되었습니다. 이는 드로우 콜 감소를 통해 얻은 CPU 연산 이득보다, 정렬되지 않은 인스턴스들이 유발한 막대한 오버드로우 비용이 GPU의 픽셀 처리 성능 한계를 상회했기 때문입니다[2].
 *   **병목을 가중시키는 요인:** 
-    오버드로우로 인한 렌더링 병목 현상은 복잡한 조명 연산이 포함된 `MeshStandardMaterial`과 같은 재질을 사용할 때 씬(Scene)을 프래그먼트 바운드([[Fragment-bound]]) 상태로 빠뜨리며 더욱 심화됩니다[2, 3]. 또한 나뭇잎(Foliage)처럼 투명도(Transparency)를 지닌 지오메트리의 경우, 조기 깊이 테스트가 비활성화되고 동일한 픽셀을 5~10번씩 반복하여 렌더링해야 하므로 픽셀 채우기 비율([[Fill Rate]])이 급감하는 치명적인 원인이 됩니다[1, 4].
+    오버드로우로 인한 렌더링 병목 현상은 복잡한 조명 연산이 포함된 `MeshStandardMaterial`과 같은 재질을 사용할 때 씬(Scene)을 프래그먼트 바운드([[Fragment-bound|Fragment-bound]]) 상태로 빠뜨리며 더욱 심화됩니다[2, 3]. 또한 나뭇잎(Foliage)처럼 투명도(Transparency)를 지닌 지오메트리의 경우, 조기 깊이 테스트가 비활성화되고 동일한 픽셀을 5~10번씩 반복하여 렌더링해야 하므로 픽셀 채우기 비율([[Fill Rate|Fill Rate]])이 급감하는 치명적인 원인이 됩니다[1, 4].
 
 ## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
 - **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
 - **정책 변화:** Programming & Language 분야의 자동 자산화 수행.
 
 ## 🔗 지식 연결 (Graph)
-- **Related Topics:** [[InstancedMesh]], [[Fragment Shading]], [[Early-Z]], [[프래그먼트 바운드(Fragment-bound)]], [[Draw Call]], [[Sorting]]
+- **Related Topics:** [[InstancedMesh|InstancedMesh]], Fragment Shading, Early-Z, [[프래그먼트 바운드(Fragment-bound)|프래그먼트 바운드(Fragment-bound]], Draw Call, [[Sorting|Sorting]]
 - **Projects/Contexts:** three.js Issue, 대규모 인스턴스 렌더링 및 투명도 처리
 - **Contradictions/Notes:** CPU 부하를 유발하는 드로우 콜을 줄이기 위해 InstancedMesh를 도입하더라도, 내부 인스턴스들의 정렬 부재가 유발하는 오버드로우 비용이 더 크다면 오히려 드로우 콜이 많은 개별 메쉬 렌더링 방식보다 FPS가 떨어질 수 있다는 역설적인 결과를 보여줍니다[2, 5].