---
id: P-REINFORCE-AUTO-6B3697
category: "10_Wiki/💡 Topics/Graphics & Performance"
confidence_score: 0.90
tags: [auto-reinforced]
last_reinforced: 2026-04-20
github_commit: "[P-Reinforce] Continuous Worker - BatchedMesh 및 InstancedMesh 성능 벤치마크"
---

# [[BatchedMesh 및 InstancedMesh 성능 벤치마크|BatchedMesh 및 InstancedMesh 성능 벤치마크]]

## 📌 한 줄 통찰 (The Karpathy Summary)
> BatchedMesh와 InstancedMesh는 Three.js 환경에서 드로우 콜(Draw Call)을 줄여 렌더링 성능을 대폭 개선하는 대표적인 최적화 기법입니다 [1, 2]. InstancedMesh는 동일한 형태의 객체를 대량으로 그릴 때 탁월한 효율을 보이지만 다양한 지오메트리를 한 번에 처리할 수는 없으며, BatchedMesh는 서로 다른 지오메트리를 하나의 드로우 콜로 묶을 수 있는 높은 유연성을 제공합니다 [3, 4]. 하지만 벤치마크 사례 연구에 따르면, 대규모 객체를 처리할 때 BatchedMesh는 내부적인 객체 정렬 및 버퍼 업로드 오버헤드로 인해 오히려 심각한 CPU 병목 현상과 렌더링 성능 저하를 유발할 수 있음이 확인되었습니다 [5, 6].

## 📖 구조화된 지식 (Synthesized Content)
- **최적화 메커니즘과 적용 기준**
  InstancedMesh는 동일한 기하학적 구조(BufferGeometry)와 재질(Material)을 공유하는 수많은 복제본을 단일 드로우 콜로 GPU에 전달해 처리합니다 [7, 8]. 고유한 지오메트리가 1,000개 미만이면서 수만 개의 복제본이 존재하는 환경에서 최상의 성능(`drawElementsInstanced`)을 발휘합니다 [9, 10]. 반면 BatchedMesh는 재질은 같으나 형태가 각기 다른 여러 지오메트리를 하나의 버퍼에 통합(`multiDrawElementsWEBGL` 활용)하여 한 번에 렌더링할 수 있으므로 지오메트리가 매우 다양한 씬에 적합합니다 [9, 11-13].

- **BatchedMesh의 대규모 씬 성능 병목 현상**
  실제 건축 BIM 모델이나 대규모 씬(예: 1,200만 개의 삼각형, 수십만 개의 고유 지오메트리)을 BatchedMesh로 렌더링한 벤치마크 테스트에서 막대한 성능 하락이 보고되었습니다 [5, 14, 15]. 동일한 환경에서 모든 객체를 하나로 병합한 Merged Mesh 방식이 60 FPS(CPU 15%, GPU 90%)의 성능을 보인 반면, BatchedMesh는 약 20 FPS 이하(CPU 40~60%, GPU 30%)로 프레임이 급락하며 극심한 CPU 부하를 보였습니다 [5, 15-17]. 

- **성능 저하의 주요 원인**
  BatchedMesh의 CPU 오버헤드는 매 프레임마다 GPU로 그려야 할 부분의 '시작(starts)' 지점과 '카운트(counts)' 배열 데이터를 재업로드해야 하는 구조에서 비롯될 확률이 높습니다(약 20만 개 항목 기준 1.6MB의 데이터를 매 프레임 전송) [6, 18, 19]. 더불어 개별 객체마다 가시성을 판별하는 시야 절두체 컬링(Frustum Culling) 및 심도 정렬(Sorting) 작업이 CPU 자원을 크게 소모하며, 특히 정렬 기능을 켤 경우 `texSubImage2D` 작업 병목으로 인해 FPS가 30에서 9로 떨어지는 현상까지 관찰되었습니다 [20-22].

- **오버드로우(Overdraw)와 심도 정렬의 한계**
  InstancedMesh는 내부적으로 인스턴스를 자동으로 정렬하지 않기 때문에, 불투명 객체들이 겹칠 때 발생하는 오버드로우 현상으로 인해 프래그먼트 바운드(Fragment-bound) 성능 저하를 겪을 수 있습니다 [23-25]. BatchedMesh는 이러한 문제를 덜기 위해 자체적인 정렬 기능을 제공하지만, 앞서 언급한 바와 같이 수많은 요소를 CPU에서 정렬하는 연산 자체가 새로운 렌더링 지연의 원인이 됩니다 [22, 24].

- **성능 벤치마크 기반의 선택 가이드라인**
  동적인 씬에서 객체의 종류가 1,000개 이하라면 InstancedMesh가 압도적으로 효율적입니다 [10, 26]. 만일 고유 객체가 1,000개 이상이라면 BatchedMesh를 고려할 수 있으나, 수만~수십만 개의 극대규모 객체 단위로 넘어가면 한계에 부딪힙니다 [10, 27]. 씬이 정적이라면 지오메트리를 하나의 거대한 버퍼로 완전히 병합(Merge)해버리는 것이 성능에 훨씬 이로우며, 매우 방대하고 동적인 처리가 필수적이라면 WebGPU 기반의 컴퓨트 셰이더와 간접 드로우(Indirect Draw) 파이프라인으로 전환하는 것이 근본적인 해결책입니다 [6, 28, 29].

## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
- **정책 변화:** Graphics & Performance 분야의 자동 자산화 수행.

## 🔗 지식 연결 (Graph)
- **Related Topics:** 드로우 콜 (Draw Call), Frustum Culling (시야 절두체 컬링), [[오버드로우(Overdraw)|오버드로우 (Overdraw)]]
- **Projects/Contexts:** Revit 및 BIM 건축 모델 렌더링 최적화, WebGPU 및 Indirect Draw
- **Contradictions/Notes:** BatchedMesh는 여러 종류의 지오메트리 렌더링 시 발생하는 CPU의 드로우 콜 오버헤드를 줄이고 성능을 최적화하기 위해 고안되었으나, 대규모(10만 개 이상) 지오메트리 벤치마크 환경에서는 내부 상태 업데이트 및 버퍼 데이터 전송 부하로 인해 도리어 Merged Mesh 방식보다 CPU 사용량을 최대 3배 이상 폭증시키고 FPS를 심각하게 떨어뜨리는 역설적인 결과를 보입니다 [5, 15, 30].

---
*Last updated: 2026-04-19*
- Raw Source: 00_Raw/2026-04-20/BatchedMesh 및 InstancedMesh 성능 벤치마크.md
---