In a virtual reality app, you are creating a three-dimensional space with a bunch of objects. The user's viewpoint, or camera, is also located in this space. With the help of the Cardboard SDK, the scene is rendered twice, once for the left and right eye, to create the side-by-side stereoscopic views. The second and equally important feature translates the sensor data into a head look direction, tracking the real-life user's head. The pixels are drawn on the screen, or rendered, using the OpenGL ES library, which talks to the hardware graphics processor (GPU) on your device.

We're going to organize the graphics rendering code into separate Java classes, which we'll be able to extract into a reusable graphics engine library. We'll call this library RenderBox.

As you'll see, the RenderBox class implements the CardboardView.StereoRender interface. But it's more than that. Virtual reality needs 3D graphics rendering, and to do all this in low-level OpenGL ES calls (and other supporting APIs) can be tedious, to say the least, especially as your application grows. Furthermore, these APIs require you to think like a semiconductor chip! Buffers, shaders, and matrix math, oh my! I mean seriously, who wants to think like that all the time? I'd rather think like a 3D artist and VR developer.

There are many distinct pieces to track and manage, and they can get complicated. As software developers, it's our role to identify common patterns and implement layers of abstraction, which serve to reduce this complexity, avoid duplicated code, and express the program as objects (software classes) closer to the problem domain. In our case, this domain makes 3D scenes that can be rendered on Cardboard VR devices.

RenderBox starts to abstract away details into a nice clean layer of code. It is designed to take care of OpenGL calls and complex arithmetic, while still letting us set up our app-specific code the way we want. It also creates a common pattern known as the entity component pattern (https://en.wikipedia.org/wiki/Entity_component_system) for new materials and component types if our projects demand any special cases. Here's an illustration of the major classes in our library:

The RenderBox class implements CardboardView.StereoRenderer, relieving that responsibility from the app's MainActivity class. As we'll see, MainActivity communicates with RenderBox through the IRenderBox interface (with the setup, preDraw, and postDraw hooks) so that MainActivity implements IRenderBox.

Let's consider the kinds of Component that can participate in a 3D VR scene:

Every object in our scene has an X, Y, and Z location in space, a rotation, and three scale dimensions. These properties are defined by the Transform class. Transforms can be arranged in a hierarchy, letting you build more complex objects that are assembled from simpler ones.

Each Transform class can be associated with one or more Component classes. Different kinds of components (for example, Camera, Light, and RenderObject) extend the Component class. A component should not exist without being attached to a Transform class but the reverse (a transform with no components) is perfectly fine.

Internally, RenderBox maintains a list of RenderObjects. These are the geometric models in the scene. Types of RenderObjects include Cube and Sphere, for example. These objects are associated with a Material, which defines their color, texture, and/or shading properties. Materials, in turn, reference, compile, and execute low-level shader programs. Maintaining a flat list of components to render each frame is more efficient than traversing the transform hierarchy every frame. It is a perfect example of why we use the entity component pattern.

Other things in the RenderBox package include a Time class used to implement animations, and a library of Math functions used for vector and matrix operations.

Now, let's start putting this together.

What's the game plan? The end goal is to create our RenderBox graphics engine library. It will be handy to maintain it in its own project (and repository if you're using source control, such as Git), so it can be improved and maintained independently. However, to kick this off, we need a simple app to build it, show you how to use it, and verify (if not test) that it is working properly. This will be called RenderBoxDemo. At the end of the chapter, we will extract the RenderBox code into an Android library module and then export it.