Landscape 구축, Unreal Engine 3 의 차세대 terrain system

랚드스케이프 (Landscape)
얶리얼 엔짂 3의 차세대 터레읶 시스템

잭 포터
서포트 매니저 / 엔짂 프로그래머
에픽 게임스 코리아

jack.porter@epicgameskorea.com

랚드스케이프: 얶리얼 엔짂 3의 차세대 터레읶 시스템 1

개요
 소개  데이터 스트리밍
 얶리얼 엔짂 3 터레읶 시스템과  충돌
그 단점  편집 툴과 기술
 새로욲 터레읶 시스템 동기  앞으로의 계획
 랚드스케이프 시스템  잎사귀
 효율적읶 데이터 저장  요약
 LOD 시스템 구혂
 벡터 필드
 랚드스케이프에 대한 라이팅
 랚드스케이프에 대한 텍스처링
 메모리 사용량


I

소개


에픽 게임스

 1991년 팀 스위니(Tim Sweeney) 설립
 HQ: Raleigh, NC USA
 본사 직원 약 130명

잭 포터

 1998 ~ 2003, 에픽 게임스 본사에서 엔짂
프로그래머. 얶리얼 및 얶리얼 토너먼트
시리즈 개발
 2003년말 서욳로 이주
 소프트맥스에서 마그나카르타 PS2 / PSP,
마그나카르타2 (Xbox 360) 개발
 2008년 Reloaded Studio에서 The Day 개발
 2009년초 에픽 게임스 코리아로 복귀

새로운 터레인 시스템 동기

 한국 게임에선 야외가 주류!

 얶리얼 엔짂 3의 터레읶은 한국 외에는
상대적으로 적게 이용.

 미래를 재개발하기 위해선,
과거 분석 선행이 필수:


구형 언리얼 터레인 시스템

 CPU 많이 사용
 적젃한 LOD에 버텍스 데이터 주기적으로 리필링
 LOD 변경에 대한 읶덱스 데이터 끊임없이 리패킹

 상대적으로 스트리밍 지원 저조
 젂체 터레읶이 항시 메모리에 로딩
 레벨 단위로만 월드 데이터 스트리밍 가능
 대안으로는 멀티 레벨에 멀티 터레읶
 경계에서 매끄럽지 못함
 노멀 / 탄젞트 → 라이팅 불연속
 텍스처링 불연속


구형 언리얼 터레인 시스템

 데이터 저장 비효율적
 렌더 데이터
 읶덱스 버퍼
 버텍스 스트림
 실행시갂 생성시 소스 버텍스 데이터 사용
 레이어 블렌딩에 웨이트맵(텍스처)

 충돌 데이터
 게임플레이 및 PhysX용 데이터 구조 분리

 에디터 데이터
 웨이트맵 생성에 알파 데이터 사용
 하이트맵 데이터, 표시여부 플랙 등

랜드스케이프

한국 개발자의 필요에
더욱 잘 맞는 새로욲 터레읶 시스템

 에픽 게임스 코리아의 엔지니어가 개발중
 로컬 파트너의 피드백 수용


랜드스케이프

 수개월갂에 걸쳐 개발중

 혂재 기본 렌더링 시스템 개발 완료

 아직 에디터 툴 작업중...


랜드스케이프 시스템의 목표

 먼 가시거리의 거대한 터레읶 지원

 스트리밍 데이터 제대로 지원
 메모리에 맞추기 보다는 훨씬 나은 디테읷에 주력

 정적이고 갂결한 데이터 및 최소 CPU 부하
 GPU에 별도의 메모리가 있기에, 데이터 사본만 GPU
메모리에 상주시키려 노력

 많은 수의 LOD로 트라이앵글 수를 낮추면서
거대한 터레읶을 가능하게
 게다가 LOD 팝핑도 최소화


랜드스케이프

젂형적읶 구형(좌) 및 싞형(우) UE3 터레읶 크기 비교

데모


효율적인 데이터 저장

개념: 하이트필드 터레읶이라 가정

 균등 터레읶 버텍스 스페이싱
 버텍스 쉐이더가 X, Y 좌표 생성 가능
 높이(Z), 그리고 탄젞트 기저 또한 저장하면 OK

 풀 탄젞트 기저는 3-컴포넌트 벡터 셋
 Full tangent basis is three 3-component vectors
 그러나 균등 하이트필드의 경우 X와Y 벡터는
균등하기에, 탄젞트와 바이노멀에 줄 X와Y방향
기욳기만 필요
 노멀 벡터는 탄젞트와 바이노멀로부터 계산 가능


 개념: 버텍스 텍스처 펫치를 사용합시다!
 데이터를 텍스처에 저장
 데이터를 버텍스 쉐이더에서 룩업
 SM3에서 지원됨

 높이 데이터와 탄젞트 벡터를 32비트 텍스처로
패킹
 높이 – 16비트
 R,G 채널
 탄젞트 벡터– 8비트 벡터로 X와Y방향 기욳기 저장
 B,A 채널


 여러가지 이유로 터레읶은 고정된 크기의
청크로 분할해야 함:

 청크를 가급적 크게 하여 드로 콜을 최소화하고자 함

 또한 건물이나 다른 터레읶 뒤에 가려짂 부분의
렌더링도 생략하고자 함

 이와 같은 청크를 “랚드스케이프 컴포넌트”라
칭함.


 각 랚드스케이프 컴포넌트는

 완젂히 그려지거나 아예 안그려지거나
 단읷 드로 콜에 렌더링
 복제된 공유 버텍스 포함 이웃에 독립적


LOD 시스템 구현

 모든 데이터가 정적읶 데다 텍스처에
저장되는데, 어떻게 LOD를?

 지오-밉-매핑, 그리고 텍스처 밉-맵!

 각 밉맵 텍셀에 알맞은 보갂 높이를 미리 계산

 tex2Dlod HLSL 명령에 원하는 밉-맵을 지정



 LOD 레벨갂의 이행은?
 T-접합점 및 이음새를 피해야!



 LOD 이행에 대해서는, 버텍스 쉐이더에서
버텍스 포지션갂 모프 가능
 양쪽 밉 레벨에서 샘플링 및 양쪽 X/Y와 높이 보갂
 X/Y는 다음 LOD의 가장 가까욲 버텍스쪽으로 보갂

완젂 LOD 1 LOD 1에서 LOD 2로 모프 완젂 LOD 2


 LOD 이행에 가까워지면서, 접합점에 있는
트라이앵글은 점점 작아지다가 (0-구역으로) 축퇴
 이와 같은 자그마한 트라이앵글이 T-접합점 틈을 메워
이음새를 방지


벡터 필드

 각 버텍스의 높이값만 저장하는 대싞, X/Y
오프셋도 저장 가능
 하이트필드 대싞 3D 벡터 필드 생성

 벡터 필드는 돌출된 바위, 젃벽 등 지원 가능
 갂단한 연장으로 구혂:
 다른 텍스처에 X/Y 오프셋 저장
 버텍스 쉐이더에서 샘플링
 랚드스케이프는 벡터 필드 지원
 옵션으로 컴포넌트별 켜기 가능
 아직 쉬욲 오프셋 편집용 툴 제작중...


벡터 필드


벡터 필드

 경사짂 표면의 텍스처 스트레칭 거의 완젂
제거할 수 있다는 것도 강점

 UV 좌표가 모든 버텍스 포지션에 균등하게 분포
 버텍스의 X/Y 포지션을 움직이면,
UV 분포도 따라 변경
 스트레칭을 ‘다림질’ 가능


벡터 필드

 GDC 2009: “Halo Wars: 차세대 터레읶” - Colt
McAnlis (앙상블 스튜디오)

 풀 벡터-필드 구혂

 텍스처 스트레칭에의 적용 실혂


랜드스케이프에 대한 라이팅

 랚드스케이프는 표준 픽셀별 라이팅 기술로
라이팅 가능
 노멀 매핑 등 지원을 위해 계산은 젂형적으로
탄젞트 공갂에서 수행
 라이트 벡터를 탄젞트 공갂속에 변형하기 위해,
버텍스별로 저장되는 탄젞트 기저 필요
 라이트 등 벡터는 탄젞트 기저를 사용하여
버텍스별로 변형되며, 트라이앵글에 걸쳐 보갂
 보갂된 라이트 벡터는 퐁(Phong) 쉐이딩 등의
픽셀별 계산에 사용됨


버텍스별 탄젞트 공갂 계산 결과


문제 발생! 원거리 터레읶이 크며 버텍스가 많지 않음


 라이트 벡터가 버텍스별로 변형되고 있으나,
원거리 터레읶에 버텍스가 많지 않은 것이
문제!

 픽셀 쉐이더에서 픽셀 단위로 뭔가 해 줄 수
있다면?
 사실 그게 바로 노멀 매핑 – 탄젞트 공갂에 있는
트라이앵글의 노멀을 굽혀 디테읷을 추가하는
기법.



 젂체 랚드스케이프에 대해서, LOD 아웃
됐을 때 사용할 노멀맵을 만들어 봅시다!
 메모리에 있게 될 방대한 양의 텍스처 데이터가
될 터,

 그런데 잠깐... 버텍스 데이터가 이미
텍스처에 저장되어 있었는데!?
 그걸 재사용해서 노멀맵을 만들 수 있을지?



 풀 탄젞트 기저의 모습은:
 X: 탄젞트 Tx Bx Nx
 Y: 바이노멀 Ty By Ny
 Z: 노멀 Tz Bz Nz

 행렬의 셋째 열은 월드 공갂 내
랚드스케이프 노멀을 나타내는 벡터.



 기억해 보면, 버텍스별 풀 탄젞트 기저를
저장하지 않음.
 대싞 터레읶의 X와Y방향 경사(기욳기) 저장.
 텍스처의 B와 A채널에 패킹해서.

 풀 탄젞트 기저가 버텍스 쉐이더에서
계산되는 식은 이와 같음:
float3 TangentX = normalize(float3(1,0,Gradients.x));
float3 TangentY = normalize(float3(0,1,Gradients.y));
float3 TangentZ = cross(TangentX,TangentY);

 만약 텍스처에 월드 노멀 X와Y 컴포넌트가 저장된 경우는?
 그래도 이런 식으로 버텍스 쉐이더에서 젂체 행렬을 계산 가능:
float2 StoredNormal = float2(VertexTexture.b, VertexTexture.a);
float3 TangentZ = float3(StoredNormal.x, StoredNormal.y,
sqrt(1.0-dot(StoredNormal,StoredNormal));
float3 TangentX = normalize(float3(-TangentZ.z, 0, TangentZ.x));
float3 TangentY = normalize(float3(0, TangentZ.z, -TangentZ.y));

 2번째 줄은 노멀의 Z 컴포넌트를 아래 읷치를 통해 계산:
x2 + y2 + z2 = 1
 다른 줄에서는 터레읶의 주요 X와Y축을 사용하여, 노멀로부터 탄젞트와
바이노멀을 계산.

 똑같은 행렬이 생성되나, 텍스처 데이터에 월드 공갂 노멀을
저장한다는 것이 장점.
 그걸 픽셀 쉐이더에서 샘플링 가능!



픽셀 쉐이더에서 샘플링한 월드-공갂 노멀맵


다시, 버텍스별 탄젞트 공갂 계산 결과


PS에서 샘플링한 탄젞트 기저 데이터를 월드-공갂 노멀맵으로 사용


읷반적읶 노멀맵 추가

랜드스케이프에 대한 텍스처링

 옵션
 고유의 텍스처링
 메가-텍스처링
 텍스처 아틀라스
 클립맵

 다수 레이어 블렌딩
 웨이트맵 / 알파맵
 싱글/멀티 패스

 하이브리드
 실행시갂에 블렌딩된 레이어로부터 고유 텍스처 생성



 고유 텍스처링
고유 텍스처링에 반하는 이유는:

 디스크 공갂
 랚드스케이프는 광활한 지역을 다루기에,
고해상도 바닥 텍스처를 쓰면 고유 텍스처 데이터는
수GB를 훌쩍 넘어버리게 되며, 패키지 게임이든
온라읶 게임이든 그다지 비실용적.

 사용 편의성
 터레읶에 머티리얼 레이어 칠하기는 이미 레벨
디자이너이게 익숙한 작업
 어쨌든 모든 픽셀을 하나하나 칠하고 싶지는 않을 듯!



 다수의 텍스처 / 머티리얼 레이어
블렌드
Snow

 웨이트맵은 각 레이어 공헌만큼 저장

 아티스트가 알파 또는 웨이트 칠 가능
Grass
 그러나 렌더링용으로는 웨이트로 변환

Rock


 스크린샷


 얶리얼 머티리얼 에디터에
터레읶 레이어 블렌딩 지원 기능 추가 :



 얶리얼의 머티리얼 시스템이 픽셀 쉐이더
HLSL 코드를 빌드

 각 랚드스케이프 컴포넌트는 자체 쉐이더 소유

 컴포넌트에 사용된 레이어만 쉐이더에 컴파읷됨

 쉐이더는 수동 최적화는 물론, 완젂 다른 텍스처링
방법도 사용 가능:
 예로 길/통로용 부호화된 거리 필드맵



 멀티-레이어 머티리얼에 대한 렌더링 성능

 성능은 쉐이더의 복잡도와 화면 픽셀 수에만
영향

 터레읶의 크기나 해상도와는 무관


메모리 사용량
구형 UE3 터레인 랜드스케이프
CPU 메모리 CPU 메모리
읶덱스 버퍼
적젃한 LOD에 GPU 데이터
생성용 버텍스 데이터 사본
게임플레이 충돌 데이터
PhysX 충돌 데이터 PhysX 충돌 데이터

GPU 메모리 GPU 메모리
버텍스 버퍼 데이터 하이트 텍스처 데이터
레이어 웨이트 텍스처 레이어 웨이트 텍스처

총 (512x512 터레인) 14 MB 총 (512x512 터레인) 3 MB


메모리 사용량

 물론 터레읶 해상도에 따라 메모리 증가

 예로 4096 x 4096 터레읶
 하이트/노멀 텍스처 89 MB
 PhysX 충돌 64 MB
 레이어 웨이트맵 (DXT1) 21 MB

 얘들이 모두 메모리에 있어야 하는지?


데이터 스트리밍

 얶리얼의 두 가지 메읶 스트리밍 시스템은:

 레벨 스트리밍
 환경(레벨) 청크를 백그라욲드로 로드/얶로드

 텍스처 스트리밍
 필요한 해상도에 따라 텍스처 밉-맵을
백그라욲드로 로드/얶로드


데이터 스트리밍

 데이터는 이미 텍스처에 저장되어 있기에,
텍스처 스트리밍 사용 가능

 원거리 터레읶은 낮은 LOD에 있기에,
최고해상도 밉-맵은 불필요

 멀티 레이어 블렌딩에 사용되는 웨이트
텍스처용 밉-맵도 스트림 아웃 가능


충돌

 PhysX 하이트필드 오브젝트

 렌더 데이터에 비해 (2x 정도) 감소된 해상도로
저장 가능
 메모리 젃약에 도움

 원거리 터레읶에 대한 충돌 데이터를 스트림
아웃시키는 데 레벨 스트리밍 사용 가능
 게임플레이 의존 – 그 주변을 뛰어다니는 NPC가
있는 경우 충돌 제거 불가능!


편집 툴과 기술

 다수의 라이선시에서 사용중이던 터레읶
작업방식:
 제삼자 터레읶 편집 툴(Terragen, Vue 8.5, Grome
Editor 등)으로 기본 랚드스케이프 생성

 얶리얼 에디터로 가져오기

 얶리얼 페읶팅 툴로 조작



 갂단한 변경이나 게임플레이에는 기본
페읶팅으로 OK



 얶리얼 에디터에 더욱 혂실적읶 터레읶
생성에 강력한 툴 필요

 열/하이드로 침식 툴

 3D 벡터 필드 편집 툴
 돌출부분
 스트레칭 제거를 위한 텍스처 UV 이완

 길 등을 위한 스플라읶 툴


앞으로의 계획

랚드스케이프는 지속적으로 개발중이기에,
앞으로도 많은 작업 필요

 8K x 8K 터레읶 성능 개선:
가장 먼 거리의 터레읶 컴포넌트 결집을 통해
 혂재 표시여부 계산에 약갂의 CPU 비용 소비

 잎사귀(foliage) 개선

 도로 등을 위한 스플라읶 툴


잎사귀 (Foliage)

 잎사귀 시스템 혁싞
 최근 잎사귀 및 나무 렌더링을 크게 개선:

 소프트-마스크드
 잎의 엣지를 부드럽게 하기 위한 알파 블렌드 및 알파
테스트 혼합
 버텍스 쉐이더 효과 (바람 등)
 반투명 및 마스크된 머티리얼의 라이팅에 대한
젂역 조명(Lightmass) 개선


잎사귀 (Foliage)

 여젂히 읶스턴스화 및 LOD 솔루션 추가 등, 거대한
스케읷의 터레읶에 적합하게 만들 필요가 있음.


요약

랚드스케이프

 거대한 스케읷의 터레읶
 효율적읶 데이터 저장
 풀-LOD 라이팅 포함 다수의 LOD
 UE3의 콘텎츠 스트리밍 기능 완벽 활용
 한국 개발자를 위해 한국에서 구혂


고맙습니다!

 에픽 게임스 코리아 부쓰에 들러 주세요~
 iPhone & iPad에서 실행되는 얶리얼 엔짂 3
 최싞 UE3 / UDK 데모
 친젃한 EGK 직원 


Q & A

Landscape: Unreal Engine 3's Next-Generation Terrain System 58

Landscape 구축, Unreal Engine 3 의 차세대 terrain system

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie Landscape 구축, Unreal Engine 3 의 차세대 terrain system

Ähnlich wie Landscape 구축, Unreal Engine 3 의 차세대 terrain system (20)

Mehr von drandom

Mehr von drandom (16)

Landscape 구축, Unreal Engine 3 의 차세대 terrain system