Google Daydream to Samsung Gear VR: A Story of Virtual Reality Transformation

Hi, I’m Dominik, and I would like to share with you some details about our first virtual reality project. This is cutting-edge technology which is leading to game creation for VR-only games as well as to transformation from mobile platforms to VR platforms.

INTRODUCTION

The virtual reality boom began when cardboard first appeared. The community noticed that mobile devices are powerful enough to handle stereoscopic rendering, so many manufacturers started producing their own headsets with better lenses or additional controllers compared to the homemade cardboards. The first product of that nature was the Samsung Gear VR, which launched a year before Google released their own headset, Daydream. Both were designed for the latest high-end devices, which made it possible to achieve an acceptable quality for mobile games. We started our adventure with VR with these devices.

VIRTUAL REALITY CASE STUDY

Our goal was to port a mobile game which was released at the beginning of 2014 to our target platform, Daydream. However, after struggling with the underdeveloped and young SDK, we decided to switch to Samsung Gear VR. Changing platforms in VR is quite easy and straightforward. In fact, it’s almost possible to change platforms from week to week. A major issue with porting old games is the environment. To develop virtual reality games, you must use the latest available tools. Our game was created in Unity 4.3, so we encountered a few problems when we upgraded the project to Unity 5.4. Daydream also required us to use the beta version of the engine because native support would not be added until the Unity 5.6 release.

Apart from the adaptation of the user interface to the new controls, the two most important things in VR games are high performance (constant 60 fps) and lack of motion sickness, which are the two points I would like to focus on. To achieve both, we had to do several things:

• Enable multithreaded rendering – This single option can increase performance even by 10 fps. However, it can cause some graphical artifacts during switching the cameras. To avoid this, you must ensure that there are no races and at least one camera is always active (enable the second camera first, then disable previous – sometimes some delay may be needed).
• Decrease number of draw calls – This is important in each game, but especially in VR. We used special tools like MeshBaker (to batch static elements) and NGUI (to batch UI in one draw call).
• Remove overdraw effect –  On mobile devices, the overdraw effect is more expensive than on PC because devices can only display a restricted number of pixels per frame. In this case, it is good to use occlusion areas or manually disable as many objects as possible if you know that they won’t be visible.
• Adjust quality settings – Here it’s very useful to know about the capabilities of your target devices so you can marginally improve performance without a visible decline in the quality. For example, many high-end devices have hardware support for anti-aliasing (MSAAx2 and MSAAx4). Correct texture compression is also important (eg. ECT2 when using GLES 3.0).
• Adjust time settings – To provide a constant number of frames per second, it is useful to change the Fixed Timestep and Maximum Allowed Timestep to 0.01666 s. It will force a specific amount of frames, but you should use it only if you are close to 60 fps. Otherwise, the game will work like it’s in slow motion.
• Remove many cameras – This is worth doing for two reasons. The first is each camera adds its own overhead (culling is done separately for each camera) and increases the number of overdrawn pixels, which decreases performance. The second reason is motion sickness. If various elements are moving differently during rotation of the head (for example UI layer and 3D elements), the user can quickly have symptoms of motion sickness.
• Simplify camera movement and animations – The camera must move as naturally as possible to avoid symptoms of motion sickness. The most unpleasant are sudden stops/starts and zoom in/out effects. It is better to teleport player instead of moving him. Additionally, the developer can’t change the camera’s Field of View; it must be the same FoV as the headset lenses.
• Add design constraints – If you finally reach 60 fps, you have to maintain it during the whole game. In our case, we had to limit the number of elements affected by the physics that the user can create so that the game was possible to finish, but the player hasn’t been able to harm him/herself.

OTHER SOLUTIONS

I specifically mentioned two devices which we used as target devices for this project: Samsung Gear VR and Google Daydream. During our porting and development processes, we were able to work with many other VR sets and gadgets. Many manufacturers are working on extension kits for their VR sets to add additional controllers and cameras which will allow the user to walk through virtual space. This could soon be a cheaper and more mobile alternative for solutions like Oculus Rift or HTC Vive. Examples of such solutions are:

• Ximmerse Outside-in kit – Provides two comfortable controllers and camera which tracks a player’s position and position of the head (http://www.ximmerse.com/goods-5.html).
• VicoVR – full body controller for mobile virtual reality (http://vicovr.com/).

CONCLUSION

Virtual Reality development is demanding regarding performance but gives a lot of new possibilities. Additionally, vendors of the game engines like Unity or Unreal Engine 4 strive to create their own virtual reality applications to be very similar to normal apps. Thanks to this, many solutions work out of the box, and the developer just has to remember some limitations and good practices. I think this project will open Playsoft up to greater opportunities to VR projects in the future.

Thanks for reading! I hope you’ve enjoyed!