1. ✅ 드로우 콜(Draw Call) 기본개념
-
게임에서 화면에 뭔가를 그릴 때,
CPU가 GPU한테 이거 그려줘 하고
명령을 보내는 단위를 드로우콜이라고 함. -
이것이 많아지면 CPU가 계속 명령 보내느라 바빠지고,
GPU도 잦은 상태 전환 때문에 부담이 커져서 프레임이 떨어질 수 있음.
그래서 드로우콜은 적을수록 좋다 는 말이 흔히 통용되어짐.
2. ✅ 드로우 콜은 왜 생길까?
- GPU는 한 번에 여러 물체를 통째로 그리는 기계 처럼 보이지만,
실제로는 조건이 맞아야 한 번에 묶어서 그릴 수 있음. - 조건이 맞지 않으면 GPU 상태(state)를 바꿔야 하고,
상태를 바꿀 때마다 드로우콜이 추가 발생됨.
대표적으로 상태를 바꾸는 요소들:
-
머티리얼/셰이더가 다를 때
-
텍스처가 다를 때
-
메시가 완전히 분리되어 있을 때
-
블렌드 모드나 깊이 테스트 설정 등이 다를 때
3. ✅ 드로우 콜이 많아지면 뭐가 문제일까?
- GPU 성능만 보면 많이 그릴 수 있지 않나? 싶지만...
사실 병목은 CPU 의 문제임. - CPU가 GPU한테 드로우 명령을 하나하나 보내는 시간이
누적되면서 병목이 생김. 즉, CPU 오버헤드 = 드로우콜 비용
그래서 드로우콜이 늘면 FPS가 출렁이는 주범이 됨.
4. ✅ 드로우 콜을 줄이는 실전 방식들
실제 게임 프로젝트에서 주로 쓰는 최적화 기법들:
- 메시 합치기(Mesh Merge / Static Mesh Merge)
여러 오브젝트를 하나의 메시로 합쳐서 드로우 콜을 한 번으로 줄임.
머티리얼 통합(Atlas 또는 Master Material 사용)
텍스처 아틀라스나 같은 머티리얼을 공유하여 GPU 상태 전환을 줄임.
인스턴싱(Instancing)
같은 모델을 여러 개 뿌릴 때 가장 효율적.
예: 숲의 나무들, 도시의 가로등
HLOD / LOD 시스템
멀리 있는 건 저품질 모델로 묶어서 그려 부하를 줄임.
오클루전 컬링 / 프러스텀 컬링
안 보이는 건 아예 그리지 않음 → 드로우콜도 감소.
5. ✅ UE(언리얼) 기준으로 이해하기
- 언리얼은 레벨에서 StaticMeshActor가
하나 있을 때마다 거의 1드로우콜을 쓰는 느낌임.
그래서 아래 같은 상황이 위험해짐:
-
복잡한 오브젝트 여러 개를 하나도 병합 안 했을 때
-
텍스처/머티리얼이 죄다 제각각일 때
-
나무 수천 개를 그냥 배치만 했을 때
언리얼은 특히 InstancedStaticMeshComponent, Hierarchical Instanced Static Mesh(HISM) 같은 걸 잘 쓰면 드라마틱하게 드로우콜을 줄일 수 있음.
6. ✅ 드로우 콜은 무조건 줄이는 게 정답 은 아님
너무 무작정 병합하면 오히려 손해일 때도 존재함.
-
상황별로 컬링이 안 되고
-
작은 수정에도 큰 리소스를 다시 로딩해야 하고
-
빌드 파이프라인이 무거워짐
그래서 실제 게임에서는 드로우콜 최적화 = 적당한 수준에서 밸런스 찾기 가 핵심
7. ✅ 한 줄 요약
-
드로우콜은 GPU에게 보내는 그려라 명령의 횟수고,
많아지면 CPU가 버벅이기 때문에 성능이 떨어짐. -
그래서 개발자들은 메시/머티리얼/텍스처를 통합하거나
인스턴싱 같은 방법으로 명령 횟수를 줄이는 것에 집중함.
