AR/VR 입문서

이 튜토리얼은 Godot 게임 엔진에서 AR과 VR의 세계로 가도록 도와주는 발판이 될 것입니다.

Godot 3부터 AR/VR Server라고 하는 새로운 아키텍처가 도입됬습니다. 이 아키텍처를 기반으로 하여, 특정 구현을 인터페이스로 이용할 수 있게 되었습니다. 대부분은 GDNative로 만들어진 플러그인입니다. 이 튜토리얼은 순수히 핵심 아키텍처에 의해 추상화된 핵심 요소에 초점을 둘 것입니다. 이 아키텍처는 다양한 인터페이스로 배포되면서 모든 VR 경험을 만들기에 충분한 기능을 갖고 있습니다. 하지만 각 플랫폼은 추상화하기에 불가능한 독특한 기능을 갖고 있습니다. 그런 기능은 입문서의 영역을 벗어나는 것이므로 관련 인터페이스에서 서술하겠습니다.

AR/VR 서버

Godot를 실행하면, 사용 가능한 각 인터페이스는 AR/VR 서버에 알려집니다. GDNative 인터페이스는 싱글톤으로 설정됩니다; 인터페이스가 프로젝트의 GDNative 싱글톤 목록에 추가되는 만큼, 서버로 알려질 것입니다.

이용 가능한 인터페이스 목록을 반환하기 위해선 함수 get_interfaces()를 사용할 수 있습니다, 하지만 이 튜토리얼에서, 예제를 위해 네이티브 모바일 VR 인터페이스를 사용하겠습니다. 이 인터페이스는 폰에서 3DOF를 사용해 입체 이미지를 화면에 출력하도록 하는 간단한 구현입니다. 또한 Godot 코어로 데스크톱에서 화면을 출력할 수 있으므로, 프로토타입을 만들거나 이것과 같은 튜토리얼을 하기에 이상적입니다.

인터페이스를 활성화하기 위해, 다음 코드를 실행합니다:

var arvr_interface = ARVRServer.find_interface("Native mobile")
if arvr_interface and arvr_interface.initialize():
    get_viewport().arvr = true
var arvrInterface = ARVRServer.FindInterface("Native mobile");
if (arvrInterface != null && arvrInterface.Initialize())
{
    GetViewport().Arvr = true;
}

이 코드는 우리가 사용하고자 하는 인터페이스를 찾아 초기화합니다, 그리고 완료되면 메인 뷰포트를 인터페이스에 제한합니다. 마지막 단계에서는 뷰포트에서 인터페이스를 제어하여 뷰포트에 입체 렌더링과 같은 것을 자동으로 활성화하도록 할 것입니다.

모바일 VR 인터페이스나, 화면에 주요 입력이 보여지는 인터페이스의 경우, 메인 뷰포트는 arvr이 true로 설정되어 있어야 합니다. 하지만 외부에 부착된 기기에 렌더링을 하는 인터페이스에는, 보조 뷰포트를 사용할 수 있습니다. 후자의 경우, 기기에서 완전히 처리된 입체 영상을 출력하지만, 화면에 표시하는 뷰포트는 왜곡되지 않은 왼쪽 눈 장면을 보여줄 것입니다.

마지막으로, 인터페이스를 한번만 초기화해야 합니다; 씬을 바꾸고 인터페이스를 다시 초기화하면 많은 부담이 발생합니다. 헤드셋을 일시적으로 끄려면, 뷰포트를 비활성화하거나 뷰포트에서 arvr을 false로 설정하세요.

새로운 AR/VR 노드

Godot에서 AR과 VR을 지원하기 위해 세가지 새로운 노드 타입이 추가되었고 AR만을 위한 추가적인 노드 타입 한 가지가 추가되었습니다. 다음과 같습니다:

  • ARVROrigin - 월드에서 원점
  • ARVRCamera - 위치 추적이 가능한 카메라의 특수 하위 클래스
  • ARVRController - 컨트롤러의 위치를 추적하는 새로운 Spatial 클래스
  • ARVRAnchor - 실제 세상 위치를 가상 세계에 매핑하는 AR 구현을 위한 기준점

AR/VR을 위해선 앞의 두 개가 씬에 있어야 하고 이 튜토리얼 역시 이 둘에 초점을 두고 있습니다.

ARVROrigin은 중요한 노드로, 씬 어딘가에 반드시 있어야 합니다. 이 노드는 실제 세상의 중심을 가상 세상의 한 위치에 매핑합니다. 다른 모든 것들은 이 점으로 위치를 추적합니다. 이 점이 하나의 구현에서 다른 구현으로는 다르지만, 이 노드가 작동하는 방식을 이해하기 위한 최선의 예는 방 규모 장소를 살펴보는 것입니다. 기본적으로 플레이어를 중심으로 점이 조정되지만, 원점은 당신이 있는 방의 중심에 있게 됩니다. 물리적으로 방을 돌어다니면 HMD의 위치는 중심점에 따라 추적하고 이는 가상 세계에 반영됩니다.

To keep things simple, when you physically move around your room, the ARVR Origin point stays where it is, the position of the camera and controllers will be adjusted according to your movements. When you move through the virtual world, either through controller input or when you implement a teleport system, it is the position of the origin point which you will have to adjust.

ARVRCamera is the second node that must always be a part of your scene and it must always be a child node of your origin node. It is a subclass of Godot's normal camera. However, its position is automatically updated each frame based on the physical orientation and position of the HMD. Also due to the precision required for rendering to an HMD or rendering an AR overlay over a real world camera, most of the standard camera properties are ignored. The only properties of the camera that are used are the near and far plane settings. The FOV, aspect ratio and projection mode are all ignored.

Note that, for our native mobile VR implementation, there is no positional tracking, only the orientation of the phone and by extension, the HMD is tracked. This implementation artificially places the camera at a height (Y) of 1.85.

Conclusion: your minimum setup in your scene to make AR or VR work should look like this:

../../_images/minimum_setup.png

And that's all you need to get started. Obviously, you need to add something more into your scene, so there is something to see, but after that, you can export the game to your phone of choice, pop it into a viewer and away you go.

Other things to consider

There are a few other subjects that we need to briefly touch upon in this primer that are important to know.

The first are our units. In normal 3D games, you don't have to think a lot about units. As long as everything is at the same scale, a box sized 1 unit by 1 unit by 1 unit can be any size from a cube you can hold in your hand to something the size of a building. In AR and VR, this changes because things in your virtual world are mapped to things in the real world. If you step 1 meter forward in the real world, but you only move 1 cm forward in your virtual world, you have a problem. The same with the position of your controllers; if they don't appear in the right relative space, it breaks the immersion for the player. Most VR platforms, including our AR/VR Server, assume that 1 unit = 1 meter. The AR/VR server, however, has a property that, for convenience, is also exposed on the ARVROrigin node called world scale. For instance, setting this to a value of 10 changes our coordinate system so 10 units = 1 meter.

Performance is another thing that needs to be carefully considered. Especially VR taxes your game a lot more than most people realise. For mobile VR, you have to be extra careful here, but even for desktop games, there are three factors that make life extra difficult:

  • You are rendering stereoscopic, two for the price of one. While not exactly doubling the work load and with things in the pipeline such as supporting the new MultiView OpenGL extension in mind, there still is an extra workload in rendering images for both eyes
  • A normal game will run acceptably on 30fps and ideally manages 60fps. That gives you a big range to play with between lower end and higher end hardware. For any HMD application of AR or VR, however, 60fps is the absolute minimum and you should target your games to run at a stable 90fps to ensure your users don't get motion sickness right off the bat.
  • The high FOV and related lens distortion effect require many VR experiences to render at double the resolution. Yes a VIVE may only have a resolution of 1080x1200 per eye, we're rendering each eye at 2160x2400 as a result. This is less of an issue for most AR applications.

All in all, the workload your GPU has in comparison with a normal 3D game is a fair amount higher. While things are in the pipeline to improve this, such as MultiView and foveated rendering, these aren't supported on all devices. This is why you see many VR games using a more art style and if you pay close attention to those VR games that go for realism, you'll probably notice they're a bit more conservative on the effects or use some good old optical trickery.