[번역]Unity Labs: AutoLOD – Experimenting with automatic performance improvements

Unity Labs: AutoLOD – Experimenting with automatic performance improvements

Amir Ebrahimi, 1월 12, 2018

원문 링크 : https://blogs.unity3d.com/kr/2018/01/12/unity-labs-autolod-experimenting-with-automatic-performance-improvements/

구글 번역기 돌린건 수정하느라 했지만 어색한 부분이 많습니다. 감안하고 봐주세요~

Check out the code on GitHub!

GPU 성능 향상을 위해서는 다양한 기법이 사용됩니다. Occlusion culling, Texture atlasing, static/dynamic batchnig, gpu instancing, shader fallbacks, multi-threading, lightmapping, optimizing GC, script and more techniques....  그중 하나가 이 LOD 기법입니다.

현실적으로 현업에서 LOD를 사용하지 못하는 이유는 다음과 같습니다.

아티스트의 LOD 작업 부하

워크플로우 상에 작업 파이프라인의 설정

일부 엔지니어의 서포트 필요

LOD 사용을 위한 이점 예상의 어려움 등등...(외국도 뭐 비슷하네요)

지난 여름에 저는 AutoLOD라고 불리는 실험 프로젝트에서 LOD 사용에 대한 이러한 장벽 중 일부에 도전하려고 했습니다. 나는 Yangguang Liao 박사의 실험실에 합류했습니다. 캘리포니아 대학 (University of California, Davis)의 학생으로 프로젝트를 지원했습니다.. 이 프로젝트의 일부는 원래 Elliot Cuzzillo와 함께 Hack Week 11 (2016)에 시작되었으며 Jake Turner와 함께 Hack Week XII (2017) 동안 계속되었습니다.

위의 비디오는 평균 LOD [왼쪽]가 30fps 인 렌더링을 SceneLOD(AutoLOD 패키지의 일부)와 비교하여 [오른쪽] 평균 42fps로 렌더링 한 것입니다. 전체 줌에서 전통적인 LOD는 ~ 9ms / 7ms (CPU / GPU)에 비해 ~ 1ms / 0.5ms (CPU / GPU)의 SceneLOD를 사용합니다. 참고 : 색상 불일치는 사용자 정의 할 수있는 SceneLOD에 사용되는 현재 셰이더 때문입니다.

각 재생 창의 아래에는 프로파일러 창의 기록이 있습니다. 왼쪽에는 더 많은 장면이 표시 될 때 렌더링 비용 풍선이 표시됩니다. 계층적 LOD가 시작되면 렌더링 비용은 상대적으로 일정하게 유지됩니다 (자세한 내용은 나중에 설명). 오른쪽에 CPU 사용량이 거의 없다는 것을 알 수 있습니다. 감소 된 그리기 호출 수 때문입니다.

Vision(비전)

AutoLOD의 비전은 자동적이고 확장 가능하며 플러그 가능한 LOD (Level of Detail) 시스템이 렌더링 중심의 프로젝트를 지원하고 지속적인 LOD 연구를위한 테스트 베드 역할을 할 수있는 Unity에서 어떻게 보이는지를 탐구하는 것이 었습니다. 다음 용어를 정의합시다.

     일반적으로 LOD를 자동 생성하기 위해 합리적인 기본값이 사용되므로 일반적으로 프로젝트가 더 나은 성능으로 실행됩니다.

     기본 LOD 생성기 및 런타임을 확장 및 / 또는 재정의 할 수 있다는 점에서 확장 가능합니다 (예 : 개별 또는 연속).

     제 3자가 기본 LOD 생성기 대신 사용할 수있는 자체 LOD 생성기를 만들어 붙일수 있다는 점

Goals(목표)

이 실험 프로젝트의 초기 목표는 다음과 같습니다.

     합리적인 기본값으로 모델 임포트시 LOD 생성
     프로젝트 차원 및 모델 별 LOD 가져 오기 설정
     GPU 가속 기본 LOD 생성기
     비동기식, 플러 거블 LOD 생성 프레임 워크
     SceneLOD를 통한 계층 적 LOD 지원
     대체 기술 (예 : 연속, 뷰 종속 등)을 위해 LOD 생성기와 쌍을 이룰 수있는 확장 가능한 런타임
     LOD 생성기 비교를 허용하는 "Workbench Scene

시간 제약으로 인해 모든 목표에 도달 한 것은 아닙니다. 그러나 우리는 실험이 비전의 일부가 성공한다는 점에서 성공한 것이라고 생각했습니다. 세부사항을 살펴봅시다.

LOD Generation

자동 생성되는 LOD 생성이라는 비전에 귀 기울이며 우리의 목표는 대부분의 프로젝트에서 작동 할 수있는 적절한 기본값을 설정하는 것이 었습니다. 모든 전문 LOD 패키지에는 많은 슬라이더와 토글이 포함되어 있으며 이상적으로는 자동 생성 된 LOD가 손으로 튜닝 할만큼 끔찍한 것일 때만 필요합니다. 즉, Edit -> Preference 설정에서 지정할 수있는 프로젝트 차원의 설정이 있습니다.

생성 된 LOD가 올바르지 않으면 모델 파일별로 모델을 재정의 할 수 있습니다.

단일 파일에 대한 단순화 / 배터 콤보를 변경하거나 가져올 때 자동 생성을 끄고 LOD를 수동으로 제공 할 수 있습니다. 원하는 경우 LOD 체인에 LOD를 추가 할 수도 있습니다. LOD 체인은 프로젝트에서 가져온 버전의 모델 파일에 포함되므로 LODGroup을 설정하기 위해 별도의 프리팹이 필요하지 않습니다.

SceneLOD

SceneLOD는 2001년 I3D 논문에서 Erikson, C., D. Manocha 및 W. Baxter의 연구에서 영감을 얻은 것입니다. Unity의 기존 LODGroup 구성 요소와 함께 사용할 수있는 구현을 작성하여 Unity의 사용자 정의 빌드가 필요하지 않도록했습니다. LODGroup 구성 요소의 경계 볼륨 계층 구조 (현재 Octree)는 장면을 렌더링하는 데 사용되는 LOD를 제어합니다.

Why HLOD?

성능 최적화로서, HLOD (Hierarchical Level of Detail)는 씬의 개별 메쉬를 그룹화 된 표현으로 대체하기 위해 개별 메쉬를 분할합니다. 전통적인 LOD (Detail of LOD)는 화면 크기, 거리, 시점 또는 다른 측정 항목에 따라 적절한 메쉬 표현을 선택합니다. 렌더링 된 각 메시는 선택된 LOD에 관계없이 일반적으로 추가 드로우콜을 추가합니다. 전통적인 LOD의 한계는 각 객체의 LOD 체인이 개별적으로 평가 될 때 드로우콜을 위해 집계에 최적화가 없다는 것입니다. Static batchnig 처리는 공유 된 자료로 집계되기 때문에 이 문제의 일부만 해결합니다. 드로우콜은 일반적으로 CPU에 부담이되므로 일반적으로 CPU 호출 속도를 줄이면 CPU 성능이 향상됩니다.

HLOD는 텍스처 볼륨을 활용하여 특정 볼륨 내의 모든 객체를 단일 메쉬 및 단일 재료로 결합하여 드로우 콜을 줄일 수 있습니다. 전체 장면의 넓은 화면을 표시하려는 게임의 경우 HLOD는 성능에 큰 도움이됩니다. 다른 경우, HLOD는 결합 된 메시 그룹으로 decimated된(Mesh 수를 감소시킨) 개별 LOD의 품질을 능가 할 수도 있습니다. HLOD의 단점은 BVH의 모든 노드에서 각 HLOD 메시에 대한 추가 메모리 비용이 필요하다는 것입니다.

Performance Analysis

POLYGON - City Pack에서 제공 한 데모 장면의 약간 수정 된 버전이 사용되었습니다. 타임 라인을 사용하여 카메라가 애니메이션으로 표시되어 가까이보기에서 도시의 전체보기까지 5 초 동안 확대되었습니다. 테스트는 Razer Blade 랩톱 3에서 수행되었습니다.

전통적인 LOD 및 HLOD에 대한 프로파일 러 뷰를 자세히 살펴 보겠습니다.

전통적인 LOD (위)는 카메라가 축소되어 더 많은 씬을 드러내면서 CPU 및 렌더링 비용이 증가하는 것을 보여줍니다.

HLOD 버전의 경우 기존 LOD가 처음 재생을 시작할 때 활성화되어 처음부터 렌더링 비용을 설명합니다. 결국 HLOD가 완전히 활용되면 성능은 거의 일정한 CPU 및 GPU 비용으로 이동합니다. BVH 평가 (즉, 어떤 HLOD가 렌더링되어야 하는지를 결정하는 것)는 약간의 CPU 비용도 갖습니다.

또한 다음 실험은 GameView 및 Stats 창에서 전체 장면 (카메라 고정)으로 실행되었습니다.

Static batching처리에는 장면의 모든 객체를 정적으로 표시 한 다음 재생으로 치는 것이 포함됩니다. 인스 턴싱은 사용 된 모든 자료에서 GPU 인스턴스를 활성화하는 것과 관련이 있습니다.

큰 도시 장면에서 볼 수 있듯이 HLOD는 전통적인 LOD에 비해 1425 %의 성능을 향상시키지만 1487에서 단지 6개의 드로우콜만을 줄입니다.

그러나 HLOD가 진정으로 빛을 발하는 곳은 기존의 LOD가 일반적으로 처리 할 수없는 장면을 제작할 때입니다.

이것은 총 6.2M 삼각형과 11655 batches의 원본 장면을 네 부 복사 한 예제 장면입니다. 83.3ms / 43.9ms (CPU / GPU)로 렌더링하면 반응속도 이하로 떨어집니다.

이제 이 장면을 동일한 장면의 HLOD 버전과 비교하면 다음과 같습니다.

우리는 삼각형 수를 7M으로 늘 렸지만 여전히 1ms / 0.4ms (CPU / GPU)로 렌더링하고 있으며 6 batching 처리만하고 있습니다. 복사본이 원본 장면이지만 - 도시의 각 부분이 개별적으로 고유 한 경우에도 동일한 성능을 기대할 수 있습니다.

Storage Cost

빌드에서 SceneLOD는 스태틱 메시와 텍스처 크기에 추가되지만, BVH 깊이가 줄어들면 축소 될 수 있습니다.

HLOD :

텍스처 36.3 mb 5.3 %
메쉬 599.9 mb 87.6 %

LOD :

텍스처 20.3 mb 20.9 %
메쉬 30.0 mb 30.8 %

HLOD 메쉬의 디스크에 압축되지 않은 크기는 1.1GB입니다.

Time Cost

One-Time

BVH의 생성과 LOD 생성과는 별도로 각 HLOD를 생성하기 위해 HLOD 구현에는 몇 가지 일회성 비용이 있습니다. 이 일회성 계산 비용은 장면에서 물체가 추가, 이동 또는 제거 될 때마다 발생합니다. 그러나 SceneLOD는 이러한 변경 사항을 추적하고 백그라운드에서 BVH 및 HLOD를 자동으로 업데이트합니다.

Dynamic

카메라가 렌더링 될 때마다 BVH를 따라 가서 렌더링 전에 활성화해야하는 LODGroup 구성 요소를 결정해야합니다 .4

Conclusion

우리는 자동 LOD가 LOD를 디지털 제작에 적용하기 위해 몇 가지 문제점을 제거 할 수 있음을 발견했습니다. 민감한 기본값은 대부분의 경우 프로젝트를 가져올 수 있으며 문제가있는 메시가있는 경우 사례별로 재정의 할 수 있습니다. SceneLOD는 큰 장면에서 현재 버전의 Unity와 함께 사용할 수있는 HLOD의 예제 구현을 제공합니다. 성능을 위해 스토리지 비용을 교환하려는 경우 많은 정적 요소가있는 매우 큰 장면에 대해 렌더링 성능을 몇 배 향상시킬 수 있습니다.

이 실험 프로젝트가 자신의 프로젝트의 성능 문제에 대한 통찰력을 제공하고 좀 더 정교한 장면을 만들 수 있기를 바랍니다. 확실히 동적 인 객체에 대한 지원, 디스크상의 HLOD를위한 더 나은 압축, 기본 LOD 생성기, HLOD 렌더링을위한 다른 셰이더 프로파일, 그리고 물론 최적화와 같은 미래의 작업을위한 많은 수단이 있습니다!

GitHub의 코드를 확인하고 직접 프로젝트에 대한 의견이나 문제를 게시하십시오!

Hardware / software configuration:

• Intel i7-6700HQ @ 2.6 GHz
• 16.0 GB RAM
• NVIDIA GeForce GTX 1060
• Samsung SSD HD
• Windows 10 64-bit
• Unity 2017.3.0f2
• Simplygon 8.2.307 for LOD generation