드로우 콜 배칭은 Unity가 더 적은 드로우 콜로 렌더링할 수 있도록 메시를 결합한 드로우 콜 최적화 메서드입니다. Unity는 두 가지 빌트인 드로우 콜 배칭 메서드를 제공합니다.
Unity의 빌트인 드로우 콜 배칭은 메시를 수동으로 병합하는 것에 비해 몇 가지 장점이 있습니다. 특히 Unity는 메시를 계속 개별적으로 컬링할 수 있습니다. 하지만 몇 가지 단점도 있습니다. 정적 배칭에는 메모리와 스토리지가 많이 사용되고, 동적 배칭에는 CPU 리소스가 많이 사용됩니다.
이 섹션은 Unity 빌트인 드로우 콜 배칭 메서드의 렌더 파이프라인 호환성에 대한 정보를 포함하고 있습니다.
| 기능 | 빌트인 렌더 파이프라인 | 유니버설 렌더 파이프라인(URP) | 고해상도 렌더 파이프라인(HDRP) | 커스텀 스크립터블 렌더 파이프라인(SRP) |
|---|---|---|---|---|
| Static Batching | 지원 | 지원 | 지원 | 지원 |
| Dynamic Batching | 지원 | 지원 | 지원 안 함 | 지원 |
다음 사용 정보는 정적 및 동적 배칭에 모두 해당됩니다. 각 드로우 콜 배칭 메서드(각 메서드를 활성화하고 사용하는 방식 등)에 특화된 정보는 정적 배칭 및 동적 배칭을 참조하십시오.
메시 렌더러, 트레일 렌더러, 라인 렌더러, 파티클 시스템, 스프라이트 렌더러는 드로우 콜 배칭 처리를 지원합니다. 스킨드 메시 렌더러 천을 포함한 다른 타입의 렌더링 컴포넌트는 지원되지 않습니다. Unity는 렌더러를 동일한 타입의 다른 렌더러와만 배칭합니다. 예를 들어 메시 렌더러는 메시 렌더러와 배칭합니다.
Unity는 동일한 머티리얼을 사용하는 게임 오브젝트의 드로우 콜을 배칭합니다. 즉, 드로우 콜 배칭에서 최상의 결과를 얻으려면 가능한 한 많은 게임 오브젝트 간에 머티리얼을 공유합니다. 텍스처를 제외하고 동일한 머티리얼 에셋이 2개 있는 경우 텍스처를 큰 텍스처 하나로 결합할 수 있습니다. 이 프로세스를 텍스처 아틀라스라고 합니다. 자세한 내용은 텍스처 아틀라스에 대한 위키피디아 글을 참조하십시오. 텍스처가 같은 아틀라스 안에 있으면 머티리얼 에셋 하나를 대신 사용할 수 있습니다.
빌트인 렌더 파이프라인에서 MaterialPropertyBlock을 사용하여 드로우 콜 배칭을 중단하지 않고 머티리얼 프로퍼티를 변경할 수 있습니다. CPU는 렌더 상태를 계속 변경해야 하지만 MaterialPropertyBlock을 사용하는 것이 여러 머티리얼을 사용하는 것보다 빠릅니다. 프로젝트에서 스크립터블 렌더 파이프라인을 사용하는 경우 MaterialPropertyBlock은 머티리얼에 대한 SRP 배처 호환성을 제거하므로 사용하지 않습니다.
투명 셰이더는 종종 Unity가 메시를 뒤에서 앞으로 진행하는 순서로 렌더링해야 합니다. 투명 메시를 배칭하기 위해 Unity는 먼저 메시를 뒤에서 앞으로 정렬한 다음 배칭을 시도합니다. Unity는 메시를 뒤에서 앞으로 렌더링해야 하기 때문에 불투명 메시만큼 많은 투명 메시를 배칭할 수 없는 경우가 많습니다.
Unity는 트랜스폼 컴포넌트에 미러링이 포함된 게임 오브젝트에 동적 배칭을 적용할 수 없습니다. 예를 들어, Unity는 스케일이 1인 게임 오브젝트와 스케일이 –1인 또 다른 게임 오브젝트를 함께 배칭할 수 없습니다.
드로우 콜 배칭을 사용할 수 없는 경우 서로 가까운 메시를 수동 결합하는 것이 좋은 대안이 될 수 있습니다. 메시 결합에 대한 자세한 내용은 메시 결합을 참조하십시오.
경고: C# 스크립트에서 공유 머티리얼 프로퍼티에 액세스할 때 Renderer.material이 아닌 Renderer.sharedMaterial을 사용해야 합니다. Renderer.material은 머티리얼 사본을 만들고 사본을 렌더러에 다시 할당합니다. 이렇게 하면 Unity가 해당 렌더러에 대한 드로우 콜을 배칭하지 않습니다.
2017–10–26 페이지 수정됨
2017.2에 동적 배칭이 그래픽스 작업과 호환되지 않는다는 내용의 참고 사항 추가됨