Overdraw

📌 한 줄 통찰 (The Karpathy Summary)

오버드로우(Overdraw)는 렌더링 파이프라인의 프래그먼트 셰이딩(Fragment Shading) 단계에서 동일한 픽셀 위치에 렌더링 연산 및 쓰기 작업이 여러 번 중첩되어 GPU 자원이 낭비되는 현상입니다. InstancedMesh를 사용할 때 개별 인스턴스에 대한 자동 정렬(Sorting) 기능이 부재하여 깊이 테스트(Early-Z)를 통한 최적화가 무력화되면서 막대한 오버드로우가 발생할 수 있으며, 이는 심각한 렌더링 프레임 지연의 핵심 원인이 됩니다[1, 2].

📖 구조화된 지식 (Synthesized Content)

오버드로우의 발생 원리: 투명한 지오메트리가 겹쳐 있거나 객체들이 비효율적으로 정렬되어 있을 때, 가려져서 최종 화면에 보이지 않을 픽셀에 대해서까지 GPU가 계산을 수행하면서 발생합니다[1].
InstancedMesh의 구조적 정렬 부재: 일반적인 불투명 객체는 '앞에서 뒤로(Front-to-Back)' 정렬하여 렌더링함으로써 뒤에 가려진 픽셀 연산을 조기에 종료하는 'Early-Z' 기법을 활용할 수 있습니다. 그러나 InstancedMesh는 이러한 자동 정렬 기능을 제공하지 않으며, 오직 버퍼에 저장된 순서대로만 인스턴스를 렌더링합니다. 카메라와 멀리 있는 인스턴스가 먼저 그려지고 가까운 인스턴스가 나중에 그려질 경우, GPU는 동일한 픽셀 영역에 대해 중복된 계산을 강제로 수행하게 됩니다[2].
드로우 콜 최적화의 역설 (성능 저하 사례): 실제 벤치마크 사례 연구에 따르면, 5,000개의 구체를 렌더링할 때 드로우 콜이 1회인 InstancedMesh 방식의 FPS가 드로우 콜이 5,000회인 일반 개별 메쉬 방식보다 오히려 더 낮게 측정되는 현상이 보고되었습니다. 이는 드로우 콜 감소를 통해 얻은 CPU 연산 이득보다, 정렬되지 않은 인스턴스들이 유발한 막대한 오버드로우 비용이 GPU의 픽셀 처리 성능 한계를 상회했기 때문입니다[2].
병목을 가중시키는 요인: 오버드로우로 인한 렌더링 병목 현상은 복잡한 조명 연산이 포함된 MeshStandardMaterial과 같은 재질을 사용할 때 씬(Scene)을 프래그먼트 바운드(Fragment-bound) 상태로 빠뜨리며 더욱 심화됩니다[2, 3]. 또한 나뭇잎(Foliage)처럼 투명도(Transparency)를 지닌 지오메트리의 경우, 조기 깊이 테스트가 비활성화되고 동일한 픽셀을 5~10번씩 반복하여 렌더링해야 하므로 픽셀 채우기 비율(Fill rate)이 급감하는 치명적인 원인이 됩니다[1, 4].

⚠️ 모순 및 업데이트 (Contradictions & RL Update)

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

🔗 지식 연결 (Graph)

Related Topics: InstancedMesh, Fragment Shading, Early-Z, 프래그먼트 바운드(Fragment-bound), Draw Call, Sorting
Projects/Contexts: three.js Issue, 대규모 인스턴스 렌더링 및 투명도 처리
Contradictions/Notes: CPU 부하를 유발하는 드로우 콜을 줄이기 위해 InstancedMesh를 도입하더라도, 내부 인스턴스들의 정렬 부재가 유발하는 오버드로우 비용이 더 크다면 오히려 드로우 콜이 많은 개별 메쉬 렌더링 방식보다 FPS가 떨어질 수 있다는 역설적인 결과를 보여줍니다[2, 5].

Last updated: 2026-04-19

3.8 KiB Raw Blame History

Overdraw

📌 한 줄 통찰 (The Karpathy Summary)

📖 구조화된 지식 (Synthesized Content)

⚠️ 모순 및 업데이트 (Contradictions & RL Update)

🔗 지식 연결 (Graph)

3.8 KiB

Raw Blame History