bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
303b01b228c7e3730aeb1c4da9457377e536f933
2nd/10_Wiki/Topics/InstancedMesh.md
T

24 KiB
Raw Blame History

category, tags, title, last_updated
category tags title last_updated
Unified
auto-consolidated
technical-documentation
InstancedMesh (드로우 콜 최적화)|InstancedMesh (드로우 콜 최적화
2026-05-02

InstancedMesh (드로우 콜 최적화)

📌 Brief Summary

InstancedMesh는 동일한 기하구조(Geometry)와 재질(Material)을 공유하는 수많은 객체를 단 1회의 드로우 콜(Draw Call)만으로 GPU에서 렌더링하여, CPU의 오버헤드를 극적으로 줄이고 애플리케이션의 프레임 레이트(FPS)를 비약적으로 향상시키는 3D 그래픽스 핵심 최적화 기법입니다.

InstancedMesh 동적 버퍼 확장은 렌더링 중 인스턴스 수가 초기 할당된 용량(Capacity)을 초과할 때, 시스템이 새로운 더 큰 버퍼를 할당하고 기존 데이터를 복사하는 과정을 의미한다 [1]. 이 과정에서 수십 메가바이트 크기의 배열이 빈번하게 생성되고 파괴되어 가비지 컬렉션(GC)을 유발하며, 이는 프레임 지연(스터터링)이나 메모리 할당 오류로 이어진다 [1, 2]. 결과적으로 이러한 성능 병목을 피하기 위해 개발자들은 런타임 확장을 피하고, 최대 예상 인스턴스 수에 맞춘 버퍼 사전 할당이나 객체 풀링 전략을 권장하고 있다 [1, 3].

InstancedMesh는 단일 드로우 콜(Draw Call)로 동일한 기하학적 구조와 재질을 가진 수많은 객체를 렌더링하여 CPU 오버헤드를 획기적으로 줄이는 최적화 기술입니다 [1, 2]. 그러나 실무 환경에서는 지오메트리 단일성 제약, 시야 절두체 컬링(Frustum Culling)의 비효율성, 오버드로우(Overdraw), 동적 데이터 갱신 시의 메모리 대역폭 포화 등 여러 구조적 한계를 드러냅니다 [3-7]. 본 사례 연구는 이러한 한계들로 인해 드로우 콜 횟수의 감소가 반드시 전반적인 렌더링 프레임 레이트(FPS) 상승으로 이어지지는 않음을 실증적으로 분석합니다 [3].

InstancedMesh 최적화는 동일한 기하학적 구조(Geometry)와 재질(Material)을 가진 수많은 객체를 단 한 번의 드로우 콜(Draw Call)로 GPU에 전달하여 렌더링 성능을 극대화하는 기법입니다 [1], [2]. 수천, 수만 개의 반복적인 객체(나무, 풀, 파티클 등)를 렌더링할 때 CPU의 명령 발행 오버헤드를 대폭 줄이고 메모리 사용량을 최소화할 수 있습니다 [3], [4], [5]. 그러나 전체 인스턴스에 대한 전역적 시야 절두체 컬링, 개별 객체의 깊이 정렬 부재로 인한 오버드로우 등 구조적 한계가 존재하므로, 프로젝트의 특성과 병목 구간에 맞춘 전략적인 도입이 필요합니다 [6], [7].

InstancedMesh는 동일한 기하학적 구조(Geometry)와 재질(Material)을 공유하는 수많은 객체를 단 한 번의 드로우 콜(Draw Call)로 렌더링할 수 있게 해주는 특수 메쉬이다 [1, 2]. 각 인스턴스는 고유한 변환 행렬(위치, 회전, 축척)과 색상을 가질 수 있으며, 이를 통해 CPU 오버헤드를 획기적으로 줄이고 렌더링 성능을 향상시킨다 [2-4]. 나무, 풀, 바위와 같이 형태가 동일한 대규모 객체 군집을 렌더링할 때 주로 사용되며, 메모리 소비도 최소화할 수 있는 강력한 최적화 도구이다 [5-7].

📖 Core Content

1. 드로우 콜(Draw Call)의 개념과 성능 병목 모든 3D 장면에서 메시는 각각의 드로우 콜을 발생시키며, 이 횟수가 많아질수록 CPU가 GPU에 렌더링 명령을 내리는 오버헤드가 급증합니다. 매끄러운 60FPS를 유지하기 위한 렌더링의 골든 룰은 프레임당 드로우 콜을 100회 미만으로 유지하는 것이며, 폴리곤(삼각형)의 수보다 드로우 콜의 횟수가 성능에 훨씬 치명적인 영향을 미칩니다.

2. InstancedMesh의 작동 원리 1,000개의 나무나 총알을 개별적인 메시(Mesh)로 렌더링하면 1,000번의 드로우 콜이 발생합니다. 하지만 InstancedMesh를 사용하면 단 1번의 드로우 콜만으로 GPU 내부에서 해당 객체를 1,000번 복제하여 렌더링할 수 있습니다. 한 부동산 데모 프로젝트의 경우, 수많은 의자 객체들을 인스턴싱 렌더링으로 변경하여 드로우 콜을 9,000회에서 300회로 줄인 사례가 있습니다.

3. 성능 이득과 활용 방식 인스턴싱 최적화를 적용하면 드로우 콜 횟수가 $N$(객체 수)에서 1로 줄어들어, 내장형 GPU 환경에서 대규모 데이터셋 렌더링 시 프레임 레이트를 10배 이상 향상시킬 수 있습니다. 또한, 각 인스턴스는 동일한 형태를 공유하더라도 인스턴스별 속성(per-instance attributes)을 통해 서로 다른 위치, 회전, 크기(Scale) 및 색상을 독립적으로 가질 수 있습니다.

4. 오브젝트 풀링과의 결합 실시간 게임 아키텍처에서는 총알이나 파티클과 같이 자주 생성되고 사라지는 객체를 개별 메시로 관리하지 않고, 하나의 InstancedMesh를 고정된 오브젝트 풀(Pool)로 관리하며 변환 행렬(Matrix)만 업데이트하는 방식을 사용해 메모리 파편화 방지와 렌더링 최적화를 동시에 달성합니다.

  • 동적 버퍼 확장의 발생 원리 InstancedMesh는 객체 수가 동적으로 변하는 환경(예: 적들이 수시로 생성되거나 파괴되는 상황)에서 초기 용량을 넘어서면 새로운 버퍼를 동적으로 확장해야 한다 [1]. 이때 기존 데이터를 새롭고 더 큰 버퍼로 복사하는 작업이 필연적으로 수반된다 [1].

  • 성능 저하 및 메모리 문제 동적 버퍼 확장은 메모리 할당 빈도가 매우 잦아 CPU 부하를 극도로 높이며, 데이터 전송 효율을 떨어뜨린다 [1]. 구형 [[TypedArray|TypedArray]] 데이터가 메모리에서 빈번하게 해제되는 과정에서 자바스크립트 가비지 컬렉터(GC)가 작동하여 프레임이 일시적으로 멈추는 현상(Stuttering)이 발생한다 [1]. A-Frame 기반 구현 등 일부 환경에서는 용량 증가 시 이전 InstancedMesh를 깔끔하게 해제(dispose)하지 못해 작은 메모리 누수(memory Leak)가 발생할 우려도 존재한다 [4]. Needle Engine 환경에서도 버퍼가 동적으로 확장될 때 "Instancing] Growing Buffer"라는 로그와 함께 렌더링이 일시적으로 수 초간 멈추는 성능 병목이 관찰되었다 [2].

  • 최적화 및 대안 전략 이러한 성능 하락을 방지하려면 런타임에 동적으로 버퍼를 확장하는 대신, 앱 시작 시점이나 로드 시 최대 예상 인스턴스 수에 맞춰 충분한 크기의 버퍼를 미리 할당(Preallocate)하는 방식이 권장된다 [3, 5]. 또한, 대규모 프로젝트에서는 예측 불가능한 버퍼 확장을 막기 위해 사전에 엄격한 메모리 예산을 수립해야 한다 [1]. 메모리 할당 및 해제의 오버헤드를 최소화하기 위해 한 번 생성된 인스턴스 데이터를 재사용하는 객체 풀링(Object Pooling)이나 링 버퍼(Ring Buffer) 구조를 채택하는 것이 효율적이다 [1].

  • 드로우 콜 최적화 원리와 맹점 InstancedMesh는 GPU 메모리에 단일 정점 버퍼를 업로드하고 개별 인스턴스의 변환 행렬만을 속성으로 관리하여 한 번의 명령으로 수천 개의 객체를 병렬 복제합니다 [1, 2]. 하지만 모든 인스턴스가 반드시 동일한 기하학적 데이터(BufferGeometry)와 재질(Material)을 공유해야 하므로 자산의 다양성을 확보하기 어렵습니다 [4]. 개별 인스턴스에 다른 텍스처를 적용하기 위해 텍스처 아틀라스(Texture Atlas)를 사용하면 경계선 블리딩(Edge Bleeding)이 발생할 수 있으며, 텍스처 배열(Texture Array)은 해상도 제약을 수반해 셰이더 복잡도를 높입니다 [8].

  • 시야 절두체 컬링(Frustum Culling)의 비효율성 InstancedMesh의 컬링은 전체 인스턴스를 포함하는 거대한 바운딩 볼륨을 기준으로 단 한 번만 수행되는 '전부 아니면 전무' 방식으로 작동합니다 [5]. 이로 인해 단 하나의 객체만 시야에 있어도 화면 밖의 수많은 객체에 대한 정점 변환 연산이 강제되어 GPU를 크게 낭비합니다 [5]. 이를 피하고자 자바스크립트 수준에서 CPU 기반의 수동 개별 컬링을 구현하면 대규모 배열 조작으로 인해 메인 스레드에 극심한 병목이 유발됩니다 [9].

  • 오버드로우(Overdraw)와 렌더링 정렬의 부재 InstancedMesh는 버퍼에 저장된 순서대로만 렌더링되며, 불투명 객체의 조기 깊이 판정(Early-Z)을 위한 '앞에서 뒤로' 자동 정렬 기능이 없습니다 [6]. 드로우 콜이 1회로 최적화되었음에도 불구하고, 무작위 정렬로 인한 막대한 오버드로우 비용 때문에 GPU 프래그먼트 병목이 발생하여 오히려 일반 메쉬 방식보다 FPS가 떨어질 수 있습니다 [6]. 투명/반투명 객체는 '뒤에서 앞으로' 렌더링되어야 시각적 오류가 없으나 동적인 순서 변경이 지원되지 않으며, 강제로 재정렬(Radix Sort 등)을 수행하면 CPU에 치명적인 부하를 줍니다 [10].

  • 메모리 대역폭 임계점과 데이터 전송 병목 각 인스턴스의 위치 및 회전 정보는 64바이트의 부동 소수점 행렬로 구성됩니다 [7]. 대규모 씬(예: 200만 개 인스턴스)에서 매 프레임 객체들이 동적으로 움직여 버퍼를 갱신해야 할 경우, 수 GB/s 단위의 막대한 데이터가 CPU에서 GPU로 이동해야 하므로 PCIe 대역폭을 포화시킵니다 [7]. 또한 할당된 버퍼 용량을 초과해 새 버퍼를 동적 할당할 때는 가비지 컬렉션(GC)이 작동해 순간적인 프레임 스터터링(Stuttering)을 유발합니다 [11].

  • 상호작용(Picking) 및 애니메이션 연동의 한계 대규모 인스턴스에 대해 사용자가 객체를 선택하는 CPU 기반 피킹(Raycasting)을 시도하면 수만 번의 행렬 역산이 발생하여 즉각적인 반응성이 저해됩니다 [12]. GPU 픽셀 기반 피킹은 파이프라인 동기화 지연(Sync stall)과 오클루전(Occlusion) 한계가 있습니다 [13]. 또한 본(Bone) 행렬 기반의 스킨드 메쉬(Skinned Mesh) 애니메이션을 기본 지원하지 않아, 인스턴스마다 고유한 본 행렬을 전달하려 하면 버퍼 크기 제한을 초과하게 됩니다 [14].

  • 대안 기술 및 최적화 전략 InstancedMesh의 한계를 보완하기 위해 서로 다른 기하학적 구조를 수용하고 개별 컬링/가시성 제어가 가능한 **BatchedMesh**가 활용되고 있으나, 이 역시 지나치게 많은 삼각형을 처리할 때는 버퍼 패킹 오버헤드가 발생합니다 [15]. 궁극적으로는 WebGPU의 컴퓨트 셰이더(Compute Shader)를 도입하여 가시성 판별과 오클루전 처리를 GPU 내부에서 해결하는 GPU 주도 렌더링(Indirect Draw) 방식이 강력한 대안으로 부상하고 있습니다 [16, 17].

  • 드로우 콜 및 메모리 최적화 원리

    • InstancedMesh는 GPU 메모리에 단 하나의 정점 버퍼만 업로드하고, 각 인스턴스에 고유하게 적용될 변환 행렬(위치, 회전, 축척) 및 색상 정보를 별도의 인스턴스 속성(Instance Attribute)으로 관리합니다 [2].
    • 이 기술을 사용하면 일반 메쉬로 수천 번 호출해야 할 드로우 콜을 1회로 줄일 수 있어, CPU 병목 현상을 해소하고 시스템 메모리 및 VRAM을 획기적으로 절약할 수 있습니다 [8], [1], [9].
    • 개별 인스턴스의 변환 행렬이나 색상을 변경(setMatrixAt, setColorAt)한 후에는 반드시 needsUpdate 속성을 true로 설정해야 렌더링 파이프라인에 반영됩니다 [10], [11]. 동적으로 인스턴스가 이동한 경우, 정확한 레이캐스팅(Picking) 및 컬링을 위해 computeBoundingSphere()와 computeBoundingBox()를 호출하여 바운딩 볼륨을 갱신해야 합니다 [12], [13], [14].

  • 구조적 한계 및 성능 병목 요인

    • 컬링(Culling)의 비효율성: InstancedMesh는 엔진 수준에서 단일 객체로 취급되므로, 개별 인스턴스 단위가 아닌 전체를 아우르는 거대한 바운딩 볼륨을 기준으로 단 한 번의 시야 절두체 컬링(Frustum Culling)을 수행합니다 [15]. 이로 인해 시야 밖의 수많은 객체에 대해서도 불필요한 GPU 정점 연산이 강제될 수 있습니다 [15], [16].
    • 정렬 부재와 오버드로우(Overdraw): 카메라 거리에 따른 자동 정렬 기능을 제공하지 않기 때문에, 뒤에 가려진 픽셀 연산을 조기에 종료(Early-Z)하지 못해 오버드로우가 발생합니다 [17], [18]. 특히 투명/반투명 객체 렌더링 시에는 깊이 정렬이 뒤섞여 시각적 오류를 초래합니다 [19].
    • 메모리 대역폭 한계: 애니메이션 등으로 매 프레임 수백만 개의 인스턴스 변환 행렬(인스턴스당 64바이트)을 갱신해야 할 경우, 데이터 전송량이 시스템 버스 대역폭을 포화시켜 프레임 지연(Stuttering)을 유발할 수 있습니다 [20], [21].
    • 다양성 표현의 제약: 단일 지오메트리와 단일 재질만 참조할 수 있어 다양한 에셋을 표현하기 어렵습니다 [22]. 개별 인스턴스에 서로 다른 텍스처를 적용하려면 Texture Atlas나 데이터 배열 텍스처(Data Array Textures)를 활용하고 UV 오프셋을 조정하는 추가적인 셰이더 조작이 강제됩니다 [23], [24], [25].

  • 한계 극복을 위한 개선 및 대안 전략

    • 공간 분할 기반 그룹화: 모든 객체를 하나의 거대한 InstancedMesh로 묶기보다는, 공간적으로 인접한 객체끼리 소규모(100~500개)로 분할하여 관리하면 절두체 컬링의 정밀도를 높여 GPU 연산 낭비를 줄일 수 있습니다 [7].
    • InstancedMesh2 및 BatchedMesh 활용: 단일 지오메트리 제약이 문제가 된다면, 서로 다른 지오메트리를 하나의 드로우 콜로 묶어주는 BatchedMesh 사용이 권장됩니다 [26], [27]. 또한, 커뮤니티 생태계의 InstancedMesh2 라이브러리를 활용하면 개별 인스턴스의 프러스텀 컬링, 정렬, Level of Detail (LOD), BVH 기반의 빠른 레이캐스팅, 스킨드 애니메이션 최적화 등의 기능을 확장 적용할 수 있습니다 [28], [29], [30].
    • WebGPU 컴퓨트 셰이더 도입: WebGPU 환경에서는 GPU가 직접 가시성 판단과 컬링을 처리하여 CPU와 GPU 간의 통신 비용을 "0"에 수렴하게 하는 간접 그리기(Indirect Draw) 방식이 차세대 대안으로 떠오르고 있습니다 [31].
  • 작동 원리 및 성능 이점: InstancedMesh는 GPU 메모리에 단 하나의 정점 버퍼(Vertex Buffer)를 업로드하고, 각 인스턴스마다 적용될 변환 행렬(Transformation Matrix)을 instanceMatrix 속성으로 전달하여 렌더링을 수행한다 [3, 8]. 이 방식을 사용하면 수많은 객체를 개별적으로 그릴 때 발생하는 엄청난 횟수의 드로우 콜을 단 1회로 묶을 수 있어, CPU 병목 현상과 CPU-GPU 간 통신 오버헤드를 크게 해소한다 [1, 5, 9]. 기하학적 데이터를 복제하지 않고 공유하므로 메모리 효율성 역시 매우 뛰어나다 [6, 9].
  • 구조적 한계 및 병목 현상:
    • 지오메트리 및 재질의 단일성 제약: 모든 인스턴스가 반드시 동일한 BufferGeometry와 Material을 공유해야 한다 [10, 11]. 여러 종류의 지오메트리를 렌더링해야 한다면 다수의 InstancedMesh를 생성하거나, 서로 다른 지오메트리를 묶을 수 있는 BatchedMesh를 사용해야 한다 [11-13].
    • 시야 절두체 컬링(Frustum Culling) 비효율성: 기본적으로 엔진 수준에서 InstancedMesh 전체를 하나의 거대한 단일 객체(바운딩 볼륨)로 취급하기 때문에, 인스턴스 개별 단위의 시야 절두체 컬링이 작동하지 않는다 [14, 15]. 따라서 단 하나의 인스턴스만 시야에 있어도 화면 밖의 모든 인스턴스에 대한 정점 연산을 GPU가 강제로 수행해야 하는 낭비가 발생한다 [15, 16].
    • 오버드로우(Overdraw) 및 정렬 부재: 인스턴스들은 버퍼에 저장된 순서대로 렌더링되며 카메라와의 거리에 따른 자동 깊이 정렬을 지원하지 않는다 [17, 18]. 이로 인해 투명한 객체 렌더링 시 알파 블렌딩 오류가 발생하거나, 불투명 객체의 심각한 오버드로우를 유발해 프래그먼트 셰이더 연산 부하가 급증할 수 있다 [17, 19-21].
    • 상호작용 및 애니메이션 난제: 개별 객체에 대한 레이캐스팅(Raycasting) 시 CPU가 각 인스턴스의 변환 행렬을 개별 계산해야 하므로 대규모 씬에서는 동기화 병목이 발생할 수 있다 [22]. 또한 본(Bone) 기반의 스킨드 애니메이션(Skinned Mesh)을 기본적으로 지원하지 않아 군중 애니메이션 등을 구현하려면 복잡한 커스텀 파이프라인이 요구된다 [23].
  • 활용 및 제어: 개별 인스턴스의 속성은 setMatrixAt, setColorAt 등의 메서드를 통해 제어하며, 값을 변경한 후에는 반드시 해당 속성(instanceMatrix, instanceColor 등)의 needsUpdate 플래그를 true로 설정해야 렌더링에 반영된다 [24]. 위에서 언급한 개별 컬링이나 정렬 문제를 극복하기 위해 [[InstancedMesh2|InstancedMesh2]] 같은 확장 라이브러리를 사용하거나 BVH(Bounding Volume Hierarchy)를 통한 공간 분할 기법을 도입하기도 한다 [25-27].

⚖️ Trade-offs & Caveats

  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Graphics & Performance 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.
  • 과거 데이터와의 충돌: 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
  • 정책 변화: Programming & Language 분야의 자동 자산화 수행.

🔗 Knowledge Connections

  • Related Topics: Draw Call Optimization (드로우 콜 최적화), BatchedMesh, Object Pooling (오브젝트 풀링, React Three Fiber 자산 최적화
  • Projects/Contexts: 대규모 파티클 시스템 최적화, 수만 개의 데이터를 표현하는 3D 산점도(Scatter Plot) 시각화, 숲, 군중 등 반복 객체가 많은 3D 씬
  • Contradictions/Notes: InstancedMesh는 성능 개선에 탁월하지만, 모든 인스턴스가 반드시 동일한 기하구조(Geometry)와 재질(Material)을 공유해야 한다는 설계적 제약이 따릅니다. 만약 재질은 같으나 형태(Geometry)가 서로 다른 여러 객체들을 묶어 드로우 콜을 1회로 줄이려면, R156 버전에 도입된 BatchedMesh를 사용하는 것이 더 적합합니다.
  • Related Topics: InstancedMesh, 가비지 컬렉션 (Garbage Collection), 객체 풀링 (Object Pooling), 버퍼 사전 할당 (Buffer Preallocation)
  • Projects/Contexts: Needle Engine, A-Frame (instanced-mesh 컴포넌트), 실시간 웹 그래픽스 최적화
  • Contradictions/Notes: 예측 불가능한 다량의 객체를 렌더링하려면 동적 확장이 필수적인 기능처럼 보이나, 실제 렌더링 환경에서는 이 과정이 프레임 드랍과 메모리 누수 위험 등 높은 리스크를 수반하므로 오히려 고정 용량 할당이나 풀링을 통해 원천적으로 확장을 회피하는 것이 강력히 권장된다 [1, 3, 4].

Last updated: 2026-04-19

  • Related Topics: Frustum Culling, Overdraw, BatchedMesh, WebGPU Compute Shader, Texture Atlas, Garbage Collection (GC)
  • Projects/Contexts: 대규모 웹 그래픽스 프로젝트, CAD 렌더링 최적화, BIM 모델 렌더링
  • Contradictions/Notes: 소스에 따르면 InstancedMesh 기술은 드로우 콜을 획기적으로 줄여 CPU 부담을 최소화하지만, 자체적인 정렬 부재와 컬링의 한계로 인해 조명 연산이 복잡한 환경에서는 오버드로우를 유발하여 결과적으로 GPU 픽셀 처리 성능을 상회하게 만들어 전체 FPS를 하락시킬 수 있다는 모순된 현상이 발생함을 강력히 지적합니다 [6]. 또한 대안으로 제시되는 BatchedMesh 역시 드로우 콜을 줄일 수는 있으나, 극한의 대규모 삼각형 렌더링 시에는 버퍼 패킹 비용이 오히려 일반 메쉬 렌더링보다 낮은 성능을 보이는 병목 사례가 보고됩니다 [15].

Last updated: 2026-04-19

  • Related Topics: Draw Call, Frustum Culling, BatchedMesh, Texture Atlas, Level of Detail (LOD), Overdraw
  • Projects/Contexts: Three.js, WebGL/WebGPU Rendering, Babylon.js, Unity GPU Instancing
  • Contradictions/Notes:
    • "InstancedMesh를 사용하면 항상 성능이 향상된다고 가정하기 쉽지만, 소스는 매우 단순한 기하학(예: 단일 삼각형)의 경우 인스턴싱 변환 행렬 데이터를 처리하는 오버헤드가 더 커서 단순히 지오메트리를 병합(Merging)하는 방식이 오히려 프레임 레이트 측면에서 유리할 수 있다고 주장합니다 [32], [33]."
    • "드로우 콜 수가 극적으로 감소함에도 불구하고, 5,000개 수준의 객체 환경에서는 인스턴스 정렬 부재로 인한 오버드로우 비용이 CPU 이득을 상회하여 일반 메쉬 렌더링보다 낮은 FPS를 기록할 수 있다고 경고합니다 [18]."

Last updated: 2026-04-19

  • Related Topics: Draw Call, BatchedMesh, Frustum Culling, BufferGeometry, Overdraw
  • Projects/Contexts: Three.js, WebGL, InstancedMesh2
  • Contradictions/Notes: InstancedMesh는 드로우 콜 횟수를 줄여 전반적인 성능을 높이기 위해 사용되지만, 자동 정렬의 부재 및 개별 인스턴스 컬링 불가 문제로 인해 극심한 오버드로우가 발생할 경우, 일반적인 Mesh(공유 속성 활용)를 사용할 때보다 오히려 프레임 레이트(FPS)가 급격히 저하되는 역설적인 병목 현상이 발생할 수 있다고 여러 소스에서 경고한다 [15, 17, 28, 29].

Last updated: 2026-04-19

Reference in New Issue View Git Blame Copy Permalink