Unity3D Tutorial #4

@Brandon

Note: This tutorial works best for SteamVR version 1.2.3, and no longer works for Steam 2.0 onward.

For the newer tutorial, go to Unity Tutorial #4.1

Requirements

• Installation of Unity

• Installation of SteamVR

Now you must be thinking, "my scene looks whiter than a flock of doves eating rice-covered marshmallows in the middle of a blizzard," and you are absolutely right! Let's change that, shall we?

Create a new folder in "Assets" and name it "Materials" (refer to the "Save Scene" section for a refresher). Navigate to that folder and create a new Material (Create>Material). Let's name it "Ball," since we will use this to make our ball look extra sleek and schwifty. In the material's inspector, we can change all sorts of attributes relating to how something looks. There should be a dropper in the upper area of the inspector. Clicking that will allow us to pick a color. I picked red, but I encourage you to go as wild as you can when it comes to picking ball colors. In the inspector, there are also sliders that can make make the material look more shiny/metallic, or look smoother.

Once you are satisfied with how the material looks, drag the material from the Materials folder to the the desired object in the hierarchy menu (in this case, it would be ball). The object should now have the texture and color in the scene view. 

Let's make some materials for the rest of the objects in the scene to give the project some extra personality!

Now its time to code! Navigate to the Assets folder, and make a new folder called "Scripts". Now enter the folder and create a new C# Script (Create>C# Script), and name it "ControllerGrab". Double click the script, and it should open up an editor for C#.

The script default layout should look something like this:

using System.Collections;

using System.Collections.Generic;

using UnityEngine;

public class ControllerGrab : MonoBehaviour {

  // Use this for initialization

 void Start () {

 }

 // Update is called once per frame

 void Update () {

 }

}    

The "using" keyword works similar to the way the "package" keyword works in Java. It gives a class file access to all classes under the System.Collections namespace, and the System.Collections.Generic namespace. These statements are auto-generated, and should not need to be changed.

Next is the line  "public class ControllerGrab : MonoBehaviour {"

Unity uses the same keywords for levels of access as Java (Ex: public, private, protected, etc.). The colon represents inheritance, and can be used in place of both the "extends" and "implements" keywords. Multiple inheritance would looks something like this: "class ChildClass : ParentClass, Interface1, Interface2, Interface3". Lastly, MonoBehavior is a class that all Unity scripts must extend, we will go into a little more depth about the added functionality of this class in a bit.

Let's start out by adding the variables that we will be using in our project. In the line after the class declaration line, type the following variables and method:

private SteamVR_TrackedObject trackObj;

private GameObject collidingObject;

private GameObject held;

private SteamVR_Controller.Device Controller

{

    get { return SteamVR_Controller.Input((int)trackObj.index); }

}

void Awake()

{

    trackObj = GetComponent<SteamVR_TrackedObject>();

}

So many weird classes and objects right? What's a SteamVR_TrackedObject? Whats  GameObject? What's the weird variable-method looking thingy that even the Java programmers of our class don't recognize? Let's break this down to what actually happens when the code runs.

1. When the Awake() method is called, we store a reference to the controller in trackObj, which is a SteamVR_TrackedObject. "Tracked Objects" generally refers to the headset and controllers, anything that is "tracked" in the real world and translated into an input for the virtual world.

2. CollidingObject will be used to store any interactable object that the controller box collider is currently touching, or "colliding" with

3. held will be used to store any object that is currently being held when we pick up an object with the controller.

4. Controller is a Device object. Since the Device class is declared in the SteamVR_Controller class, we must access the type by calling SteamVR_Controller.Device. In C#, variables can be declared with the following syntax: private Integer foo { get; set; }

By following this syntax, this means that we are declaring "getter" and "setter" methods without having to type out private Integer getFoo() {return foo;}Which is something we would have to do in Java. Then we can just type in "foo" in place of the function "getFoo()"

So for the variable Controller, we are just declaring the getter function, and saying that we want to return a SteamVR_Controller.Device type related to a certain input. In other words, this getter allows us to distinguish when different buttons are pressed on a controller.

On a separate note, before we continue, a little on functions such as Start(), Awake(), Update(), etc. MonoBehavior has a couple specific built in functions that already have assigned significance to Unity. Awake(), for example, executes only once  as soon as the application starts up, before any other function is executed. After Awake methods are called, Start() is called. Any code written in the Update method body will be executed every frame of the program.

Finally, lets add in the grab functionality itself now. Add the following code immediately after the previous section code. Let's start out with the AddFixedJoint() function. Basically we are creating a FixedJoint game object, which will connect our grabbing controller rigidbody with the object we are grabbing.

The breakforce and breakTorque numbers are somewhat arbitrary, but we want to make the joints relatively strong, so that our grip on objects doesn't unexpectedly break.

private FixedJoint AddFixedJoint()

    {

        FixedJoint fj = gameObject.AddComponent<FixedJoint>();

        fj.breakForce = 65536;

        fj.breakTorque = 65536;

        return fj;

    }

So what's happening in the grab function? We want to take the object we're touching and we no longer want to simply "collide" with the object, we want to physically hold it. So we now store the colliding object in "held", and assign the collidingObject variable to null. We then connect the controller rigidbody to the held object's rigidbody with a FixedJoint object.

    private void Grab()

    {

        held = collidingObject;

        collidingObject = null;

        var joint = AddFixedJoint();

        joint.connectedBody = held.GetComponent<Rigidbody>();

    }

If we can pick something up, we should also be able to drop it right? First, we check to see if a FixedJoint exists. This means that we are, in fact, grabbing something. The next two lines of code serve to erase the FixedJoin from existence.

Then, we say, maintain the controller's velocity and angular velocity before releasing the object. This allows us throw our ball that we made way back when, instead of the ball just dropping straight to the ground.

Lastly, set the held variable to null to show that we no longer are holding the object.

    private void Drop()

    {

        if (GetComponent<FixedJoint>())

        {

            GetComponent<FixedJoint>().connectedBody = null;

            Destroy(GetComponent<FixedJoint>());

            held.GetComponent<Rigidbody>().velocity = Controller.velocity;

            held.GetComponent<Rigidbody>().angularVelocity = Controller.angularVelocity;

        }

        held = null;

    }

Now lets put our grab and drop functions into practice. Add the following code to the Update() function. Since we made our Grab and Drop functions, this makes our Update function look so much cleaner than it could have been. To summarize, whats happening is; If we press the trigger on a controller, and the controller is colliding with an interactable object, then grab the object. Then, if we lift the trigger on the controller, if the controller was holding an object, then execute the drop function. By putting this in the Update, we are telling Unity to execute this code every frame. In other words, on a Vive, that would mean this function checks for grabbing and dropping 90 times every second.

    // Update is called once per frame

    void Update()

    {

        if (Controller.GetHairTriggerDown())

        {

            if (collidingObject)

            {

                Grab();

            }

        }

        if (Controller.GetHairTriggerUp())

        {

            if (held)

            {

                Drop();

            }

        }

    }

Save the file, and build it (Should be Ctrl/Cmd + Shift + B). Building will allow us to check to see if maybe we made any sort of mistakes in our code. If the build succeeds and there are no errors, we should be good to go back to Unity. As soon as we save the code, it should also be saved in the Unity Project itself.

Let's add another simple script that will make the program a lot easier during runtime. Create a new script and call it BallController.

public class BallController : MonoBehaviour {

    private Vector3 position;

  // Use this for initialization

 void Start () {

        position = transform.position;

 }

 // Update is called once per frame

 void Update () {

  if (transform.position.y < 0)

        {

            var rb = GetComponent<Rigidbody>();

            transform.position = position;

            rb.velocity = Vector3.zero;

            rb.angularVelocity = Vector3.zero;

        }

 }

}

Since our floor is floating in the middle of nowhere, if we throw a ball and it falls off the edge, then we'll have nothing to throw anymore. This script here basically just checks to see if the ball is below the floor. If it is, then return it to its original position.

The notable syntax here includes:

• The Vector3 object: Vector3 is a 3-D vector that stores an x, y, and z. This is useful for storing position and movement in a 3-D scene.

• transform stores everything in the "Transform" field that we saw earlier in the object inspector. Things like scale, position, etc.

• Lastly, something cool about Unity is that there are a lot of shortcuts that simplify the code we have to write. An example of this would be Vector3.zero. Normally, we would have to write something to the effect of "new Vector3(0, 0, 0), but instead, we can simplify a little to something a little more intuitive.

Now all we need to do is take the scripts, and attach them to their related objects. To do this, all we need to do is select both controllers and drag the "ControllerGrab" script into their inspectors, and drag "BallController" to the Ball's inspector.

If we still have a little more time (like 5 minutes), go to the next section, otherwise, please skip the next section.

Having only one ball and once target to knock over seems kind of boring, doesn't it? Let's add some more of each!

Create a new folder in the assets folder called "Prefabs". Now drag "Target" and "Ball" from the hierarchy into the Prefabs folder. Delete them from the Hierarchy Menu.

Prefabs are basically blueprints for objects we make. If we make a Prefab, then we can make multiple copies of that object easily, and if we change one Prefab object, we have the option to change all others made from the same prefab in the same way.

Create two new Game Objects in the Hierarchy Menu (Create>Create Empty) (Be sure that their Transform properties are zero'ed out). Name one "Balls", and the other "Targets". Now drag the ball prefab to "Balls" and the "Target" prefab to Targets (This make the hierarchy menu a little more organized). Now right click the Ball (or Target), and select "duplicate". Now if we select the duplicate in the hierarchy menu and focus on it with "f", we should notice a colored cube with arrows. If we click the bottom face with the cube, you'll notice that we can drag the object around easily without having to manipulate any numbers. This way, we can duplicate a bunch more targets and balls to throw at them.

Notes on tutorial execution:

• It should be noted that all the participants except for one noted experience with Java, which is important for this tutorial, as many concepts were explained in the write-up in terms of Java.

• The tutorial itself ended up taking the entire class period (1 hour 20 minutes), without having any time to actually test the program itself out, or to complete one of the optional last sections.

• Having the transcribed version was useful, since some classmates ended up farther along than others, and could continue along

• Creating a Unity account and downloading the SteamVR plugin such that it could be imported took up some time

• Not all students had Visual Studio to be used in conjunction with Unity - participants, especially those using MacBooks, had to use Unity Editor, which made coding and building a little more difficult.

• A major problem that had been unaccounted for was the possibility of different versions - many of the students participating were unable to run their program due to differing versions of unity

• Download time- since most of the laptops could not support an Oculus Rift or Vive, all of the projects had to be sent to one or two computers - ended up taking a long time to download all the projects off of google drive.

• Feedback was generally positive, especially in regards to clarity