# [[threejs Issue _30352|three.js Issue]]

## 📌 Brief Summary
three.js Issue #30352는 공유 속성을 가진 여러 개의 일반 `Mesh` 객체를 렌더링할 때보다 `InstancedMesh`를 사용할 때 성능이 오히려 크게 저하되는 현상을 보고한 이슈입니다 [1, 2]. 이 현상의 주요 원인은 `InstancedMesh`가 내부 인스턴스들을 렌더링할 때 앞뒤로 자동 정렬(Sorting)하지 않아 발생하는 막대한 오버드로우(Overdraw) 비용 때문입니다 [3, 4]. 즉, 단일 드로우 콜로 인한 CPU 연산 감소 이득보다 불필요한 픽셀 처리 부하가 더 커지면서 씬이 프래그먼트 바운드(Fragment-bound) 상태에 빠지는 구조적 한계를 보여주는 사례입니다 [5].

## 📖 Core 대 Content
* **이슈 발생 배경 및 증상:** 
  작성자(MHebes)는 2025년 1월 17일에 생성한 이슈에서, 50분할된 구체 5,000개를 렌더링하는 테스트를 진행했습니다 [1, 2]. 일반적으로 단일 드로우 콜을 사용하는 `InstancedMesh`가 훨씬 빠를 것으로 예상되지만, 실제로는 기하학적 구조와 재질을 공유하는 다수의 개별 `Mesh`를 렌더링할 때보다 `InstancedMesh`의 프레임 레이트(FPS)가 눈에 띄게 느리다는 것을 발견했습니다 [1, 2, 5].

* **원인 분석 (오버드로우와 정렬의 부재):** 
  three.js 기여자들(donmccurdy, gkjohnson)과 렌더링 파이프라인 사례 연구에 따르면, 성능 저하의 핵심 원인은 오버드로우(Overdraw)입니다 [3-5]. 불투명한 물체는 일반적으로 '앞에서 뒤로' 정렬하여 뒤에 가려진 픽셀 연산을 조기 종료(Early-Z)해야 하지만, `InstancedMesh`는 인스턴스의 자동 정렬 기능을 제공하지 않습니다 [5]. 정렬되지 않은 인스턴스들이 버퍼 순서대로 렌더링되면서 동일한 픽셀 위치에 렌더링 쓰기 작업이 여러 번 중첩되었고, 이로 인한 픽셀 처리 비용이 드로우 콜 감소로 얻은 CPU 이득을 상회해 버렸습니다 [4, 5].

* **셰이더 및 재질의 영향:** 
  이러한 오버드로우 문제는 복잡한 조명 연산이 포함된 `MeshStandardMaterial`을 사용할 때 프래그먼트 바운드(Fragment-bound) 상태를 유발하여 더욱 심화됩니다 [3, 5]. 따라서 문제의 원인을 명확히 파악하기 위해 오버드로우 비용이 적은 `MeshBasicMaterial`로 재질을 변경하여 비교해 볼 것이 제안되기도 했습니다 [3].

* **제안된 대안 및 이슈 종결:**
  기여자들은 정렬 기능이 없는 `InstancedMesh` 대신, 인스턴스의 정렬(Sorting)을 지원하는 `BatchedMesh`를 사용해 볼 것을 대안으로 권장했습니다 [4]. 해당 이슈는 특정 기기의 버그가 아니라 정렬 부재와 오버드로우로 인한 정상적인 하드웨어 한계 지점임이 확인되어 2025년 1월 23일에 종결(Closed)되었습니다 [4, 6].

## 🔗 Knowledge Connections
- **Related Topics:** [[InstancedMesh|InstancedMesh]], [[Overdraw|Overdraw]], [[BatchedMesh|BatchedMesh]], [[Fragment-bound|Fragment-bound]]
- **Projects/Contexts:** [[Threejs 성능 최적화|three.js]]
- **Contradictions/Notes:** 이론적으로 `InstancedMesh`는 드로우 콜 횟수를 1회로 줄여주어 렌더링 성능을 향상시켜야 하지만, 이슈 #30352의 사례에서는 개별 정렬 부재로 인한 오버드로우 비용 때문에 오히려 개별 드로우 콜(5,000회)을 수행하는 일반 `Mesh` 방식보다 성능이 떨어지는 모순적인 결과를 보여줍니다 [1, 2, 5]. 

---
*Last updated: 2026-04-19*