Unity (http://unity3d.com/) is a popular full-featured 3D game engine, which supports building your games on a wide gamut of platforms, from PlayStation and XBox, to Windows and Mac (and Linux!), to Android and iOS.

Unity consists of many separate tools integrated into a powerful engine under a unified visual editor. There are tools for graphics, physics, scripting, networking, audio, animations, UI, and much more. It includes advanced computer graphics rendering, shading, textures, particles, and lighting with all kinds of options for optimizing performance and fine tuning the quality of your graphics for both 2D and 3D. If that's not enough, Unity hosts a huge Asset Store teeming with models, scripts, tools, and other assets created by its large community of developers.

The Cardboard SDK for Unity provides a plugin package that you can import into the Unity Editor, containing prefabs (premade objects), C# scripts, and other assets. The package gives you what you need in order to add a stereo camera to your virtual 3D scene and build your projects to run as Cardboard apps on Android (and iOS). Unity is planning on integrating the Cardboard SDK directly into the engine, which means that adding support for Cardboard will be possible by just checking a box in the build settings.

So, why not just use Unity for Cardboard development? Good question. It depends on what you're trying to do. Certainly, if you need all the power and features of Unity for your project, it's the way to go.

But at what cost? With great power comes great responsibility (says Uncle Ben Parker). It is quick to learn but takes a lifetime to master (says the Go Master). Seriously though, Unity is a powerful engine that may be overkill for many applications. To take full advantage, you may require additional expertise in modeling, animation, level design, graphics, and game mechanics.

Cardboard applications built with Unity are bulky. An empty Unity scene build for Android generates an .apk file that is a minimum of 23 megabytes. In contrast, the simple native Cardboard application, .apk, that we build in Chapter 2, The Skeleton Cardboard Project, is under one megabyte.

Along with this large app size comes a long loading time, possibly more than several seconds. It impacts the memory usage and battery use. Unless you've paid for a Unity Android license, your app always starts with the Made With Unity splash screen. These may not be acceptable constraints for you.

In general, the closer you are to the metal, the better performance you'll eke out of your application. When you write directly for Android, you have direct access to the features of the device, more control over memory and other resources, and more opportunities for customization and optimization. This is why native mobile apps tend to trump mobile web apps.

Lastly, one of the best reasons to develop with native Android and Java may be the simplest. You're anxious to build something now! If you're already an Android developer, then just use what you already know and love! Take the straightest path from here to there.

If you're familiar with Android development, then Cardboard development will come naturally. Using the Cardboard SDK for Android, you can program in Java, using the Android Studio IDE (integrated development environment), which is based on InteliJ IDEA by Jet Brains.

As we'll see throughout this book, your Cardboard Android app is like other Android apps, including a manifest, resources, and Java code. As with any Android app, you will implement a MainActivity class, but yours will extend CardboardActivity and implement CardboardView.StereoRenderer. Your app will utilize OpenGL ES 2.0 graphics, shaders, and 3D matrix math. It will be responsible for updating the display on each frame, that is, rerendering your 3D scene based on the direction the user is looking at that particular slice in time. It is particularly important in VR, but also in any 3D graphics context, to render a new frame as quickly as the display allows, usually at 60 FPS. Your app will handle the user input via the Cardboard trigger and/or gaze-based control. We'll go into the details of all these topics in the upcoming chapters.

That's what your app needs to do. However, there are still more nitty gritty details that must be handled to make VR work. As noted in the Google Cardboard SDK guide (https://developers.google.com/cardboard/android/), the SDK simplifies many of these common VR development tasks, including the following:

Functions are provided in the SDK to handle these tasks for you.

Building and deploying your applications for development, debugging, profiling, and eventually publishing on Google Play also follow the same Android workflows you may be familiar with already. That's cool.

Of course, there's more to building an app than simply following an example. We'll take a look at techniques such as using data-driven geometric models, abstracting shaders and OpenGL ES API calls, and building user interface elements with gaze-based selection. On top of all this, there are important suggested best practices for making your VR experiences work and avoiding common mistakes.