[KOR][100]Large-Scale-Animated-Foliage-in-The-Witc

https://www.youtube.com/watch?v=EdNkm0ezP0o

Frame at 1.25s
# 언리얼 엔진 5: 대규모 애니메이션 식물 기술 (위쳐 4 기술 데모) ## 개요 * **주요 내용:** 대규모 애니메이션 식물 렌더링의 어려움, 초기 실험, 해결책, 그리고 언리얼 엔진 5.7 엔진 기능으로 통합되는 과정 * **발표자:** 케빈, 타이스, 비그네쉬 (CD Projekt) * **시연:** 언리얼 페스트 올랜도에서 공개된 위쳐 4 언리얼 엔진 5 기술 데모 ## 1. 식물 렌더링의 난제 ### 1.1. 과거의 한계 * **현재까지 큰 변화 없는 기술:** * 카드(Cards) 사용 * 알파 테스트(Alpha Testing) 사용 * **나나이트(Nanite)의 이점을 식물에 적용하기 어려움** ### 1.2. 초기 접근 방식 및 문제점 #### 1.2.1. 카드(Cards) 방식 * **단점:** * 기하(Geometry) 방식보다 **3~4배 느림** * 알파 테스트 사용 권장하지 않음 * **팁:** * 기하와 카드의 모양을 최대한 비슷하게 만들 것 * 평면 대신 잘라내는 형식 사용 #### 1.2.2. 알파 테스트의 성능 저하 원인 * **소프트웨어 래스터라이저(Software Rasterizer)에서의 문제:** * 바리센트릭(Barycentrics) 계산 필요 * UV 및 알파 마스크 샘플링을 위한 내부 루프에서의 **막대한 성능 페널티** #### 1.2.3. 기하(Geometry) 방식 * **장점:** * 알파 테스트 문제 없음 (빠른 렌더링) * 노멀 페이킹 불필요 (뛰어난 시각적 품질) * 좋은 서브서페이스 스캐터링(Subsurface Scattering) 효과 * **단점:** * **엄청난 디스크 공간 및 RAM 사용량:** * 단일 나무: VRAM 63MB (카드 방식 대비 10배 증가) * 디스크 공간: 30배 증가 * **LOD(Level of Detail) 생성의 어려움:** * 나나이트의 '보존 영역' 플래그 사용 시에도 먼 거리에서 모양 유지 어려움 * 나무가 삼각형 수프로 변형되어 품질 저하 * 구멍으로 인한 과도한 오버드로우(Overdraw) 발생 * LOD가 더 비싼 렌더링 비용 초래 #### 1.2.4. 애니메이션 (초기 접근) * **버텍스 셰이더 기반 바람:** * **피벗 페인터 2(Pivot Painter 2) 사용:** * 아티스트가 텍스처에 피벗 및 계층 구조 저장 * 버텍스 셰이더에서 런타임 평가 * **문제점:** * 기하 방식 사용 시 수백만 개의 버텍스 변환 필요 (런타임 부하 큼) * 클러스터 바운드(Cluster Bounds) 팽창 필요 (나나이트 컬링 성능 저하) * VSM(Virtual Shadow Map) 페이지 무효화 문제 발생 ## 2. 새로운 해결책 탐색 ### 2.1. 나나이트 활용 및 개발 * **기하 방식의 잠재력 확인** * **스킨드 식물(Skinned Foliage) 도입:** * **2단계 시스템:** * 컴퓨트 셰이더에서 뼈 변환 및 애니메이션 계산 * 버텍스 셰이더에서 버텍스 이동 * **견고한 스키닝(Rigid Skinning) 사용:** * 버텍스 당 하나의 뼈 영향 * 레이 트레이싱(Ray Tracing) 잠재적 이점 ### 2.2. 알파 테스트 최적화 시도 * **나나이트 + 커스텀 LOD:** * **장점:** 20~30% 성능 향상 * **단점:** 팝핑(Popping) 및 카드 방식 관련 문제 재발 * **소프트웨어 래스터라이저 최적화:** * 상당한 개선 있었으나 **점점 줄어드는 효율성(Diminishing Returns)** * 결론: 알파 테스트는 **적합하지 않음** ### 2.3. 기하 방식의 재조명: 모듈식 구성 * **완전한 나무 모델링의 비현실성:** 메모리 비용 문제 * **모듈식 트리 구성 방식 활용:** * 아티스트가 노드 시스템으로 다양한 부품 조합 * **인스턴싱(Instancing) 시도:** * **문제점:** * GPU 씬의 **인스턴스 제한 초과** (매우 많은 부품) * 인스턴스당 비용 발생 (무거운 GPU 씬 데이터) * **가벼운 인스턴스가 필요** ### 2.4. 가상 인스턴싱 (Virtual Instancing) * **개념:** 아키타입 메쉬(Archetype Meshes) 세트로 구성된 가벼운 인스턴스 조합 * **장점:** * 인스턴스 제한에 영향 없음 * 매우 가벼움 * **구조:** * 아키타입 메쉬 포인터 * 트랜스폼 포인터 * 스켈레톤에 속한 뼈 포인터 * **새로운 문제점:** * **나나이트 클러스터 단순화 한계:** 각 가상 인스턴스가 개별 개체로 취급되어 클러스터 병합 불가 * **가상 인스턴스 개수 폭발:** * **삼각형 개수 폭발:** 특히 큰 씬에서 128 삼각형 클러스터 다수 발생 -> 성능 문제 ### 2.5. 가상 인스턴스 LOD * **개념:** 카메라로부터의 거리에 따라 나무 LOD 교체 * **결과:** * 카메라 근처: 큰 차이 없음 * 먼 거리: 삼각형 개수 폭발 방지, 렌더링 시간 감소 * 메모리 사용량: LOD가 적용된 나무가 훨씬 효율적 (165MB vs ~10MB) * **한계:** * 데모에 **최종적으로 사용되지 않음** * 수동 LOD 생성 필요, 에픽과의 통합 필요 ### 2.6. 포인트 클라우드 (Point Clouds) * **개념:** 가상 인스턴스를 포인트 클라우드 클러스터로 대체 * **장점:** * **뛰어난 영역 보존 (Right vs Left)** * **단점:** * **성능 문제:** WIS 버퍼에 대한 원자적 쓰기(Atomic Writes)로 인한 메모리 컨트롤러 트래픽 증가 ## 3. 최종 기술 데모 솔루션 ### 3.1. 복셀 (Voxels) * **목표:** 효율적인 원거리 LOD 및 모양 보존 * **작동 방식:** * 나나이트 빌드 프로세스 중 하위 픽셀 삼각형 클러스터를 복셀 클러스터로 변환 * 4x4x4 브릭(Brick)으로 저장 (64비트 필드) * 런타임 시 래스터라이저 패스에서 브릭 추적 * 깊이 버킷(Depth Buckets)에 따른 렌더링 (조기 깊이 테스트) * **결과:** 오버드로우(Overdraw) 감소에 도움 ### 3.2. 어셈블리 (Assemblies) * **목표:** 디스크 공간 감소 및 고충실도 에셋 유지 * **개념:** * 각각 색상이 다른 개체가 어셈블리 부품(Assembly Part) * 가상 인스턴스와 동일한 입력 사용 * 어셈블리 부품들이 결합되어 연속적인 기하 구조 형성 * **장점:** * 나나이트 빌더가 오프라인 빌드 프로세스에서 LOD 자동 생성 * 어셈블리 변환(Assembly Transform)을 통한 월드 공간 변환 처리 * **성능 비교:** * **어셈블리:** 완전 모델링된 나무의 성능 특성을 유지하면서 메모리 사용량은 훨씬 적음 * **복셀:** LOD 비효율성, 원거리 모양 보존 개선으로 완전 모델링된 기하 구조보다 훨씬 빠름 * **참고:** 어셈블리와 복셀은 **함께 사용되지 않아도 됨** ### 3.3. 스키닝 (Skinning) * **어셈블리 스키닝:** * 각 어셈블리 부품은 최대 8개의 뼈 영향을 받음 (식물은 주로 단일 뼈 영향) * 단순화된 기하 구조에 대한 **버텍스별 스키닝** 적용 * **최적화:** * **기본 최소 애니메이션 화면 크기(Default Min Animation Screen Size):** 화면 크기 임계값 이하의 스킨 메쉬 애니메이션 중지 * **애니메이션:** * **완전 컴퓨트 기반 애니메이션:** * **빠른 처리 속도:** 1000개 이상의 뼈를 가진 큰 나무도 효율적으로 처리 * **바람 평가:** 각 뼈마다 매 프레임 평가 * **재귀적 누적:** 뼈에서 루트까지 위치 및 회전 누적 * **시간:** 약 300 마이크로초 (비동기 컴퓨트 활성화 시 20 마이크로초 미만) * **애니메이션 인스턴싱:** * **필요성:** 500,000개 이상의 식물 애니메이션 시 런타임 부하 감소 * **기존 방식의 문제:** 런타임 스레드 부하 큼 (PS5에서 20ms 이상) * **솔루션:** * **고유 스켈레톤당 8가지 애니메이션 변형 평가** * 스켈레톤 방향에 따라 적절한 템플릿 선택 (근사치 사용) * **결과:** 고유 항목 처리 수 500,000 -> 150 (고유 스켈레톤 수)로 감소 * **성능 향상:** 렌더 스레드 200% 개선, GPU 시간 감소 ## 4. 엔진 기능 (UE 5.7) ### 4.1. 주요 기능 * **동적 바람 플러그인 (Dynamic Wind Plugin):** * 나나이트 식물에 바람 효과 쉽게 적용 * 절차적 바람, 바람 방향 배치, 물리적 매개변수 지원 * **USD 가져오기 지원:** * 에디터 내에서 나나이트 어셈블리 생성 및 편집 도구 제공 * USD 스키마를 통해 DCC 툴에서 어셈블리 구조 마크업 * **나나이트 어셈블리 편집기 유틸리티(Nanite Assembly Editor Utils):** * 뷰포트 선택 항목으로 어셈블리 생성 * 블루프린트 API를 통한 수동 어셈블리 구축 * **절차적 콘텐츠 생성(PCG) 도구 지원:** * 나나이트 어셈블리를 메쉬로 내보내기 가능 * **콘텐츠 예제:** * **Quixel:** 나나이트 어셈블리 및 전체 식물 파이프라인에 최적화된 사전 설정 트리 팩 제공 (FAB에서 제공 예정) * **절차적 식물 에디터 (Procedural Vegetation Editor):** * 그래프 기반 규칙 및 로직을 통한 트리 편집 및 생성 * 기존 툴(Geometry Scripting, PCG)과 유사한 경험 제공 * 나나이트 어셈블리 에셋 생성 및 동적 바람 플러그인 지원 ### 4.2. 기술 데모 데이터 * **씬 규모:** * 약 20,000개의 나무 (컬링 후) * 500,000개 이상의 나무, 170만 개의 덤불, 700만 개의 풀 * 26 제곱 킬로미터 면적 * **식물 에셋:** * 종 다양성: 28종 * 트리 에셋: 수백만 ~ 수천만 삼각형, 수백 개의 뼈 * 가장 큰 나무: 4천만 삼각형 * **성능 지표:** * **숲 섹션:** 100,000개 이상의 뼈가 GPU에서 0.1ms에 업데이트 (매우 빠르고 확장 가능) * **나나이트 패스:** 약 4ms (그림자 패스 제외) * **특정 프레임:** 평균보다 약간 저렴한 비용 (나나이트 및 VSM의 거리 스케일링 덕분) ## 5. 결론 및 Q&A * CD Projekt와 Epic Games의 협업을 통해 대규모 애니메이션 식물 렌더링의 복잡한 문제를 해결 * 새로운 엔진 기능은 아티스트와 개발자가 더 쉽게 고품질 식물을 제작할 수 있도록 지원 * **추가 정보:** * Simon & Hassan (Quixel)의 세션: 내일 오후 2:30 (동일 시간) - 콘텐츠 예제, 툴, 파이프라인, 모범 사례 소개 * Q&A 시간