이번 포스팅에서 Gear VR 어플리케이션과 언리얼 엔진으로 제작한 VR의 전반적인 느낌에 대해서 말씀드리겠습니다. 게임에서 특정한 효과를 보기 위해 사용한 팁들도 또한 공유하도록 하겠습니다.
배운 점
개발 초기 최적화는 Gear VR 체험에 있어 좋은 초석이 됩니다.
광고에서 이론적으로 밝힌 Galaxy S6(저희의 타겟 플랫폼입니다.) Mali-T760 MP8 GPU의 퍼포먼스는 210 GFLOPS / 5.2GTexels/s 입니다. 이 정도 성능은 VR용으로 권장되는 PC의 사양인 Nvidia GeForce GTX 970에 비교됩니다. 이 그래픽 카드는 3494 GFLOPS (raw performance) / 109.2 GTexels/s 의필레이트(fillrate)를 가지고 있습니다. 언리얼 엔진 4가 Oculus DK2(2.097M vs 2.073M)보다 Gear VR에서 더 많은 픽셀을 그려야 한다는 점을 고려해볼 때, 확실히 적은 컴퓨팅 파워와 대역을 갖고 있음을 한 번에 알 수 있습니다. 여기에서 한 가지 장점으로 갖는 것은 프레임 레이트(framerate)입니다. Oculus DK2는 75프레임, Cresent Bay는 90프레임 유지를 목표로 하는 반면에 Gear VR 어플리케이션들은 60프레임만 유지하면 됩니다.
이런 사항들을 염두해 둔 상태로 퍼포먼스로의 한가지 예민한 접근이 남았습니다. 솔직하게 개발하는 것입니다. “최적화 패스”를 이용해서 퍼포먼스 향상을 꾀하고 계시다면, 잘못 알고 계신 것입니다. 이런 접근 방식을 사용하게 되면, 많은 애셋과 기능들을 포기하게 될 것입니다.
VR에서는 개발의 모든 단계에서 퍼포먼스를 생각하는 것이 좋습니다. 씬 속의 특정 기능을 디자인할 때, 랜더링 되어야 하는 독립적인 오브젝트들의 숫자, 모든 그래픽적 충실도에 필요한 효과 등을 생각해야 합니다. 고정된 애셋을 가진 상태에서 동일한 랜더러 설정 아래 프로토타입을 만들어 보시기 바랍니다. 만약 어떤 부분 때문에 최소 요구 프레임 이하로 떨어지게 되면 이 변경 사항을 되돌린 뒤, 변경하지 않거나 다른 브랜치에서 성능 기준에 맞도록 작업을 합니다.
Escape Velocity 작업 전 저희 팀은 언리얼 엔진을 PC 플랫폼용으로만 작업해 왔습니다. 저희는 나중에 고정 60프레임을 얻어내면 될 것이라고 편하게 생각했는데 계속되는 철야 작업과 여러 기능 제거 후에야 저희의 생각이 틀렸다는 것을 알아차렸습니다. 이러한 개발 경험이 저희의 개발 방법론을 바꾸어 놓았고 새로운 프로젝트들은 이러한 깊은 퍼포먼스 문제 때문에 고통받지 않게 되었습니다. 새로운 아이디어들은 퍼포먼스의 허용 한도 내에서 걸러지고 철저히 프로토타이핑 됩니다.
전설의 드로우콜
저희는 프레임 별 드로우콜이 개발 과정 중에 조심스럽게 살펴보아야 하는 기준이라는 것을 알게 되었습니다. 모바일 GPU는 트라이앵글(triangle push)측면에서 굉장히 강력하지만 서로 다른 머티리얼을 갖는 오브젝트로부터의 드로우 콜에서 초래되는 너무 많은 드라이버 상태 변화에는 취약합니다.
이것이 저희가 파츠마다 분리되어 있었던 스테이션을 하나의 커다란 메쉬로 텍스쳐, 맵을 전부 합친 결과물을 만든 이유입니다. 테스트 결과 LOD가 도움이 되지 않았는데, 모든 모듈을 블록아웃(blockout)모델로 바꾼 상태에서도 (각 약 30개의 tris), 갤럭시 S6 Mali-T760 MP8 에서는 60프레임을 유지하지 못했습니다.
오클루전 설정을 변경하는 것 또한 그다지 도움이 되지 않았는데, 왜냐하면 Escape Velocity에서 사용자에게 주는 자유도는 모든 스테이션이 스크린에 보이는 상황 또한 허용하기 때문입니다.
또한 저희는 파티클 이펙트를 포기해야 했는데, 왜냐하면 그 때는 UE4에서 갤럭시 S6의 인스턴싱을 사용할 수 없었기 때문에 드로우콜이 상당했습니다. 하지만, 현재는 4.11에서 잘 지원됩니다.
저희는 최근에 배포된 모바일 GPU 속 벌칸 API를 후속작에서 사용하게 되길 바랍니다. Epic’s Zen Garden데모에서는 메탈(Metal) 같은 저수준 API (벌칸에서도 되기를 희망합니다)의 진정한 가능성을 보여주었고 개발자들이 가졌던 기존 제한 사항들을 잊도록 해 주었습니다.
멀미
멀미에 관한 이슈는 2012년 첫 Oculus 프로토타입 킥스타터 캠페인 때 부터 현대 VR에 이르기까지 쭉 다루어져 왔습니다. 게임플레이 요소를 제외하는 한이 있어도 가능한 멀미를 줄이고 싶다는 의견이 대체적으로 일치했습니다.
Escape Velocity을 실제로 개발하면서 얻은 경험은 그리 간단한 문제가 아니라는 것을 보여줍니다. 멀미의 원인이 기술적 결함이 아닌 경험의 본질에서 오는 것이라면 사람들은 이 부분을 괜찮게 받아들인다는 것이었습니다.
EV외에, Setapp이라는 Gear VR 어플리케이션을 출시하였습니다. 퍼즐 게임인 Neverout입니다. 사람들은 이 타이틀에서 어지러움증이 생기지 않을 것이라 기대하지만 천천히 움직일 때에도 멀미가 발생한다는 사용자의 피드백이있었습니다.
한편, Escape Velocity는 “맙소사, 카펫에 토를 했지만 게임은 멋지네요!” 같은 코멘트가 쏟아졌습니다.
EV를 통해 사람들은 불편한 경험을 예상합니다. 그리고 현실은 정말 그럴 것입니다. 기억해 두시기 바랍니다. 하지만, 저희는 체험 중에 가장 불편한 부분에서 즉시 멈추는 방법을 추가하였습니다. (예를 들어, 제트팩 착용후에 너무 많이 회전하는 것) 이렇게 해서 사용자가 버틸 수 있도록 하였습니다.
트릭
포스트프로세스 박스
4.10 버전에서는 GearVR 에서 모바일 HDR이 지원되지 않았습니다. 즉, 대부분의 포스트프로세스 이펙트가 적용되지 않으므로 특히나 페이드인 같은 효과를 사용할 수 없다는 것을 의미했습니다.
인트로 시퀀스에서 페이드 인 효과가 필요했기 때문에 저희는 약간의 수정을 가했습니다.
저희는 노멀을 뒤집은 스태틱 메시(박스)를 카메라 위치에 고정하였습니다. 여기에는 언릿/뎁스 테스트 없음 으로 설정된 특별한 머티리얼을 사용해서 다른 지오메트리 위에 그려지도록 하였습니다.
보통, 이 오브젝트는 스크린에서 보이지 않고 타임라인에서 불투명도가 변화할 때 잠시 보이게 됩니다.
박스를 너무 작게 하면 안되는데, 왜냐하면 HMD의 헤드 모델에 따라 양안 랜더 중 한 곳이 박스 밖에 위치할 수 있기 때문입니다.
하지만, 이런 접근 방법은 전체 화면이 다시 그려지는 문제점을 갖고 있습니다. 갤럭시 S6의 제한된 픽셀 필레이트 때문에 이 방법은 스크린에 또 다른 거대 반투명 엘리먼트가 있을 때 프레임 드랍을 일으킬 수 있습니다.
기어VR 헤드 모델
아래 "헤드 모델"에서는 목으로부터의 오프셋으로 눈 사이의 위치를 잡습니다. 게임 중에 사용되는 카메라 액터는 가상의 “목”부분에 위치합니다. 각 눈의 실제 위치는 원래 “목” 위치로부터 아래 트랜스폼을 이용하여 구합니다.
- 헤드 트래킹 오프셋을 추가합니다. (Gear VR에는 없음).
- 헤드 트래킹의 입력에 따라 회전
- 헤드 모델 오프셋을 추가
- Inter Pupillary Distance (IPD)에 따라 양안을 분리.
Gear VR에서 UE4는 고정된 헤드모델과 IPD(GearVR.cpp 속 생성자의 FStrings를 참고 바랍니다.)를 사용합니다. Rift에서는 사용자 설정값을 읽어옵니다.
저희는 Gear VR의 기본값 설정이 너무 무겁다는 것을 알았습니다. 우주인이 머리를 회전할 때 헬멧 안에서 한쪽 눈이 헬멧 밖으로 클리핑이 되었습니다. 또한 아주 작은 캐릭터를 시뮬레이션 할 때는 동일한 헤드모델과 IPD 설정 때문에 캐릭터 액터의 사이즈를 조절하는 것 만으로는 불충분하였습니다. 이렇게 하면 월드의 비율이 커지는 느낌이 아니라 그냥 바닥에 누워있는 느낌이 듭니다.
이 문제를 해결하기 위해 헤드모델 전체 스케일이 변경되어야 합니다. 헤드모델, IPD, 헤드 트래킹 오프셋의 스케일을 0.1로 바꾸려면 아래와 같은 콘솔 명령어를 입력하면 됩니다.
- STEREO CS=0.1
- STEREO PS=0.1
이 명령어들은 카메라와 위치 트래킹 오프셋을 1/10으로 줄여서 사용자가 아주 작아진 듯한 느낌을 줍니다.
사용 가능한 HMD의 런타임 파라미터에 대해서는 아래 함수들을 참조해 보시기 바랍니다.
Engine/Source/ThirdParty/Oculus/Common/HeadMountedDisplayCommon.cpp function FHeadMountedDisplay::Exec().
더 좋은 (Gear) VR 체험을 위한 언리얼 엔진 4 수정
저희는 개발 중에 여러 장애물을 만났지만 이를 극복하는 똑똑한 방법들을 찾아냈습니다. 아래는 저희가 겪었던 사례들입니다.
전반적인 UMG와 UI 문제
VR에서 UI 처리를 하는 것은 어려운 문제입니다. 이러한 아이템들은 저희에게 있어 문제거리였습니다.
뎁스 테스팅과 텍스쳐 위 랜더
저희는 헬멧 위에 표시되는 UI와 같은 요소들을 만들고 싶었습니다. 하지만 이 UMG 3D 위젯을 놓았을 때는 카메라에 너무 가깝게 표시되었습니다. Gear VR에서 사용자들은 UI를 보기 위해 불편하게 눈의 촛점을 모아야 했습니다.
그래서 저희는 UI 엘리먼트를 몇 미터 뒤로 밀고 좀 더 크게 만들었습니다. 하지만 이렇게 설정하자 스테이션의 지오메트리와 겹치는 문제가 발생했습니다.
저희는 이 엘리먼트가 제일 상단에 그려지기를 원했습니다. 기본 오브젝트의 경우라면 간단히 머티리얼 설정에서 뎁스 테스팅을 꺼버려서 해결할 수 있지만, UMG 3D 위젯은 가능한 머티리얼들이 고정되어 있습니다. 저희는 결국 뎁스 테스팅을 끌 수 있도록 3D위젯을 확장시키는 방법으로 이를 해결하였습니다.
저희는 UMG 위젯을 텍스쳐로 랜더링 하는 능력을 좋아합니다. 이렇게 하면 특히나 UI엘리먼트가 주변 환경에 녹아들어야 하는 VR에서 3D 위젯보다 더 자유롭게 사용할 수 있습니다. 저희는 이 이슈에 관한 요청을 에픽게임즈에 보냈습니다.
GAZE 입력
현재로써는 gaze 입력을 UMG 3D 위젯으로 손쉽게 보내는 방법은 없습니다. 여러분은 3D 위젯을 확장하고 마우스 입력을 합성하거나 씬 위 여러 오브젝트들로부터 트레이스를 확인하는 부자연스러운 설정을 만들어서 효과적으로 UMG를 완전히 회피해야 합니다.
UMG를 텍스쳐에 올리고 마우스 이벤트로부터 UV 스페이스로의 라인트레이스를 이용하여 gaze 입력을 받아내는 방법은 VR용도로 사용하기에 굉장히 좋습니다. 저희는 이 기능 추가 요청을 에픽게임즈에 하였습니다.
마티네 중심 플레이어 애니메이션
마티네에서의 스켈레탈 메쉬 애니메이션은 ASkeletalMeshActor와 여기에서 파생된 클래스에서만 가능합니다. 저희는 게임 속 우주인이 첫 시퀀스와 마지막 시퀀스에서 마티네로 애니메이션을 하기를 원했는데, 왜냐하면 툴이 가지고 있는 유연성 때문이었습니다. 하지만 ACharacter에서 파생된 액터들은 마티네에서 직접 조정하는 스켈레탈 메시 애니메이션을 할 수 없었습니다.
FPS 게임에서 시네마틱 씬을 재생할 때는 플레이어 캐릭터가 표시되지 않도록 특별히 제작한 장면으로 페이드인 시킵니다. 하지만 VR에서는 이렇듯 몰입을 방해하는 페이드인을 만들지 않습니다. 저희는 동일한 캐릭터를 재사용하여 마티네 시퀀스를 재생하고 플레이어 컨트롤도 가능하게 하고 싶었습니다. 저희는 시퀀스의 막바지에 캐릭터가 자연스럽게 플레이어 컨트롤이 가능한 캐릭터로 바뀌도록 하였습니다.
저희는 EV에서 마티네에 사용되는 더미 스켈레탈 메시를 사용했고 실제 캐릭터를 이 메시에 붙였습니다(숨겨져 있음). 시퀀스의 막바지에 저희는 더미를 숨기고 실제 캐릭터를 보여주었습니다. 두 메시를 완전히 동일하게 일치시키는 것이 불가능했기 때문에 전환시에 약간의 어긋남이 느껴지실 것입니다.
포스팅을 마치며
VR 개발에서, 특히 모바일의 경우 개발자, 디자이너는 완전히 새로운 도전에 직면합니다. 일반적으로 널리 사용되는 패턴과 해결 방안이 통하지 않았고 다른 방법을 생각해 내야 했습니다. 이러한 수 많은 이슈들이 해결되어야 합니다. 특히 사용자와의 상호작용 측면이 그렇습니다.
모바일 VR은 장치가 갖는 제약 때문에 개발이 특히 어렵습니다. 고정 프레임을 얻으면서도 최고의 비주얼을 만들려면 퍼포먼스 조정시 창의력이 풍부해야 합니다.
언리얼 엔진은 저희의 비전을 굳건한 게임으로 만들어나갈 수 있도록 도와주었습니다. 몇가지 문제들을 달성해 나가는 것은 여전히 어렵지만 VR(특히 모바일에서) 에 대해 생각해보면 아직 초기이기 때문에 이런 부분들은 납득할 만 합니다. 언리얼 엔진 4에서 최근 VR과 모바일 기능들을 개발해 주어 감사드립니다. 저희는 새로운 프로젝트 작업을 기대하고 있습니다.
Escape Velocity 또는 언리얼 엔진 4 속의 일반적인 VR에 관해 질문이 있으신 경우 언리얼 엔진 포럼에서 자유롭게 문의해 주세요.