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

01_Archive/2026-04-20/Three.js 대규모 렌더링 최적화 파이프라인.md

@@ -1,4 +1,4 @@
-# [[Three.js 대규모 렌더링 최적화 파이프라인]]
+# [[Three.js 대규모 렌더링 최적화 파이프라인|Three.js 대규모 렌더링 최적화 파이프라인]]
 
 ## 📌 Brief Summary
 Three.js 대규모 렌더링 최적화 파이프라인은 수많은 3D 객체를 브라우저 환경에서 매끄럽게 렌더링하기 위해 CPU와 GPU 간의 통신 오버헤드, 즉 드로우 콜(Draw Call)과 메모리 병목 현상을 극복하는 일련의 기술적 아키텍처입니다 [1, 2]. 주로 InstancedMesh와 BatchedMesh를 통한 드로우 콜 최소화, Draco 및 KTX2 등을 이용한 에셋 압축, 절두체 컬링(Frustum Culling) 및 LOD 시스템을 활용하여 그래픽 자원의 낭비를 줄입니다 [3-6]. 최근에는 WebGPU와 컴퓨트 셰이더(Compute Shader)가 도입되어 렌더링 제어 및 가시성 판단 연산을 GPU로 대거 이관함으로써, 더욱 막대한 규모의 씬을 유연하게 처리할 수 있는 차세대 파이프라인으로 진화하고 있습니다 [7-9].
@@ -10,8 +10,8 @@ Three.js 대규모 렌더링 최적화 파이프라인은 수많은 3D 객체를
 - **WebGPU 기반 차세대 렌더링 파이프라인:** 2026년 기준, Three.js(r171 이상)의 `WebGPURenderer` 및 TSL(Three Shader Language) 도입으로 대규모 렌더링 구조가 혁신적으로 변화했습니다 [7, 30]. 일반적인 CPU 한계를 초과하던 100만 개 이상의 파티클 연산, 물리 시뮬레이션, 복잡한 군중 애니메이션 등을 컴퓨트 셰이더(Compute Shader)를 통한 GPU-driven Rendering으로 병렬 처리할 수 있게 되었습니다 [31-34]. Native WebGPU 수준에서는 `GPURenderBundles` 및 Indirect Drawing 기술을 통해 500MB 이상의 초대형 건설/BIM 데이터셋에서도 강력한 성능 향상을 이끌어냅니다 [35, 36].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** `[[InstancedMesh]]`, `[[BatchedMesh]]`, `[[WebGPU]]`, `[[Draw Call (드로우 콜)]]`, `[[Frustum Culling (절두체 컬링)]]`, `[[LOD (Level of Detail)]]`, `[[Overdraw (오버드로우)]]`, `[[Compute Shader (컴퓨트 셰이더)]]`
-- **Projects/Contexts:** `[[InstancedMesh2 (agargaro)]]`, `[[Three.js r171 WebGPURenderer]]`, `[[Segments.ai]]`, `[[Fragment (IFC.js)]]`
+- **Related Topics:** `[[InstancedMesh|InstancedMesh]]`, `[[BatchedMesh|BatchedMesh]]`, `[[WebGPU|WebGPU]]`, `Draw Call (드로우 콜)`, `Frustum Culling (절두체 컬링)`, `[[가변적 LOD(Level of Detail) 시스템|LOD (Level of Detail)]]`, `Overdraw (오버드로우)`, `Compute Shader (컴퓨트 셰이더)`
+- **Projects/Contexts:** `InstancedMesh2 (agargaro)`, `Three.js r171 WebGPURenderer`, `[[Segments.ai|Segments.ai]]`, `Fragment (IFC.js)`
 - **Contradictions/Notes:** 
   - `InstancedMesh`는 드로우 콜을 줄여 성능을 크게 향상시키도록 설계되었으나, 불투명도 및 복잡한 셰이더 환경에서는 인스턴스 정렬 부재로 인한 심각한 오버드로우(Overdraw)를 유발해 일반 개별 Mesh(Shared attributes)를 사용할 때보다 프레임 레이트(FPS)가 오히려 낮아지는 역설적인 사례가 보고되고 있습니다 [18, 19].
   - `BatchedMesh` 역시 다수의 기하학적 구조를 통합하는 유용한 기술이지만, 약 20만 개 수준의 대량 지오메트리에 적용할 시 버퍼 데이터 업로드 등의 이유로 CPU 사용량이 30~50% 급증하며 병합된 기하학(Merged Geometry)보다 현저히 성능이 하락하는 구조적 병목이 제기되고 있습니다 [37-39].