Now that we have made a conscious decision to work in VR, today I finally had the chance to play around with VR in Unity.

Today we’re going to explore setting up and using Google’s VR SDK. You might think that setting up VR would be an extremely complex process, but after going through the process, I can say that starting out is simpler than you would think!

Here’s our objective for today:

Let’s get started!

Step 1: Setting up Google Cardboard on Unity

For today, I’ll be going through Google’s documentation for setting up VR on Unity.

The nice thing about the Google VR SDK is that we can re-use most of the prefabs and scripts that are used with Google Cardboard and use them with Google Daydream. That’s 2 different platforms for the price of one.

Today I’ll be following Google’s official documentation on getting started on Unity.

Step 1.1: Install Unity

At this point, I’m going to assume that we all have an older version of Unity (5.6+).

Step 1.2: Adding the Google VR SDK

After we have Unity set up correctly with Android Build Support, we need to get Google’s VR assets.

We’re looking to download the .unitypackage.

After we have the package downloaded, it’s time to add it to a Unity project.

For our case, we’re going to create a new project to play around with.

Step 1.3: Configuring Unity to Run VR

Now we have imported everything we need, the last thing to do is to change some of our settings in Unity so we can run our game.

Change Our Build Setting to Build and Run Android Applications

The first thing we need to do is get Unity to run our game project on an Android platform.

Change Our Player Settings to Support VR

The next thing we need to do is to change our Player Settings so that we can support the specific VR SDK that we want. In our case, it’s going to be Google Cardboard.

Once we have everything installed, we can finally get started on taking a first look at working with VR!

Step 2: Looking Through the Unity Tutorial

Now that everything is configured, we can officially start looking through Google’s SDK Basics.

I went through the SDK basics while also going through the GVRDemo scene.

Google provides prefabs and scripts that will take care of the VR features for you. These are all located in Assets > GooglveVR > Prefab and Scripts. Here’s a breakdown of what they and the script attached to them do:

There are quite a couple of other prefabs and scripts, but on the high level, these are the basics we’ll need to make a VR game.

Let’s see this in action with the GvrDemo scene!

Step 2.1: Looking at the demo scene

When we open up GvrDemo, here’s what we see:

I suggest that you explore around the scene and see the objects in our hierarchy, but on the high-level summary, here’s what we have in our hierarchy that’s relevant to just the Google Cardboard (because it has Daydream assets too)

The main point of this game is to click on the cube that appears in the game. When we click on the cube, it’ll be randomly moved somewhere else in the game.

The interesting part of all of this is how we can trigger the code with our Gaze.

Let’s look at the Cube and Unity’s Event Trigger system.

The Event Trigger System is a way for Unity to recognize any action taken on the game object that the Event Trigger is registered onto.

An action is something like:

In our example, OnPointerClick will be triggered whenever we click on an object that has the Event Trigger attached to it.

Here’s the teleport script:

// Copyright 2014 Google Inc. All rights reserved.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

using UnityEngine;

using System.Collections;

[RequireComponent(typeof(Collider))]
public class Teleport : MonoBehaviour {
  private Vector3 startingPosition;

  public Material inactiveMaterial;
  public Material gazedAtMaterial;

  void Start() {
    startingPosition = transform.localPosition;
    SetGazedAt(false);
  }

  public void SetGazedAt(bool gazedAt) {
    if (inactiveMaterial != null && gazedAtMaterial != null) {
      GetComponent<Renderer>().material = gazedAt ? gazedAtMaterial : inactiveMaterial;
      return;
    }
    GetComponent<Renderer>().material.color = gazedAt ? Color.green : Color.red;
  }

  public void Reset() {
    transform.localPosition = startingPosition;
  }

  public void Recenter() {
#if !UNITY_EDITOR
    GvrCardboardHelpers.Recenter();
#else
    GvrEditorEmulator emulator = FindObjectOfType<GvrEditorEmulator>();
    if (emulator == null) {
      return;
    }
    emulator.Recenter();
#endif  // !UNITY_EDITOR
  }

  public void TeleportRandomly() {
    Vector3 direction = Random.onUnitSphere;
    direction.y = Mathf.Clamp(direction.y, 0.5f, 1f);
    float distance = 2 * Random.value + 1.5f;
    transform.localPosition = direction * distance;
  }
}

We can ignore what the code does, but the important thing that I want to bring attention to are the public functions that are available:

Where are these called?

Well, if you look back at our Event Trigger that’s created in Cube, we set 3 event types:

Then whenever any of these events occur, we call our public function.

In this example, when we look at our cube, we’ll trigger the Pointer Enter event and call the SetGazedAt() function with the variable gazedAt to be true.

When we look away, we trigger the Pointer Exit event and call the SetGazedAt() function with gazedAt to be false.

Finally, if we were to click on the cube, we would trigger the Pointer Click event and call TeleportRandomly() to move our cube to a new location.

Conclusion

It’s surprising how un-complex this whole process is so far! I’m sure there are a lot more things to consider once we dive deeper into Unity, however for today, I think the progress we have made is sufficient.

Tomorrow, we’re going to look at how we can get the demo app to run on a phone that supports a Google Cardboard (which I assume at this point is 99% of you guys here)

Day 33 | 100 Days of VR | Day 35

Home