Unity Networking

In this article I will introduce the networking functionality included in Unity. I will build a simple authorative server solution, introduce the NetworkView component, and show you how RPCs can be used. The screenshots are from Unity 3.5, but the solution works for Unity 4.0 as well.

If you are planning to make a multiplayer game in Unity, be it two player turn based or massive multiplayer online, you will have to implement some sort of networking solution capable of ensuring that all players share the same consistent world view. This will require the handling of problems such as:

• players playing on differing hardware platforms (cpu/memory), such as pcs and mobiles
• players with differing connection speeds
• differing network latency between players (round trip time), and differences in the variation thereof (jitter)
• lossy connections and the handling of lost data

For real time games the above problems are especially relevant and if not handled correctly will result in players experiencing “lag”.

Before diving into the networking solution that Unity offers, lets briefly look at the history of multiplayer games and their networking solutions.

• Peer to Peer Lockstep

  

  Fully connected star topology

  Initially, each computer exchanged game information with each of the other computers in a star topology. The game consisted of “turns” and in each turn a computer could choose from a limited number of “moves”. Once all the computers had communicated their next move to all the other computers, each computer carried out the moves after which it was time for the next turn. Assuming that all computers started from the same initial game state, this would ensure that all games played out identically across computers. The disadvantage of this networking solution is that each computer has to wait until it has received the move from the last computer, the slowest computer thus determing the pace of the turns (and thus lag). Real Time Strategy games typically use variants of peer to peer lockstep, albeit with better handling of the lag issues.

• Authorative Server/Dumb client

  

  Star topology for client-server

  To avoid having to wait on the slowest computer, each computer now communicates with a single server. The server has the game “world” and the clients just receive a view on this world. The clients have (almost) no code, they are just dumb terminals sending input (key presses) to the server. The server then carries out the input and sends back a “picture” of the resulting world. There is no longer a problem of keeping the game world consistent across computers as there is only one world (on the server). The solution works fine for computers with the same low network latency but begins to fall apart when players have higher, differing latency. For players with a high latency, the game quickly become unplayable, the world moving in jarring jumps. Doom worked like this and if you had a high latency then most chances were you were dead before you had a chance to see what hit you.

• Client Side Prediction

  To smoothen the game experience, clients no longer wait until they receive a view back from the server. They take the players input and predict what will happen, immediately updating the world view accordingly. This requires the client to know about the game mechanics and game objects, thus the client is no longer dumb. The resulting game play is much more responsive. Of course, a problem occurs when the server world view comes back and differs from what the client predicted. The world view is then yanked back in line with the server view, often causing a noticeable glitch. This solution was first introduced in Quakeworld.

• Lag Compensation

  

  Client side prediction and lag compensation

  Reverting to the server state when a client prediction is off, actually means that the world view of the client jumps back in time. To understand this, say that it took 200 ms for the client input to reach the server, and another 200 ms for the resulting world view to come back from the server. The client has in the mean time moved forward 400 ms in time using it’s own predictions. If the client has to revert to the server view resulting from it’s input 400ms ago, it is thus jumping back in time to the time of that input. To avoid this, the client would have to first rewind time and then repredict forward in time to reach the current time again. If the game play mechanics are reasonably deterministic then corrections will occur rarely as server and client are calculating the same world view. Input from other players is basically the only cause for correction, such as the firing of a rocket point blank at the back of the head. This solution results in smooth, responsive gameplay and was first introduced in CounterStrike.

• Non authorative server

  As a side note, clients can be authorative in that they are allowed to process the players inputs and update the world themselves. In this case, the server does not own the world, it just serves to update the world according to views from it’s clients and distribute these views to the other players. While this ensures that game play is responsive, it can lead to clients having different conflicting world states requiring solutions to resolve these conflicts. It also introduces the risk of cheating clients, one player claiming to have shot another when he didn’t even have a gun, for example. This networking solutions is seldom (if ever) used for games. Sometimes a peer to peer solution, with one of the clients being both server and client, is called a non authorative server, but typically the client-server is authorative.

Reference: What every programmer needs to know about game networking

To understand the networking solution that comes with Unity, let’s start by building a server. Create a new, empty Unity project and add a script called ServerMain.js with the following code:

var listenPort = 25000;
var maxClients = 5;

function startServer() {
	Network.InitializeServer(maxClients, listenPort, false);	
}

function stopServer() {
	Network.Disconnect();
}

The Network class is the main networking class in Unity. The function InitializeServer() starts up the server, taking the maximum number of clients allowed:

var maxClients = 5;

as well as the port to listen to for incoming clients:

var listenPort = 25000;

The last parameter to the Network.InitializeServer() function (false in the code above) indicates whether or not the server should use NAT punchthrough to enable clients to connect with it. See the Network Overview for more details. For now, leave this at false.

The function Network.Disconnect() stops the server.

To complete the server side script, add the following UI code to the same script file:

function OnGUI ()
{
 	if (Network.peerType == NetworkPeerType.Disconnected) {
        GUILayout.Label("Network server is not running.");
        if (GUILayout.Button ("Start Server"))
		{				
			startServer();	
		}
    }
    else {
    	if (Network.peerType == NetworkPeerType.Connecting)
        	GUILayout.Label("Network server is starting up...");
    	else { 
        	GUILayout.Label("Network server is running.");        	
        	showServerInformation(); 	
        	showClientInformation();
        }
        if (GUILayout.Button ("Stop Server"))
		{				
			stopServer();	
		}
    }
}

function showClientInformation() {
	GUILayout.Label("Clients: " + Network.connections.Length + "/" + maxClients);
    	for(var p: NetworkPlayer in Network.connections) {
		GUILayout.Label(" Player from ip/port: " + p.ipAddress + "/" + p.port);	
	}
}

function showServerInformation() {
	GUILayout.Label("IP: " + Network.player.ipAddress + " Port: " + Network.player.port);  
}

This code snippet uses the startServer() and stopServer() functions we defined above and adds some buttons to start/stop the server. It uses the Network.peerType property to determine the status of the connection and shows this on the screen. The value of the peerType can be:

• Disconnected : No client connection running. Server not initialized
• Server : Running as server
• Client : Running as client
• Connecting : Attempting to connect to a server

The code also uses

for(var p: NetworkPlayer in Network.connections)

A NetworkPlayer is a datastructure containing information about a client (such as the ip address and port). Network.connections returns a list of all connected NetworkPlayers.

To finish the server side, create an empty GameObject and add the ServerMain.js script to it. You should now be able to start and stop the server.

Before we build the client side code, we first need to configure Unity to allow both the client and the server projects to run on the same pc. This is easy for development and debugging purposes.

• Project wizard

  Unity does not allow the same project to be opened more than once. It also automatically reopens the last project you edited. This combination means that if you have any project open in Unity, clicking on Unity again will result in an error message. This can be avoided by selecting Edit > Preferences from the main menu in the Unity editor and then check “Always Show Project Wizard“.

  

  Unity – Preferences

  Unity will now no longer automatically reopen the last project, but allow you to select the project yourself on start up. You should now be able to open both a server project and a client project.

• Run in background

  By default, Unity will only run the project when the game view is active (the mouse is in the view for example). If not active, the code is paused. This is a nuisance if you have a server and a client project open at the same time and are switching between them for development/debugging purposes. To get around this, select Edit > Project Settings > Player from the main menu in the Unity editor, and select Run In Background in the PlayerSettings inspector.

  

  Unity – Player Settings

  If you now run the server project, it will not stop running when the mouse leaves the game view screen. Remember to do this for both the client and the server projects.

Note that as an alternative, bulding the server (.exe) and the client (.exe) projects and running the resulting executable also allows you to run both client and server at the same time on the same pc.

Now that we have a server, let’s build a client to connect to it. Create a new Unity project and add a script called ClientMain.js with following code:

var remoteIP = "127.0.0.1";
var remotePort = 25000;

function connectToServer() {
	Network.Connect(remoteIP, remotePort);	
}

function disconnectFromServer() {
	Network.Disconnect();
}

Again we use the Network class. The function Connect() tries to establish a connection to the server. The first parameter is the (remote) IP address of the server, which in the code above is set to:

var remoteIP = "127.0.0.1"

This is the default ip for localhost (the pc you are running on). This will work fine if the server is also running the same pc, but otherwise this should be set to the actual global ip address of the server.

The second parameter is the (remote) port of the server and should be identical to the listenPort in the ServerMain.js script.

The function Disconnect() is used to disconnect from the server.

To complete the client side script, add the following UI code to the same script file:

function OnGUI ()
{	
	if (Network.peerType == NetworkPeerType.Disconnected)
	{	
		GUILayout.Label("Not connected to server.");
		if (GUILayout.Button ("Connect to server"))
			connectToServer();					
	}
	else
	{
		if(Network.peerType == NetworkPeerType.Connecting)
			GUILayout.Label("Connecting to server...");
		else {
			GUILayout.Label("Connected to server.");
			GUILayout.Label("IP/port: " + Network.player.ipAddress + "/" + Network.player.port);
		}
		if (GUILayout.Button ("Disconnect"))
			disconnectFromServer();
	}
}

This code snippet uses the connectToServer() and disconnectFromServer() functions defined above. In addition, it adds some buttons to connect/disconnect to the server, and shows some status information using the Network.peerType. To complete the client, create a new empty GameObject and add the ClientMain.js script to it.

Run the Server project and press the “Start Server” button. Now run the Client project and press the “Connect to Server” button.

Screenshot of client connected to server

If you are seeing something comparable to the above screenshot then congratulations, you have successfully built your first networking solution!

The client server example above allows a connection to be established between server and client, but it doesn’t yet do anything useful. To improve, let’s first discuss the Unity Network View component.

Unity Network View

The Network View component can be added to any GameObject. It allows state information about the GameObject to be communicated across the network. It has the following key properties:

• Observed

  This property determines the Component of the GameObject for which information will be sent over the network. This is a drop down allowing either a Transform, an Animation, a RigidBody, or a script to be selected. For the selected Component, all the state information required to “recreate” the state of the Component on a different client is sent across the network automatically (by default information is sent 15 times per second). Unity handles all of this information sending and recreating for you, thereby ensuring that all clients see the same state.

• State Synchronization

  This property determines how information about the GameObject will be sent over the network. One option is Unreliable which means that all the state information about the Observed component will be sent every time (15 times per second). It is called unreliable because if the information is lost somewhere in the network (due to packets being dropped by a router for example) then it is not resent. For a real time racing game, such loss is quite acceptable as any resent information will be too late anyway. As long as the next packets contain the complete state again, the game can recover.

  Another option is Reliable Delta Compressed. In this case, not the entire state information is sent every time but only the information that has changed since the last send (hence “delta”). It is called reliable because any information lost in the network is resent and is guaranteed to arrive at all clients. This is necessary because if any change packets are lost then the state on the remote client goes out of sync and any subsequent change packets are unusable. Sending only changes instead of the total state saves on bandwidth but the resending introduces delay, making it less suitable for real time games.

Before showing how the Network View works in some sample code, there is another important function in the Network class to discuss. The Network.Instantiate() function allows a prefab instance to be created on all connected clients (note the prefab must have a Network View). The syntax is:

static function Instantiate (prefab : Object, position : Vector3, rotation : Quaternion, group : int) : Object

Besides the prefab, the function also requires the position and rotation of the prefab.

The last parameter denotes the Communication Group. This allows clients to be split into different groups and the prefab would only be instantiated on clients in that group. This aovids having clients that are nowhere near each other in the game exchanging useless information.

Instantiate() can be called by any client and/or the server, but whoever makes the call “owns” the instance. This means that if Instantiate() is called on a client, this client is authorative for that instance and can change the position and rotation etc. Other clients can cheat by modifying the position of the instance, but these chances are only local to that client and are not communicated across the network (and are overwritten by changes made by the owner).

We will be building an authorative server solution, so all calls to Instantiate need to be made on the server.

To demonstrate the Network View and Network.Instantiate(), let’s extend our client-server solution so that a player gameobject is spawned every time a new client connects to the server.

In the server project, create a folder called “Server” in the Project View and drag the script ServerMain.js into this folder. This folder will contain everything that is needed only on the server side. Also, delete the GameObject from the scene.

Create a second folder called “Game“. This folder will contain everything shared with the client project. Save the scene and call it “Game“. Drag the “Game.unity” scene into the “Game” folder.

Add a Plane GameObject to the scene with Position (0,0,0), Rotation (0,0,0), and Scale (1,1,1). Make sure the Main Camera shows the plane, for example Position (0,1,-10) and Rotation (0,0,0). Add a Directional light to the camera and set the Directional light to Position (0,0,0) and Rotation (0,0,0).

Add an empty GameObject called “GameController” to the scene. Select the GameController and add a NetworkView component by selecting Component > Miscellaneous > Network View from the main menu. In the Inspector, set the State Synchronization property to “Off“, and the Observed property to “None“. This GameObject will serve as a global placeholder used to attach scripts. Why we need a NetworkView here that is doing “nothing” will be explained later on.

None/Off NetworkView

Your scene hierarchy should now look like:

Scene hierarchy

Now we will create a simple cube prefab which will serve as our “player” object. To do this, add a Cube GameObject to the scene. Rename the cube to “Player“. Add a Rigidbody component and also a NetworkView component. In the Inspector, drag the Rigidbody component onto the “Observed” property of the NetworkView component.

Networkview observe Rigidbody

Also in the Inspector, tag the object as “Player“.

Tag as Player

Finally, drag the cube from the Hierarchy view into the Project view. This will create a prefab called “Player” in the project’s Assets folder. Move this prefab into the Game folder and delete the original Player GameObject from the scene.

In the “Game” folder add a JavaScript asset called “PlayerInfo.js” with the following code:

#pragma strict
var playerPrefab : GameObject;

Drag this script from the Project view onto the GameController object in the Hierarchy view. Select the GameController to view the Player Info (Script) in the Inspector. Now drag the “Player” prefab from the Project view onto the “Player Prefab” property in the Inspector. This script serves as a “global” placeholder for the player prefab that the clients will instantiate when they connect.

Player prefab property in Inspector

We have now finished the shared “Game” folder. All that is left to do is to export the folder and (later) import it into the client project. To do this, select and right-click the “Game” folder in the Project view and select “Export Package…” from the pop-up menu that appears.

The Exporting Package dialog will appear.

Export package

Click the “Export…” button and save the Unity package as “NetworkGame“.

We will continue with the client project later on, but first we will complete the server side.

In the folder “Server“, add a second JavaScript called ServerPlayerManager.js. The Project view should now look like the screenshot below.

Project view

Add the following code to the ServerPlayerManager.js script:

#pragma strict

function spawnPlayer(player : NetworkPlayer) {
	var ply : PlayerInfo = GameObject.FindObjectOfType(PlayerInfo);
	var go : GameObject = Network.Instantiate(ply.playerPrefab, Vector3.up*3, Quaternion.identity, 0);
}

This code finds the PlayerInfo script (global placeholder) we created above and uses it to Network instantiate the Player prefab (the cube), positioning it 3 units above the plane (Vector3.up*3) so that it will initially drop down to the plane (it’s a rigid body, so it will be affected by physics). The cube is not rotated (Quaternion.identity). The group parameter is set to 0 which means send to all clients (we are not using groups).

To make sure the spawnPlayer() function is called, we add the following code to ServerMain.js:

@script RequireComponent(ServerPlayerManager)
private var spm : ServerPlayerManager;
function Awake() {
	spm = gameObject.GetComponent(ServerPlayerManager);
}

function OnPlayerConnected(player: NetworkPlayer) {	
	spm.spawnPlayer(player);
}

This code first ensures that the ServerMain.js script is attached to a GameObject that also has the ServerPlayerManager.js script attached to it. This is done by:

@script RequireComponent(ServerPlayerManager)

When the script is created, Unity calls the Awake() function and a reference to the ServerPlayerManager component is stored in a private variable:

private var spm : ServerPlayerManager;
function Awake() {
	spm = gameObject.GetComponent(ServerPlayerManager);
}

This private variable is used to call the spawnPlayer() function when a new client connects (Unity will invoke the OnPlayerConnected() function when a client connects to the server):

function OnPlayerConnected(player: NetworkPlayer) {	
	spm.spawnPlayer(player);
}

To finish the server side, drag both the ServerMain.js and ServerPlayerManager.js scripts onto the GameController object.

Switch to the client project and create a folder called “Client” in the Project view. This folder will contain everything that is needed only on the client side. Drag the ClientMain.js script into this folder. Also, delete the GameObject in the scene.

Now import the NetworkGame.unitypackage you exported from the server project. To do this right click in the Project view and select Import Package > Custom Package… from the pop-up menu, then browse to the location you exported the package to.

Import custom package

Open up the Game scene, and drag the ClientMain.js on to the GameController object in the Hierarchy view.

Press run in the server project and press the “Start Server” button. Now press run in the client project and press on the “Connect to Server” button. You should see a cube drop down onto the plane in both the server and client game views.

Client side game view instantiated player

Select the Player(clone) in server scene hierarchy and use the inspector to modify the position (change the x to 3 for example). You should see the cube change position on both the server and the client.

Select the Player(clone) in the client scene hierarchy and change it’s position likewise. The cube should now only be modified on the client side, and not the server side. In fact, if you now change the server side position again, the client side will jump to the correct (server) position again.

This clearly demonstrates that the server is authorative.

In the client game view, press the “Disconnect” button. You will notice that the cube on the server and the client side remain where they are. Press the “Connect to Server” button again. You should see one additional cube spawn on the server side and two additional cubes on the client side, making the total number of cubes on the client side three.

If you repeat this a couple of times, you will soon have cubes exploding all over the place!

To understand why this is happening, we first need to discuss Remote Procedure Calls (RPC) and how they are implemented in Unity.

Remote Procedure Calls, or RPCs for short, are function calls made over the Network. This allows a client to call a function on a remote server, or vice versa, for example.

The following code snippet demonstrates an RPC function:

@RPC
function PrintText (text : String)
{
    Debug.Log(text);
}

Notice the @RPC attribute placed before the function declaration. This tells Unity that this function can be called remotely.

To call this function, the server or any client can use:

networkView.RPC ("PrintText", RPCMode.All, "Hello world");

The first parameter of the RPC() call is simply the name of the function to call. The third parameter is the parameter for the function call, i.e. the above call is equivalent to locally calling PrintText(“Hello world”).
The second parameter is the RPCMode, which can be used to indicate to whom the RPC call should be made:

• Server: Sends to the server only.
• Others : Sends to everyone except the sender
• OthersBuffered : Sends to everyone except the sender and adds to the buffer
• All : Sends to everyone
• AllBuffered : Sends to everyone and adds to the buffer

The RPCMode allows an RPC call to be either unbuffered (Server, Others, All) or buffered (OthersBuffered, AllBuffered). Non buffered calls are carried out and then forgotten. Buffered calls, on the other hand, are never lost but are stored by the server in an ordered stack. When a new client connects, all the buffered calls are carried out on the new client (in order). This allows the game state to recreated on a client who comes into a game that has already started.

Whenever we make a call to Network.Instantiate(), Unity makes use of buffered RPCs underwater. This ensures that when new clients connect, all the instantiated game objects (player instances etc.) will also be created on the new client.

You can easily build your own RPCs, but there are some restrictions:

• Firstly, the network communication required for RPCs is handled by a NetworkView. This means that the script containing RPC functions must be attached to a GameObject that also has a NetworkView component. This is why we added a NetworkView to the GameController object in the projects above. The GameController is a dummy placeholder and so we don’t need to synchronise the state (position, rotation etc) of the object. However, the script calling Network.Instantiate() (and thus making RPC calls underwater) is attached to the GameController. For this reason, it requires a NetworkView, but the State Synchronisation property can be set to “off” and the Observed property to “None”.
• Secondly, an RPC function can have as many parameters as you want, but each parameter must be one of the following types: float, string, NetworkPlayer, NetworkViewID, Vector3, Quaternion. To call an RPC with more than one parameter, use the following syntax:

  networkView.RPC ([rpc function name], [rpc mode], parameter1, parameter2, ...);
  

Returning to our client and server projects, we can easily understand the spawning madness we get when the client disconnects and reconnects. When the client connects for the first time, its Intantiate() call is buffered. When the client disconnects and connects again, it triggers a new Instantiate() and it also gets the buffered Instantiate(), thus leading to two cubes. A third connect, would lead to three cubes, and so on.

To avoid this problem, the server needs to clean up the buffered RPC calls for clients that have disconnected.

However, that is not all. On the client side, the client has to clean up its old cubes before connecting again. The sever cannot do it for the client because it is no longer connected.

To improve the spawning process add the following code to the client side:

function OnDisconnectedFromServer (info : NetworkDisconnection) {
	var gos : GameObject[] = GameObject.FindGameObjectsWithTag("Player");
	for(var go : GameObject in gos) {
		Destroy(go);
	}
}

The function OnDisconnectedFromServer() will be called by Unity when the client is disconnected from the server. Because we tagged the Player prefab with the “Player” tag, we can get any cube instances using:

GameObject.FindGameObjectsWithTag("Player");

We can then use the Destroy() function to delete these old player cubes.

To improve the server side spawning and cleaning up when a client disconnects is a little more complicated. The reason for this is that the server needs to keep track of which cube instance belongs to which client. This allows the server to delete the right cube when a client disconnects.

Replace the existing code in ServerPlayerManager.js with:

#pragma strict

var players = new Hashtable();

function spawnPlayer(player : NetworkPlayer) {
	var ply : PlayerInfo = GameObject.FindObjectOfType(PlayerInfo);
	var go : GameObject = Network.Instantiate(ply.playerPrefab, Vector3.up*3, Quaternion.identity, 0);
	players[player] = go;
}

This instantiates a new cube when a client connects, and places the cube instance in a hashtable, using the NetworkPlayer as the key.

To clean up when a client disconnects add the following code:

function deletePlayer(player : NetworkPlayer) {
 	var go : GameObject = players[player];
 	Network.RemoveRPCs(go.networkView.viewID); 
	Network.Destroy(go); 
	players.Remove(player); 
}

This function first finds the cube instance for this player in the hastable (using the NetworkPlayer as key). It then calls

Network.RemoveRPCs(go.networkView.viewID);

which clears away any buffered RPCs belonging to the cube’s NetworkView. This will ensure that new clients connecting will not instantiate a cube for the disconnected player.
Next, the cube is deleted from all clients (including the server) using

Network.Destroy(go); 

This is basically the network version of the local Destroy() function.
Finally, the server removes the player and cube instance from the hashtable:

players.Remove(player);

To make sure this function is called when a client disconnects, as the following code the ServerMain.js

function OnPlayerDisconnected(player : NetworkPlayer) {
	spm.deletePlayer(player);
}

This uses the private variable instance of the ServerPlayerManager.js script initialised earlier.

Start up the Server and the Client projects, and try connecting and reconnecting the client. Spawning and cleaning up of the cubes should now work as expected. Try building the client to create an executable (.exe) and also running this a number of times so that you have more than one client connecting to the server at the same time.

To complete this introduction tutorial, lets improve our networking solution to allow the clients to move their cubes about. To do this in an authorative server solution requires the clients to send their input (key presses etc) to the server. The server will then update the world (ie the position of the clients cube) and send the result to all connected clients.

Add the following code to ServerPlayerManager.js:

@RPC
function handlePlayerInput(player: NetworkPlayer, vertical: float, horizontal: float) {
 	var go : GameObject = players[player];
 	go.transform.position = go.transform.position + Vector3.right*horizontal;
 	go.transform.position = go.transform.position + Vector3.forward*vertical;
}

This is an RPC function which can be called by the clients remotely. It basically finds the cube belonging to the player and then updates the position depending on the value of the “vertical” and “horizontal” parameters the client sends.

Add the following code to ClientMain.js:

function Update() {
	if(Input.anyKey) {
		sendInputToServer();
	}
}

function sendInputToServer() {
	var vertical: float = Input.GetAxis("Vertical");
	var horizontal: float = Input.GetAxis("Horizontal");
    if((vertical!=0)||(horizontal!=0)) {
        networkView.RPC("handlePlayerInput",RPCMode.Server,Network.player,vertical, horizontal);
    }
}

Unity Input is used to check if any key is pressed

if(Input.anyKey)

and if so the function sendInputToServer() is called. This function uses Input.GetAxis() to check for input:

var vertical: float = Input.GetAxis("Vertical");
var horizontal: float = Input.GetAxis("Horizontal");

On the “Horizontal” axis, -1 is left and 1 is right. On the “Vertical” axis, 1 is up and -1 is down. If theri is any input (!=0) then the code calls the RPC “handlePlayerInput” on the server:

networkView.RPC("handlePlayerInput",RPCMode.Server,Network.player,vertical, horizontal);

passing along as first parameter the client NetworkPlayer

Network.player

followed by the values of vertical and horizontal.

Note that RPCMode.Server is used, meaning that the RPC call should only be sent to the server for execution.

Also add the following code:

@RPC
function handlePlayerInput(player: NetworkPlayer, vertical: float, horizontal: float) {
}

The reason that this dummy (empty) function is needed is that Unity requires the client and the server to both have the RPC function, even if it is only going to be called on the server. This is a typical for Unity networking in that Unity seems to prefer the client and server code to be combined into one and the same project. This would favour the peer to peer networking model, where a client can host a game and be the server as well. In this tutorial, we have split the client and sever code into two projects. This serves the purpose of clarifying what the server does and what the client does.

Run the server and connect with one or more clients. Each client should now be able to move it’s own cube (but nobody else’s). The server should not be able to move anything. Try bumping one cube into another and see that the server side physics (the cubes are rigid bodies) handles all the collisions.

Congratulations! You have now completed this introduction to Unity networking.

You can download the two projects directly here.

Surface Shader

In this article, I will give a basic introduction to what shaders are, discuss the basics of the Unity rendering pipeline and introduce the reader how to use shaders within the Unity game engine.

Shaders are used a lot in video games to produce a wide variety of effects like for example lightning models, distortion, (motion)blur, bloom, and edge detection effects. A shading language is used to program the graphics processing unit (gpu) and allows the user to setup the graphics hardware for rendering instead of the fixed function pipeline. There are 3 shaders types commonly used; Vertex Shaders, Fragment Shaders and Geometry Shaders.

In Unity the user is able to write custom shaders, however full screen effects require render textures which are only available in Unity Pro and won’t be covered in this article. These are full screen image processing effects are a pretty advanced topic on themselves. Because there is quite a lot of material to cover I won’t be delving too deep into writing custom shader effects but emphasize on what shaders are and how they are used in the Unity game engine.

Borderlands 2 Cell Shading

In Unity all rendering is done through the use of shaders. Shaders in Unity are small scripts that allow the user to configure how the graphics hardware is set up for rendering. Unity ships with over 60 built-in shaders that are are used through the use of materials. There is a close relationship in Unity between materials and shaders. The shaders contain the code that defines what kind of properties and asset to use while materials allow the user to adjust the properties and assign assets. For example if we create a new GameObject and assign a material to it, we can choose a shader from the Inspector that specifies how our material should look like when we are in-game. The properties of the material vary depending on the shader that is used to render the GameObject.

There are 3 ways how shaders can be written in Unity; Fixed Function Shaders, Vertex and Fragment Shaders, and Surface Shaders. The code for these shaders is encapsulated using the Unity shading and material language called ‘ShaderLab’. The shaders themselves are typically written using CG or HLSL shading language.

Surface shaders are commonly used if your shader needs to be affected by both lights and shadows. Since the shader needs to be affected by light, you do not want to write out the complete shader code that handles a default BlinnPhong lighting model every time. This allows the user to write more complex shaders in a more compact way. If the shader doesn’t need to interact with lighting it is best to use a vertex and fragment shader instead. Otherwise Unity would still be making lighting calculations while we don’t need them.

Vertex and fragment shaders can be used if the shader doesn’t need to interact with lighting or when you need to deal with an effect that a surface shader can’t handle. These are the most flexible shaders to create shader effects however it makes it harder to interact with lighting.

Fixed function shaders are used for older hardware that doesn’t support programmable shaders. The fixed function shaders are usually used as a last fallback to make sure a game is still rendering something meaningful when a certain shader effect is not supported by the graphics processing unit. Fixed function shaders are completely written using in Unity’s ‘ShaderLab’. We will look at this in more detail later.

Unity’s Built-In Shaders

So with shaders we can define how our object will appear in the game world and how it will react to lighting. How these lights will react on the objects depend on the passes of the shader and which rendering path is used. The rendering path can be changed through Unity’s Player Settings. Or it can be overridden in the camera’s ‘Rendering Path’ setting in the inspector. In Unity there are 3 rendering paths: Vertex Lit, Forward Rendering and Deferred Rendering. If the graphics card can’t handle the current selected render path it will fallback and use another one. So for example if deferred rendering isn’t supported by the graphics card, Unity will automatically use Forward Rendering. If forward rendering is not supported it will change to Vertex Lit. Since all shaders are influenced by the rendering path that is set I will briefly describe what each rendering path does.

Vertex Lit is the simplest lighting mode available. It has no support for real-time shadows. It is commonly used on old computers with limited hardware. Internally it will calculate lighting from all lights at the object vertices in one pass. Since lighting is done on a per-vertex level, per-pixel effects are not supported.

Forward rendering renders each object in one or more passes, depending on the lights that affect the object. All lights are treated differently depending on the settings and intensity being set by the user. When forward rendering is used, the amount of pixel lights set from the quality menu that affect the object will be rendering using full per-pixel lighting. Additionally 4 point lights are calculated per-vertex and all other lights are computed as Spherical Harmonics which is an approximation. A light can be per-pixel lit depending on several situations. Lights with the render mode set to Not Important, are always per-vertex or spherical harmonics. Brighter lights are always calculated per-pixel also when the render mode is set to Important. Forward rendering is the default selected rendering path in Unity.

In Deferred rendering there is no limit on the number of lights that affect an object and all lights are calculated on a per-pixel base. This means that all lights interact with normal maps etc. Lights can also have cookies and shadows. Since all lights are calculated per-pixel it works great on big polygons. Deferred rendering is only available in Unity Pro.

Selecting a rendering path

All shaders in Unity are wrapped in a material and shading language that is called ‘ShaderLab’. ShaderLab organizes the shader structure. Here is an example from the Unity documentation:

Shader "MyShader" {
    Properties {
        _MyTexture ("My Texture", 2D) = "white" { }
        // other properties like colors or vectors 
        // go here as well
    }
    SubShader {
        // here goes the 'meat' of your
        //  - surface shader or
        //  - vertex and fragment shader or
        //  - fixed function shader
    }
    SubShader {
        // here goes a simpler version of the SubShader above that
        // can run on older graphics cards
    }
}

In ShaderLab we start by defining a name for the shader which in this case is “MyShader” and it will be listed in the inspector under that name. Next there are properties defined and these will be shown in the Material Inspector in Unity. Sub Shaders are used to create a list of shaders that can be used on different types of hardware. If the gpu doesn’t support a certain feature, it is able to fallback to a more simplified version of this shader. Unity itself will go through the list of sub shaders and pick the first sub shader that is supported by the hardware. Note: The user must always specify at least 1 sub shader!

Shader "example" {
    // properties and subshaders here...
    Fallback "otherexample"
}

Optionally the user can also define a fallback which tries to run another sub shader from another shader. The fallback gets called when all the sub shaders you defined are not able to run on the hardware. This is nice since we don’t need to rewrite all the sub shader code from another shader.

To start, I will show you how to create a new fixed function shader that binds a color property for a material and after that we will walk through Unity’s vertex lit shader. We can create a new shader from the project panel in Unity by pressing Create – Shader or from the top menu In Unity under Assets – Create – Shader. If we want to edit a shader we can simply double click it in the project view similar to opening a script file. Once we double-clicked a shader, Unity will open MonoDevelop to start editing the shader file. After the shader is opened we first want to delete everything that Unity created by default. Unity by default creates a basic template for a surface shader. We can recognize if it is a fixed function shader if we take a look at the inspector when selecting a shader in the project view under Vertex and Pixel program.

Fixed Function Shader

First we need to start by giving our shader a name. Look at the ShaderLab body above to see the basic layout of the ShaderLab structure. We can use backslashes in the Shader name to put the shader in a custom folder in the inspector. It should look like this:

Shader “Custom/MyCustomShader” {
}

Next we need to define some properties that we want to tweak in the material inspector. First we start with the keyword ‘Properties’ and use opening brackets so we can list several properties we want. Properties can be used by the shader, so for example we could set a color and a texture and combine those two together which will be the final color of our material.

Let’s take a look at an example of a property.

Properties {
    _Color ("Main Color", Color) = (1.0, 1.0, 1.0, 1.0)
}

First the name of the property is set in this case _Color. Next we need to specify a display name; this is how the property will be listed in the material inspector. Next we specify the type of property we want to set and we need to assign an actual value to that property we just specified. In our case it is a Color, which takes 4 floats (RGBA). Instead of the Color property we can also add different types. For example: Range, 2D, Rect, Cube, Float, and Vector. Range is presented as a slider in the material inspector and goes from min to max. 2D takes a string as parameter and defines a 2D texture. Rect defines a rectangle (non-power of two) texture. Cube defines a cubemap texture, float defines a floating point property and Vector defines a four component vector. The texture property can also be given property options which can for example set the texture coordinate generation of this texture.

Now we need to define at least one sub shader so our object can be displayed. As stated above Unity will pick the first sub shader that runs on the graphics card. Each sub shaders defines a list of rendering passes. Each pass causes the geometry to be rendered once. Generally speaking you would like to use the minimum amount of passes possible since which every added pass our performance goes down because of the object being rendered again. A pass can defined in 3 ways, a regular pass, use pass or grab pass. The ‘UsePass’ command is used when we want to use another pass from another shader. This can help by reducing code duplication. ‘GrabPass’ is a special pass. It grabs the content of the screen where the object is to be drawn into a texture. This texture can then be used for more advanced image based processing effects. A regular pass sets various states for the graphics hardware. For example we could turn on/off vertex lighting, set blending mode, or set fog parameters.

SubShader {
    Pass {
        Material {
            Diffuse [_Color]
        }
    }
    Lighting On
}

The material block binds the property values we set for _Color to the fixed function lighting material settings. The command Lighting On turns on the standard per-vertex lighting.

Additionally tags can be setup which tells how and when sub shaders should be rendered to the rendering engine. Tags must be specified inside the sub shader block and not inside the pass block.

A fallback will automatically be used when none of the previously described sub shaders are able to run on the hardware and it will try to use a sub shader from another shader.

Categories can be used to group multiple shaders inheriting the same rendering state. For example the user can group several sub shaders to with all of them having Fog turned off.

A fixed function shader assigning a Color type

When using vertex and fragments shaders the so called ‘Fixed Function Pipeline’ is turned off. As an example the 3D transformations that normally take place are disabled. This means that when we want to write a vertex/fragment program we need to rewrite the fixed function functionality ourselves that is normally built into API’s like OpenGL. Note that vertex and fragment shaders are typically used when the shader doesn’t need to interact with lighting. If that is the case a ‘Surface shader’ is suggested.

In Unity shaders in ShaderLab are written using the Cg programming language. ‘Cg Snippets’ are compiled into low-level shader assembly by the Unity editor. That means that once you distribute your game files, only the low-level assembly code will be included. This is how a general ‘Cg Snippet’ would look in ShaderLab:

Pass {
    // ... the usual pass state setup ...

    CGPROGRAM
    // compilation directives for this snippet, e.g.:
    #pragma vertex vert
    #pragma fragment frag

    // the Cg code itself

    ENDCG
    // ... the rest of pass setup ...
}

The whole Cg code is placed inside the Pass block between CGPROGRAM and ENDCG keywords. The pragma directives indicate what function should be executed for the vertex program, and another function that is executed for the fragment program. In this case ‘vert’ is the vertex program and ‘frag’ is the fragment program. The vertex program is executed at a per-vertex level, where the fragment program is executed at a per-pixel level. Unity also contains several files that bring predefined variables and helper functions. This is done by the standard include directive like – #include “UnityCG.cginc”.

Similarly to the fixed function shaders we can specify properties that should be revealed in the material inspector. To use these variables in your ‘Cg Snippets’ we need to define a variable that has a matching name and a matching type. Unity will automatically set the variable for us as long the name and type are matched with the property. This means that if you defined a Property called _Color (“Main Color”, Color) in the Properties block you need to have a matching Color type named _Color. In this case a float4 would be the correct type to use since a Color consists out of 4 floating point numbers.

Note: the syntax might not look familiar to you. In case you want to learn more about the Cg programming language, I suggest heading over to the NVIDIA website. I added a few resource pages at the end of this article.

Surface shaders in Unity are an easy way to write shaders that make use of lighting instead of using low-level vertex and pixel shaders. Surface shaders are still written in Cg/HLSL. The surface shader compiler will turn the surface shader into the actual vertex and pixel shaders as well as the rendering passes to handle forward and deferred rendering. Using surface shaders prevents the user from typing repetitive code that calculates lighting.

The user needs define a surface function that describes the standard output of the surface shader which describes properties of the surface like albedo color, normal, emission value, specularity and so on. This is how an output structure would look like:

struct SurfaceOutput {
    half3 Albedo;
    half3 Normal;
    half3 Emission;
    half Specular;
    half Gloss;
    half Alpha;
};

A surface shader is placed in between a CGPROGRAM and an ENDCG block. It must be placed inside the SubShader block. To define a surface shader the user must use #pragma surface to indicate it is a surface shader. The complete pragma directive looks like this:

#pragma surface surfaceFunction lightModel [optional parameters]

The surface function indicates which surface shader function contains the Cg code. The function should have the following form: void surfaceFunction(Input IN, inout SurfaceOutput o)

The Input or IN is a structure we should have defined. Input should contain any texture coordinates and extra automatic variable needed by the surface function surfaceFunction. The lightModel specified which lighting model we want to use. There are several built-in lighting models available like Lambert (diffuse) and BlinnPhong (specular). For all list of all the optional parameters I suggest you read the Unity documentation on surface shaders which will be listed at the end of this article. The user is also able to write a custom lightModel that can be used in the surface shader however that won’t be described in this article.

The Input structure we need to specify usually has the texture coordinates that are needed by the shader. Texture coordinates must be named ‘uv’ followed by the texture name. We can also use ‘uv2’ to indicate we are dealing with a second texture coordinate set. There are several values that can be defined in the Input structure like view direction, screen/world position, world normal etc.

So let’s take a look at a simple diffuse surface shader from the Unity manual.

Shader "Example/Diffuse Simple" {
    SubShader {
        Tags { "RenderType" = "Opaque" }
        CGPROGRAM
        #pragma surface surf Lambert
        struct Input {
            float4 color : COLOR;
        };
        void surf (Input IN, inout SurfaceOutput o) {
           o.Albedo = 1;
        }
        ENDCG
    }
    Fallback "Diffuse"
}

Probably you immediately notice that surface shaders are quite similar to the previously described fixed function shader except the surface shader has the additional lines we just described, like the #pragma directive indicating we are dealing with a surface shader here. So what is new here?

The most important change we see is that inside the SubShader block we start with CGPROGRAM and end the SubShader with ENDCG. All our Cg code will be placed within this block. After this we have the pragma directive to indicate this is surface shader. In this case we tell surf is our surface function and that the lighting model to use is Lambert.  Next there is an input structure defined. This shader only specified a color as input value.

After the input structure is created, the surface function is defined which takes the Input and a surface output as parameters. The output will be the actual output of the shader code. So in this case we can see that the albedo of the output is set to 1. This will result of this shader will be that the surface color will be set to white while it used the Lambert (diffuse) lighting model we defined in the pragma directive.

A surface shader creating a checker pattern

Shaders are quite an advanced and complex subject and learning how to write shaders isn’t easy and something that you learn in one day. Hopefully I was able to give the reader a better understanding of the underlying rendering pipeline, how lighting is treated and how shaders can be used to manipulate the resulting outcome. You probably used materials all the time already, but hopefully you now have a better understanding of how they work internally. There is a lot of material to cover so I didn’t go into great detail of each render setting of a shader. I suggest you refer to the Unity Reference Manual for a more detailed look on shaders.

We learned:

• That shaders in ShaderLab are written using the Cg programming language.
• That Unity utilizes different rendering pipelines.
• How materials and shaders have a direct connection between them.
• The differences between Fixed function, Vertex and Fragment, and Surface shaders.
• That Surface Shaders are compiled into vertex and fragment shaders.
• How all shader code is encapsulated in Unity’s ShaderLab.
• That vertex/fragment shaders have two functions that describe both the vertex and fragment program.

Furthermore we took a look at:

• How to write a basic ‘Fixed Function’ shader.
• How surface shaders are being defined and what they can do.
• How we can define a structure.

The following references were used to gather the information required to write this article.

http://docs.unity3d.com/Documentation/Manual/Materials.html
http://docs.unity3d.com/Documentation/Components/Built-inShaderGuide.html
http://docs.unity3d.com/Documentation/Manual/Shaders.html
http://docs.unity3d.com/Documentation/Components/SL-Shader.html
http://docs.unity3d.com/Documentation/Components/SL-Reference.html
http://docs.unity3d.com/Documentation/Components/SL-SurfaceShaders.html
http://docs.unity3d.com/Documentation/Components/SL-ShaderPrograms.html
http://docs.unity3d.com/Documentation/Components/SL-RenderPipeline.html
http://docs.unity3d.com/Documentation/Components/Rendering-Tech.html
http://unity3d.com/unity/download/archive

http://docs.unity3d.com/Documentation/Images/manual/Materials-1.jpg

http://blogs.unity3d.com/2010/07/17/unity-3-technology-surface-shaders/

http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html

[UnityShaders.zip]

Terrains in Unity

In this article, I will introduce the reader to Terrains in Unity. I will describe the different terrain features that Unity offers and we will build a simple terrain that can be used in your game.

In this article, I will explain how to use the Terrain Engine in Unity.

I assume the reader has a basic understanding of Unity including creating a new Unity project and, asset management, and the basic GameObject-Component model. If not, then I would refer the reader to my previous article which provides an introduction to Unity here: http://3dgep.com/?p=3246.

To create a new Terrain in your scene, select Terrain > Create Terrain from the main menu.

Unity – Create Terrain

This will add a new Terrain Asset in the Project view and add a GameObject in the scene with a Terrain (Script) component and a Terrain Collider component that references the new Terrain Asset.

Unity – New Terrain

If you want to change the properties of the currently selected terrain, you can choose Terrain > Set Resolution from the main menu.

Unity – Terrain Resolution

The Set Heightmap Resolution dialog box exposes the following properties:

• Terrain Width: Allows you to specify the width (X-axis) of the terrain in world units.
• Terrain Height: Allows you to specify the maximum height (Y-axis) of the terrain in world units.
• Terrain Length: Allows you to specify the length (Z-axis) of the terrain in world units.
• Heightmap Resolution: The resolution of the terrain heightmap. The heightmap is always a square texture that has this value for both the width and height of the texture regardless of the size of the terrain.
• Detail Resolution: The resolution of the detail map that controls the grass and detail meshes. For best performance, you should keep this value as small as possible while still maintaining the desired amount of detail.
• Detail Resolution Per Patch: The detail texture is split into patches according to this parameter where each patch combines all of the detail (grass and detail meshes) into a single piece of geometry and a single texture. For example a Detail Resolution map of 1024×1024 will be split into 128×128 detail patches if Detail Resolution Per Patch is set to 8. Larger values for this parameter will produce less detail patches and thus less draw class to the GPU if a lot of terrain is visible. Smaller values will produce more patches which could potentially produce more draw calls (depending on how much of the terrain is visible). If you have relatively flat terrain, I would suggest to set this value higher (64, or 128 for example) but if you have a mountainous terrain, I would suggest you keep this value smaller (8 or 16 for example).
• Control Texture Resolution: The resolution of the spat map that is used to layer the different textures that are painted onto the Terrain.
• Base Texture Resolution: The base texture is used in place of the splat map when the viewer is sufficiently far away.

The Terrain Heightmap is a 2-dimensional texture that is used to encode the height of each point on the terrain. The height values of the terrain are usually encoded in 8, or 16-bit floating point values in the range 0 to 1. A value of 0 in the heightmap indicates the lowest part of the terrain and a value of 1 in the heightmap indicates the highest part of the terrain.

Terrain Heightmap

The original terrain heightmap can be generated in an external tool such as Terragen (http://www.planetside.co.uk/) or using plug-ins purchased on the Asset Store directly in Unity. You can also create your terrain heigtmap directly in Unity using the available heightmap tools.

Unity – Terrain Tool

The first three buttons on the Terrain Toolbar allow you to adjust the height of the terrain using the following tools:

• Raise/Lower Height: The Raise/Lower tool is used to adjust the height of the terrain using a variety of brushes.
• Paint Height: The Paint Height tool allows you to flatten areas of the terrain to a specific height.
• Smooth Height: The smooth height tool allows you to smooth rough edges of the terrain.

As the name suggests, the Raise/Lower Height tool allows you to raise and lower the height of the terrain. The terrain can be raised to the maximum (1.0) height and it can be lowered to the minimum height (0.0). You cannot lower the terrain below the lowest possible value.

Unity – Raise/Lower Height

Clicking on the terrain will raise the terrain incrementally. Holding Shift while clicking will cause the terrain to lower incrementally. Keeping the mouse button held down while moving the mouse will allow you to raise and lower the terrain continuously.

Unity – Raise/Lower Terrain Tool

The Raise/Lower Height brush has the following properties:

• Brush Size: This slider allows you to select the size of the brush in terrain heightmap resolution units. The minimum value being 1 terrain heightmap pixel and the maximum value being 100 terrain heightmap pixels.
• Brush Opacity: The brush opacity determines the intensity of the change that occurs. This slider property can have a minimum value of 0 which will cause no change to occur and a maximum value of 100 which will cause the terrain to be raised/lowered a full increment.

The Paint Height terrain tool will allow you to flatten certain areas of the terrain to a specific height.

Unity – Paint Height Terrain Tool

This is useful for creating plateaus and shelves on your terrain.

The Paint Height terrain tool has the following properties:

• Brush Size: This slider allows you to select the radius of the brush in terrain heightmap resolution units. The minimum value being 1 terrain heightmap pixel and the maximum value being 100 terrain heightmap pixels.
• Brush Opacity: The brush opacity determines the intensity of the change that occurs. This slider property can have a minimum value of 0 which will cause no change to occur and a maximum value of 100 which will cause the terrain to be adjusted a full increment.
• Height: This value determines the desired height to set the terrain to. This value is measured in world-units. The minimum value is 0 and the maximum value is the value of the Terrain Height parameter specified in the Terrain Heigtmap Resolution dialog box. You can adjust this slider value manually, or you can Shift-Click on a part of the terrain to set this property to the height of the terrain at the clicked point.

After adjusting the height of the terrain several times using the Raise/Lower and Paint Height tools, the terrain can become quite jagged. The Smooth Height terrain tool can be used to smooth-out these apparent jaggies to create a more natural, smooth terrain. This is equivalent to the erosion that occurs naturally after thousands of years of exposure to weather conditions.

The image below shows an example of jaggies that occur after manipulating the terrain.

Unity – Terrain Jaggies

After smoothing:

Unity – Smooth Terrain

The Smooth Height terrain tool has the following properties:

• Brush Size: This slider allows you to select the radius of the brush in terrain heightmap resolution units. The minimum value being 1 terrain heightmap pixel and the maximum value being 100 terrain heightmap pixels.
• Brush Opacity: The brush opacity determines the intensity of the change that occurs. This slider property can have a minimum value of 0 which will cause no change to occur and a maximum value of 100 which will cause the terrain to apply the maximum amount of smoothing.

After you have created your prefect heightmap, you may want to export it for use in another project or to be used in an external program to be fine-tuned. Or, you may want to import a heightmap that was created with an external tool such as Bryce, Terragen, or Photoshop.

To export your heightmap from Unity, select Terrain > Export Heightmap – Raw… from the main menu.

Unity – Export Heightmap

The Export Heightmap dialog box should appear.

Terrain – Export Heightmap Dialog

In most cases, the default settings should be sufficient. Click the “Export” button to export your heightmap to a Raw file.

Because the Raw file format does not encode the pixel format or the dimensions of the texture in the file itself, it is generally a good idea to save the file with this information in the filename. For example, a 16-bit heigtmap texture of size 257×257 pixels should be saved with the name:

terrain_257x257_16-bit.raw

This way, if you want to use this texture in another program, you already know the size of the texture and the pixel format.

You can then use your texture in a program such as Bryce, Terragen, or Photoshop to fine-tune the heightmap.

For example, if you open a raw file in Photoshop, you will get the following dialog box:

Photoshop – Raw File Options

If you specify the correct settings according to how you exported the Raw file in Unity, you should see the heightmap of your terrain in Photoshop.

Phtoshop – Edit Raw File

After you make the necessary adjustments to the terrain in Photoshop you can import the modified terrain file into Unity using the Terrain > Import Heightmap – RAW… command from the main menu in Unity.

Textures can be painted onto the terrain using the Paint Texture tool.

Unity – Paint Texture

Before you can paint any textures to the terrain, you must first add at least one texture to the terrain. To get started quickly, Unity provides suitable terrain assets in the Standard Packages that comes with Unity. To import the Terrain Assets, select Assets > Import Package > Terrain Assets from the main menu.

Unity – Import Terrain Assets

Click the Import button to import these assets into your current project.

With the Paint Texture tool selected in the Inspector click the Edit Textures… button and select Add Texture from the popup that appears.

Unity – Add Terrain Texture

The Add Terrain Texture dialog box should appear.

Unity – Add Texture

The Add Terrain Texture dialog has the following properties.

• Splat: The texture to apply to this slot in the terrain.
• Tile Size: How large each tile of the texture is applied to the terrain. Larger tiles means the texture will have less tiles across the terrain in each direction. Smaller tiles will mean the texture will be repeated more times across the terrain in each direction.
• Tile Offset: Adjusting this parameter will shift the texture in the terrain. This is useful if you want to blend multiple layers with the same texture to break the repetition that occurs when using a single texture.

Click the target button on the Splat parameter and select a texture to apply to the terrain.

Unity – Select Texture

After you apply the texture to the terrain, you should see the entire terrain covered in that texture.

Unity – Textured Terrain

The Paint Texture terrain tool has the following properties:

• Textures: The Textures property shows the different textures that are assigned to the various texture slots of the terrain. You can have a maximum of 255 textures assigned to the terrain.
• Brush Size: The radius of the Paint Texture brush measured in pixels of the Control Texture resolution.
• Opacity: The intensity that the selected texture will be applied to the terrain. This parameter is measured as a percentage from 0 to 100.
• Target Strength: The Target Strength parameter can be used to cap the intensity of the currently selected texture. This value is measured as a ratio of the amount of texture that will replace the texture under it. If you don’t want to apply more than 50% opacity of the selected texture to the terrain, then you should set this value to 0.5.

Before you can blend textures on the terrain, you must have at least 2 textures in the terrain’s texture list. Add a few more textures to your terrain and use the Paint Texture tool to fancy-up your terrain. The currently selected texture will have a blue outline in the Inspector.

Unity – Textured Terrain (2)

Now that we have some interesting textures applied to the terrain, it’s time to add some detail.

Trees can be painted onto the terrain using the Place Tree tool in the inspector.

Unity – Place Trees Tool

Just like the Paint Texture tool, the Place Tree tool requires at least one tree to be added to the terrain.

Click the Edit Trees… button and select Add Tree from the pop-up menu that appears.

Unity – Add Tree Dialog

The Add Tree dialog provides the following properties:

• Tree: The tree model to use for this slot in the terrain’s tree list.
• Bend Factor: The the amount of bending that will be applied to the trees when they are effected by wind.

Select the target icon next to the Tree property and select a tree from the dialog that appears.

Unity – Select Tree

Click the Add button to add that tree to the tree list for the terrain.

Unity – Tree Inspector

The Place Trees tool has the following properties:

• Trees: The list of trees assigned to the different slots of the terrain.
• Brush Size: The radius of the brush in world unit.
• Tree Density: How many trees will be placed when the terrain is painted.
• Color Variation: The amount of random shading that will be applied to the trees when they are painted.
• Tree Height: The amount of scaling to apply to the painted trees. A value of 100 will paint the trees with a scale of 1 and a value of 200 will double the height of the trees.
  

  Unity – Tree Heights

  The image shows the trees on the left are painted with a height of 50, the trees in the middle are painted with a height of 100 and the trees on the right are painted with a height of 200.

  • Variation: The amount of random variation to apply to the tree heights.
• Tree Width: The amount of scaling to apply to the width and depth of the tree.
  • Variation: The amount of random variation to apply to width of the tree.

You can have Unity automatically place trees for you on the terrain by using the Mass Place Trees option in the Terrain menu.

Unity – Mass Place Trees

Select the number of trees that you would like to place and press the “Place” button to randomly place that number of trees on your terrain. Doing this will replace any trees that you have already placed on the terrain.

Unity – Mass Place Trees (2)

Unity will place the trees on relatively flat areas of your terrain.

Unity provides the Tree Creator tool that allows you to create your own custom trees directly in the Unity editor. To create a custom tree in Unity, create a new Tree GameObject by selecting GameObject > Create Other > Tree from the main menu.

Unity – Tree Creator

You can also import the Tree Creator package from the Standard Assets that ship with Unity (select Assets > Import Package > Tree Creator from the main menu). This package gives you access to some textures that can be used to create your own trees in Unity. The image above shows the Big Tree tree asset that has been created with the Tree Creator tool.

To learn more about how to use the Tree Creator tool to build custom trees in Unity, please refer to the online documentation on the Unity website:
http://docs.unity3d.com/Documentation/Components/class-Tree.html

To add grass to the terrain, select the Paint Details tool in the Inspector.

Unity – Paint Details Tool

Similar to the Paint Texture and the Place Trees tools, the Paint Details tool needs to have some detail objects to be defined.

Click the Edit Details… button and select Add Grass Texture in the pop-up menu that appears.

Unity – Add Grass Texture

The Add Grass Texture dialog has the following properties:

• Detail Texture: The texture to be used for the grass.
• Min Width: Minimum width of each grass section in world units.
• Max Width: Maximum width of each grass section in world units.
• Min Height: Minimum height of each grass section in world units.
• Max Height: Maximum height of each grass section in world units.
• Noise Spread: The size of noise-generated clusters of grass. Lower numbers mean less noise.
• Healthy Color: The color of healthy grass, prominent in the center of Noise Spread clusters.
• Dry Color: Color of dry grass, prominent on the outer edges of Noise Spread clusters.
• Billboard: If checked, this grass will always be rotated to face the current Camera.

Click the target icon next to the Detail Texture property and select a grass texture in the Select Texture2D dialog that appears.

Unity – Select Grass Texture

The Terrain Assets in the Standard Packages contains a couple grass textures that can be used on your terrain. Add the grass textures to your terrain and paint some areas with grass.

Unity – Grass Detail Textures

Similar to grass, detail meshes are added to the terrain using the Paint Details tool.

Unity – Paint Details Tool

To add a detail mesh to the terrain, click the Edit Details… button in the inspector and select Add Detail Mesh from the pop-up menu that appears.

Unity – Add Detail Mesh

The Add Detail Mesh dialog has the following properties:

• Detail: The mesh to be used for the detail.
• Noise Spread: The size of noise-generated clusters of the Detail. Lower numbers mean less noise.
• Random Width: Limit for the amount of width variance between all detail objects.
• Random Height: Limit for the amount of height variance between all detail objects.
• Healthy Color: Color of healthy detail objects, prominent in the center of Noise Spread clusters.
• Dry Color: Color of dry detail objects, prominent on the outer edges of Noise Spread clusters.
• Render Mode: Select whether this type of detail object will be lit using Grass lighting or normal Vertex lighting. Detail objects like rocks should use VertexLit. Detail mesh that should be effected by wind (such as bushes) should be set to Grass.

The Terrain Assets in the Standard Assets package does not include any meshes that can be used as detail meshes for the terrain, but you can download the Terrain Assets package that is provided on the Unity website contains some bushes and rocks that can be used to add some detail to your terrain. You can download the Terrain Assets package here:
http://unity3d.com/support/resources/assets/terrain-assets

Add some detail meshes to your terrain.

Unity – Detail Meshes

If you make changes to detail meshes outside of Unity, the meshes are not automatically updated in your terrain. To tell unity to apply the changes you made to a detail mesh, select Terrain > Refresh Tree and Detail Prototypes from the main menu.

The last button on the Terrain toolbar is the Terrain Settings.

Unity – Terrain Setttings

The properties of the Terrain Settings are split into three categories; Base Terrain, Tree & Detail Objects, and Wind Settings.

The Base Terrain settings affect the terrain mesh itself.

• Pixel Error: This property controls the amount of allowable errors in the rendering of the Terrain geometry. Parts of the terrain that are far away from the viewer use less vertices to render. As the viewer approaches the terrain, the terrain will refine to a more detailed mesh. This is a rendering optimization. The Pixel Error controls how much error can occur then the terrain is far away. Higher values can result in better performance but more error.
  

  Unity – Pixel Error

• Base Map Dist.: The distance that Terrain textures will be displayed in high-resolution. After this distance, a low-resolution composite texture will be displayed.
• Cast Shadows: Should the terrain cast shadows?

The Tree & Detail Objects settings effect the rendering of the Trees, detail grass, and detail meshes.

• Draw: Used to toggle the rendering of trees, grass, and detail meshes.
• Detail Distance: The distance from the camera that details will stop being rendered. The higher this value is, the farther away details will be visible. Raising this value could have a negative impact on rendering performance.
• Tree Distance: The distance from the camera that trees will stop being rendered. The higher this value is, the farther away trees will be visible.
• Billboard Start: The distance from the camera that trees will start appearing as Billboards instead of Meshes.
• Fade Length: The total distance delta that trees will use to transition from Billboard orientation to Mesh orientation.
• Max Mesh Trees: The maximum number of trees that will be drawn as Meshes.

The Wind Settings control how wind is simulated over the trees and grass on the terrain.

• Speed: The speed that wind blows through grass. Setting this value to 0 will top the wind from blowing, but the grass may appear bent in some areas.
• Size: The areas of grass that are affected by wind all at once.
• Bending: The amount that grass will bend due to wind. Setting this value to 0 will prevent the grass from bending. Setting this value too high may cause the grass to bend too much and will produce unnatural results.
• Grass Tint: As the wind blows over the grass, at tint can be applied to the grass and detail meshes. This gives the wind effect a bit more realism but this color should be subtle otherwise it will look unnatural.

For better performance, terrains can be lightmapped just like any other static object in the scene. For terrains to be considered for lightmpping, they must be marked as Lightmap Static (by default, this should already be the case for terrains).

Lightmapping was covered in a previous article titled Rendering and Special Effects in Unity.

Unity provides a very powerful terrain engine with a lot of features such as grass, trees, and detail meshes. But even with all of these features, it is very difficult to get exactly the result you want. You must take care not to create too much detail near where the player can walk because colliders for detail meshes need to be created by hand.

But with enough skill and effort, it is possible to create very appealing terrains in a short time.

Unity Terrain Engine Guide (http://docs.unity3d.com/Documentation/Components/script-Terrain.html)

Unity Particles

In this article I will introduce the Shuriken Particle System that was added to Unity in version 3.5.

Particle effects are an integral component of a polished video game. They add that extra flash, fizzle, and pop that makes a good game a great game. When used correctly particle effects can add that subtle bit of realism that draws the player into the game allowing them to feel, see, and maybe even smell your gameplay.

In Unity (and throughout this document) the terms Particle System and Particle Effect are used interchangeably however these two terms have different meanings.

• Particle System: This is a single Particle System component that is attached to a GameObject.
• Particle Effect: This refers to a hierarchical composition of GameObjects each with their own Particle System component. In other words, a combination of Particle Systems which together compose a Particle Effect.

The component that provides the Shuriken Particle System functionality in Unity is the Particle System component. You can add a particle system to your scene in multiple ways.

• Create a Particle System GameObject.
• Create a GameObject and add the Particle System component.

To create a Particle System in your scene, you can either create a new Particle System GameObject by selecting GameObject > Create Other > Particle System from the main menu.

Unity – Create New Particle System

You can also create an empty GameObject in the scene and add a Particle System component to it by selecting Component > Effects > Particle System from the main menu.

Unity – Particle System Component

Using either method should create a GameObject with a Particle System component attached to it. In the Inspector you will see the default particle system component.

Unity – Particle System Inspector

I will discuss the individual modules in a later section.

When you select a GameObject that has a Particle System component attached to it, the Particle Effect Preview Panel will appear in the Scene view.

Unity – Particle Effect Preview Panel

The Particle Effect Preview Panel allows you to Pause, Simulate, and Stop the particle effect simulation in the Scene view.

While the Particle Effect is being simulated or paused, you can also change the value of the Playback Time to see how the particle effect will appear at certain times. It is also possible to scrub the Playback Time so that you can see how the Particle Effect changes over time.

You can open the Particle Effects view by selecting Window > Particle Effect from the main menu or by clicking the Open Editor… button on the Particle System component in the Inspector.

Unity – Open Particle Effect View

The Particle Effect view should open and display the Particle System component of the currently selected GameObject.

Unity – Particle Effect View

If you select a GameObject in the Scene view or the Hierarchy view that does not have a Particle System component then the Particle Effect view may be empty.

The Particle Effect view consists of three primary panels:

• Toolbar: Provides buttons to Simulate/Pause and stop the Particle Effect in the Scene view
• Particle System Editor: Provides access to the properties of the Particle System components.
• Curve Editor: Allows you to manipulate the values of the Particle System properties using curves.

The toolbar at the top of the Particle Effect view allows you to control a few aspects of the Particle Effect displayed in the scene view as well as the layout of the different panels in the Particle Effect View.

Unity – Particle Effect View Toolbar

The Pause/Simulate and Stop buttons on the toolbar in the Particle Effect view allow you to start and stop the Particle Effect simulation in the Scene view and the Game view. These buttons operate exactly the same way as the Particle Effect Preview Panel that appears in the Scene view when a GameObject with a Particle System component is selected.

The Show: All/Selected button will toggle the view of the particle systems shown in the Particle Effect view and in the Scene view. With Show: All selected, all of the Particle System components will be visible in the Particle Effect view and in the Scene view. With Show: Selected selected, only the currenlty selected Particle System component will appear in the Scene view and the other Particle System components will appear darker in the Particle Effect view.

Unity – Particle Effect View (Show All)

Unity – Particle Effect View (Show Selected)

You will still be able to make changes to the other Particle System components in the Particle Effect view but they will not be visible in the Scene view or the Game view and the Particle System component will appear dimmed in the Particle Effect view.

In addition, the currently selected Particle System component will display a blue outline to indicate that it is the currently selected Particle System (as shown in the images above).

If the Resimulate toggle button is enabled the the Particle Effect will be updated when changes to the Particle System properties are made and those changes will be immediately visible in the Scene view. If this option is not selected then you must manually resimulate the Particle Effect to see the changes you made.

The Wireframe toggle button to preview the Particle Effect in the Scene view with wireframes turned on for the billboard and mesh particles. In addition to the wireframe for the particles, the screen-space bounding box for each Particle System is also displayed in the Scene view.

Unity – Particle Effect View (Wireframe)

The Layout button allows you to swap between a horizontal layout and a vertical layout. Using the horizontal layout the Particle System components will appear in the left panel and the Curve Editor will appear in the right panel. Using the vertical layout the Particle System components will appear in the top panel and the Curve Editor will appear in the bottom panel.

Unity – Particle Effect View (Horizontal Layout)

Unity – Particle Effect View (Vertical Layout)

The Lock Selected toggle button will keep the currently selected Particle Effect visible in the Particle Effect view even if you change the currently selected GameObject in the Scene view or the Hierarchy view.

The Curve Editor is used to manipulate the curves for specific properties of the Particle System components.

Unity – Particle Effect Curve Editor

In the image above, the Start Size property of the Flare Particle System is selected and viewable in the Curve Editor.

The Particle System components have several properties that can have a scalar numeric value (such as the Duration and Start Delay properties), or a boolean value (such as the Looping and the Prewarm properties) but there are also a few properties that allow you to select the value type of the property using the drop-down arrow shown to the right of the property (such as can be seen on the the Start Lifetime, Start Speed, and Start Size properties).

Unity – Particle System Property Type

There are different options in this drop-down menu depending on whether you are editing a numeric property or a color (or gradient) property.

For numeric properties you can change the type of the value to one of the following types:

• Constant: Choose a single numeric value that will be used over the entire duration of the Particle System simulation or over the entire lifetime of the particle (depending on the selected module)
• Curve: The value of the property will be determined by a value on a curve at the time during the Particle System simulation or at a time during the lifetime of the particle (depending on the selected module).
• Random Between Two Constants: Allows you to specify a minimum and maximum value that will used to select a random value between those two points.
• Random Between Two Curves: Unity will create a random curve that lies between the minimum and maximum curves. The current value will be chosen based on the current time of the Particle System simulation or the lifetime of the particle depending on the selected module.

If a numeric property has a Constant value type then the value of the property will not change over the duration of the Particle System simulation or the lifetime of the particle. No curve will be visible in the curve editor in this case. For example, the Start Lifetime property is set to be a Constant value.

Unity – Particle System Numeric Property (Constant)

A Constant property will not be displayed in the Curve Editor.

If a numeric property has a Curve value type then the value of the property will be determined by the value of the curve (displayed in the curve editor) at a specific time during the simulation of the Particle System or at the lifetime of the particle (depending on the module).

Unity – Particle System Numeric Property (Curve)

The image above shows the Start Size property is selected and its Curve property is shown in the Curve Editor.

If a numeric property is set to a Random Between Two Constants type then the value of the property will be a random value between a minimum and maximum values.

Unity – Particle System Numeric Property (Random Between Two Constants)

In the image above the Start Lifetime property is set to a Random Between Two Constants with a minimum value of 0 and a maximum value of 0.05.

If you select a Random Between Two Constants then there will not be a graph in the Curve Editor for that property.

If a numeric property is set to a Random Between Two Curves then the value of the property will be determined by a randomly generated curve that fits within the minimum and maximum curves.

Unity – Particle System Numeric Property (Random Between Two Curves)

In this image the Start Lifetime property is shown with a minimum and maximum curve. The shaded area between the two curves is the area in which the randomly generated curve will exist.

Some properties of the Particle System do not use numeric values but instead use colors or gradients. For example, the Start Color property allows you to specify a color as it’s value.

Similar to numeric properties, color properties can be one of the following types:

• Color: Use a single color over the duration of the Particle System simulation or the lifetime of the Particle depending on the module.
• Gradient: Use a gradient to specify the color value over the duration of the Particle System simulation or the lifetime of the Particle depending on the module.
• Random Between Two Colors: A random color is chosen between two color values.
• Random Between Two Gradients: A random gradient is chosen between two gradient values.

Unity – Particle System Color Property

Color properties never use the Curve Editor. Instead, colors use the Color Picker and gradients use the Gradient Editor.

If you specify that a color property should be a single Color value, then you will use the Color Picker to determine the color of the property over the duration of the Particle System simulation or the lifetime of the particle depending on the module.

Unity – Particle System Color Property (Color)

If you specify that a color property should be a Gradient value, then you will use the Gradient Editor to determine the color of the property over the duration of the Particle System simulation or the lifetime of the particle depending on the module.

Unity – Particle System Color Property (Gradient)

The Random Between Two Colors type allows you to specify two color values. The color that is chosen is a random color that lies somewhere between these two colors.

Unity – Particle System Color Property (Random Between Colors)

The Random Between Two Gradients type allows you to specify two gradients. The color of the property is determined by a random gradient that is created based on the two gradients.

Unity – Particle System Color Property (Random Between Two Gradients)

Each Particle System consists of several modules that are shown in the Inspector and in the Particle Effect view. Each module controls different aspects of the Particle System.

The following modules are available to each Particle System component:

• Initial Module: Defines properties that are used to initialize the particles. This module cannot be disabled.
• Emission Module: Controls the emission rate of particles.
• Shape Module: Defines the shape of the particle emitter.
• Velocity over Lifetime Module: Used to control the velocity of the particles over their lifetime.
• Limit Velocity over Lifetime Module: Limits the speed of the particles over their lifetime.
• Force over Lifetime Module: Applies a force to the particles over their lifetime.
• Color over Lifetime Module: Adjusts the color of the particles over their lifetime.
• Color by Speed Module: Adjusts the color of the particles based on their speed.
• Size over Lifetime Module: Controls the size of the particles over their lifetime.
• Size by Speed Module: Controls the size of the particles based on their speed.
• Rotation over Lifetime Module: Adjusts the particles angular velocity (rate of rotation) over their lifetime.
• Rotation by Speed Module: Adjusts the particles angular velocity (rate of rotation) based on their speed.
• Collision Module: The collision module uses a set of transforms that define collision planes for which the particles will collide with.
• Sub Emitters Module: Allows the creation of other particle systems during particle birth, death, and collision.
• Texture Sheet Animation Module: Allows you to define a sprite sheet that will be used to animate the texture of the particles over their lifetime.
• Renderer Module: Defines the properties that are required to visually render the particles (such as the particle’s Material).

The Initial Module is always present on every Particle System and it cannot be removed or disabled. This module controls how each particle is initialized when it is emitted.

Unity – Particle System Modules (Initial)

The Initial Module defines the following properties:

• Duration: The duration in seconds that the particle system will emit particles.
• Looping: If you need the particle system to keep emitting particles even after the duration, then set this property to true.
• Prewarm: If the Particle System is set to Looping then enabling this parameter will cause the particle system to appear that it has already emitted particle for one cycle when it is created. This is useful for effects like fountains and waterfalls where a warm-up cycle would be visible to the player. Only looping Particle Systems can be prewarmed.
• Start Delay: The delay in seconds before this particle system will start emitting particles. Particle Systems that are both Looping and Prewarm cannot have a Start Delay value and in such a case this property will be disabled.
• Start Lifetime: The lifetime in seconds of the particles from the time that they are emitted.
• Start Speed: The initial speed of the particle when it is emitted.
• Start Size: The initial size of the particle when it is emitted.
• Start Rotation: The initial rotation of the particle measured in degrees when it is emitted.
• Start Color: The initial color of the particle when it is emitted.
• Gravity Modifier: The global gravity vector is first multiplied by this value before being applied to the particles. To make particles move upwards (useful for smoke) make this value negative.
• Inherit Velocity: How much of the linear velocity of the Particle System’s Transform node is used to determine the initial velocity of the particle. This is used to simulate conservation of momentum. This only has an influence if the Particle System GameObject is moving.
• Simulation Space: Should the particle be simulated relative to Particle System Transform (Local space) node or relative to the origin of the world (World space).
• Play On Awake: Should the Particle System automatically start emitting particles as soon as it is created.
• Max Particles: The maximum number of particles that this Particle System will ever have at any moment.

The Emission Moduele defines the rate at which particles are emitted from the Particle System. The Emission Module also allows you to define particle bursts when a large number of particles are emitted at certain intervals over the duration of the Particle System simulation.

Unity – Particle System Modules (Emission Module)

The Emission Module defines the following properties:

• Rate: The number of particles that are emitted. If the nameless drop-down parameter under Rate is set to Time then this parameter determines the number of particles that are emitted per second. If the drop-down parameter is set to Distance then this parameter determines the number of particles that are emitted per world unit (per meter).
• Burst: The Burst parameter allows you to specify specific intervals at which extra particles should be emitted. The Time of the burst is measured in seconds since the particle simulation started. The Particles property determines that number of particles that will be emitted at that time. Burst intervals can be added and removed using the (+) and (-) buttons next to the burst parameter.

The Shape Modules determines the shape of the area that emits particles. The properties that appear here are determined by the Shape parameter.

The Shape parameter can have one of the following values:

• Sphere: The shape of the emitter resembles a 3D sphere.
• Hemisphere: The shape of the emitter resembles a half-sphere. The hemisphere is always in the local positive Z axis (relative to the GameObject)
• Cone: The shape of the emitter resembles a cone. The cone is always in the direction of the local positive Z axis.
• Box: The shape of the emitter resembles a 3D box.
• Mesh: Particles will be emitted from either the vertex, edge, or triangles of a mesh. The mesh can either be an asset in the project folder or a mesh that has been placed in the scene (via a GameObject).

The Sphere shape emitter defines a 3D sphere that defines the shape of the area in which particles are emitted.

Unity – Particle System Modules (Shape Module – Sphere)

The Sphere Shape emitter has the following properties:

• Radius: The radius of the sphere in world units.
• Emit from Shell: If checked, then particles will only be emitted from the shell of the sphere (at a distance exactly equal to Radius from the origin of the Particle System). Otherwise, particles will be emitted randomly at a distance less than the Radius from the origin of the Particle System.
• Random Direction: If checked particles will be emitted in random directions. Otherwise particles will be emitted outward from the center of the sphere.

The HemiSphere shape emitter will emit particle in the shape of a half-circle. The HemiSphere is always in the direction of the local Z-axis.

Unity – Particle System Modules Shape Module – HemiSphere)

The HemiSphere Shape emitter has the following properties:

• Radius: The radius of the hemi-sphere in world units.
• Emit from Shell: If checked, then particles will only be emitted from the shell of the hemi-sphere (at a distance exactly equal to Radius from the origin of the Particle System). Otherwise, particles will be emitted randomly at a distance less than the Radius from the origin of the Particle System.
• Random Direction: If checked particles will be emitted in random directions. Otherwise particles will be emitted outward from the center of the hemi-sphere.

The Cone shape emitter defines a cone that has its apex at the origin of the ParticleSystem and is in the direction of the positive local Z-axis. Particles are emitted at a random angle from the apex of the Cone in the direction of the positive local Z-axis..

Unity – Particle System Modules (Shape Module – Cone)

The Cone shape emitter has the following properties:

• Angle: The maximum angle that particle will be emitted in the direction of the Cone.
• Radius: This parameter allows you to determine the radius of the apex of the Cone. A radius of 0 indicates the particles will be emitted exactly at the apex of the Cone. A larger radius will enlarge the apex in which particles can be emitted.

Unity – Particle System Module (Cone Emitter)

The image shows a Cone shape emitter. The smaller end of the cone is called the apex and the larger part of the cone is called the base. The length of the cone is determined by the Start Speed parameter of the Initial Module. The particles are only emitted from the apex of the cone.

The shape of the emitter will resemble a 3D box. The box will always be orientated according to the orientation of the Particle System‘s Transform node. Particles will be emitted at a random position within the volume of the box.

Unity – Particle System Modules (Shape Module – Box)

The Box shape emitter has the following properties:

• Box X, Y, Z: The size of the box measured in world-units in each the X, Y, and Z axis.
• Random Direction: If checked particles will be emitted in random directions. Otherwise particles will be emitted in the direction of the local Z-axis.

The Mesh shape emitter allows you to specify a mesh that determines the area in which the particles are emitted. You can specify that the particles should be emitted at a random vertex, edge, or triangle face of the mesh.

Unity – Particle System Modules (Shape Module – Mesh)

The Mesh shape emitter has the following properties:

• Vertex, Edge, Triangle: This drop-down box determines how the particles are emitted from the mesh. Vertex specifies that the particles will be emitted at a random vertex of the mesh. Particles will be emitted in the direction of the vertex normal. Edge specifies that the particles will be emitted at a random edge (an edge connects any two vertices) on the mesh. Particles will be emitted at an interpolated directed based on the direction of the vertex normals of the two vertices that define the edge. Triangle specifies that particles will be emitted from the triangle faces of the mesh. Particles will be emitted in the direction of the face normal for that triangle.

The Velocity over Lifetime module allows you to animate the velocity of the particle over its lifetime.

Unity – Particle System Modules (Velocity over Lifetime)

The Velocity over Lifetime has the following properties:

• X, Y, Z: The direction of the velocity vector. These values can be either a Constant, Curve, Random Between Two Constants, or a Random Between Two Curves.
• Space: Whether the velocity vector is expressed in Local-Space or World-Space.

The Limit Velocity over Lifetime module allows you to restrict the maximum velocity or speed of the particle over it’s lifetime.

Unity – Particle System Modules (Limit Velocity over Lifetime)

The Limit Velocity over Lifetime module has the following properties:

• Separate Axis: If enabled, then the next parameter will be the X, Y, and Z axis of maximum velocity the particle can have before being dampened. Otherwise the next parameter will be Speed which is used to limit the maximum magnitude of the particles velocity vector.
• X, Y, Z: If Separate Axis is enabled then these values represent the X, Y, and Z axis of the maximum velocity vector.
• Speed: If Separate Axis is not enabled then the Speed parameter determines the maximum magnitude of the particle’s velocity vector.

The Force over Lifetime module is used to apply a force to the particle that will effect it’s velocity. This can be used to create turbulent particle for example sparks from a fire or snowflakes that are influenced by wind.

Unity – Particle System Modules (Force over Lifetime)

The Force over Lifetime module has the following properties:

• X, Y, Z: The X, Y, and Z components of the force vector to apply to the particle. This value can be either Constant, Curve, Random Between Two Constants, or a Random Between Two Curves.
• Space: Determines whether the force vector is expressed in Local-Space or World-Space.
• Randomize: If enabled, the magnitude of the force vector will be randomized. This parameter only becomes available if the force parameter is set to either Random Between Two Constants or Random Between Two Curves.

The Color over Lifetime module allows you to specify the color of the particle over it’s lifetime.

Unity – Particle System Modules (Color over Lifetime)

This module only has a single parameter called Color which can be either a Gradient or a Random Between Two Gradients.

For example, the following gradient will cause the particle to start as a red particle and transition through all of the colors of the rainbow and fade-out over the last 25% of it’s life.

Unity – Gradient Editor

The Color by Speed module will adjust the color of the particle based on its speed (the magnitude of the velocity vector).

Unity – Particle System Modules (Color by Speed)

The Color by Speed module has the following properties:

• Color: Defines a gradient that will be used to determine the color of the particle based on its speed. This value can be a Gradient or a Random Between Two Gradients
• Speed Range: Used to map the speed of the particle to a color. If the particle has a minimum speed it will map to the color of the gradient at 0%. If the particle has the maximum speed then then it will map to the color of the gradient at 100%.

For example, the following gradient will cause the particle to turn red as it approaches the maximum speed.

Unity – Gradient Editor

The Size over Lifetime module allows you to control the scale of the particle over it’s lifetime.

Unity – Particle System Modules (Size Over Lifetime)

The Size over Lifetime module defines a single parameter that can be either a Curve, Random Between Two Constants, or a Random Between Two Curves.

For with the curve shown in the image below will start the particles with a scale of 0 at the beginning of its lifetime and steadily scale to full size near the end of the particle’s lifetime.

Unity – Particle System Modules (Size Over Lifetime Curve)

The Size by Speed module allows you to specify the scale of the particle based on its speed.

Unity – Particle System Modules (Size by Speed)

The Size by Speed module defines the following properties:

• Size: The size of the particle based on its speed. This parameter can be a Curve, Random Between Two Constants, or a Random Between Two Curves.
• Speed Range: Maps the maximum and minimum speeds to a value on the Speed curve.

The Rotation over Lifetime module controls the angular velocity of the particle over its lifetime.

Unity – Particle System Modules (Rotation over Lifetime)

The Rotation over Lifetime module defines a single property called Angular Velocity. This property controls the rotation of the particle in degrees per second over the lifetime of the particle. This property can be a Constant, Curve, Random Between Two Constants, or a Random Between Two Curves.

The Rotation by Speed module controls the angular velocity of the particle based on its speed (magnitude of the velocity vector).

Unity – Particle System Modules (Rotation by Speed)

The Rotation by Speed module defines the following properties:

• Angular Velocity: Used to control the rotation of the particle in degrees per second based on its speed. This property can be a Constant, Curve, Random Between Two Constants, or a Random Between Two Curves.
• Speed Range: Maps the minimum and maximum speeds to a value in the Angular Velocity property. If the Angular Velocity is a Constant then the Angular Velocity of the particle will be the same regardless of its speed.

The Collision module allows you to specify a set of Transform nodes that will be used to perform collision with the particles in this Particle System.

Unity – Particle System Modules (Collision)

The Collision module defines the following properties:

• Planes: The Planes property is an array of maximum 6 Transform nodes that are used to define the position and orientation of invisible planes in the scene. It is not necessary that the Transform that you assign in this list actually have a Plane mesh assigned to it. The local Y-axis of the Transform node is used to determine the normal of the plane (that is, the local Y-axis of the Transform node points up in the direction of the plane). You can add up to 6 planes to this list by pressing the (+) button and you can remove planes from the list by pressing the (-) button.
• Dampen: How much of the speed of the particle is reduced when a collision occurs. A value of 0.5 will reduce the particle to half of its current speed. This property can have a value in the range 0 to 1.
• Bounce: How much the particle will bounce. If this value is 1, then 100% of the particles vertical motion is maintained. If this value is 0 then it will not bounce at all. This parameter can have a value in the range 0 to 1.
• Lifetime Loss: How much of the particle’s Start Lifetime is lost when a collision occurs. If you want the particle to die as soon as it collides then set this parameter to 1. This value can have a value in the range 0 to 1.
• Visualization: The Visualization parameter will draw virtual planes in the Scene view and the Game view to help you determine where the planes are located relative to the Particle System. These planes will not be visible in the final game. This property can have the value Plane or Grid which determine how the virtual plane is rendered. Adjusting the Transform node that is used to define the plane will not update the virtual plane in the Scene view or the Game view (I think this is a bug).
• Scale Plane: Determines the scale of the virtual plane.

The Sub Emitters module allows you to spawn additional particle systems when a particle is emitted (birth), or if it collides with a virtual plane, or on particle death.

Unity – Particle System Modules (Sub Emitters)

The Sub Emitters module defines the following properties:

• Birth: The Particle System to spawn when the particle is emitted.
• Death: The Particle System to spawn when the lifetime of the particle reaches 0.
• Collision: The Particle System to spawn when the particle collides with one of the virtual planes defined in Collision module.

If you assign a Particle System as a sub emitter of another Particle System then the assigned Particle System will not start playing when the Particle Effect is started. In addition to this, spawned Particle System will inherit the position of the particle which spawned it.

The Texture Sheet Animation module allows you to animate the texture coordinates of the particle over its lifetime. This module uses the size of the texture assigned to the Material property of the Renderer module (discussed next) to determine the size of each tile of the sprite sheet.

This module allows you to create a sprite sheet of animated sprites that will be used to created animated textures for your particles.

Unity – Particle System Modules (Texture Sheet Animation)

The Texture Sheet Animation module defines the following properties:

• Tiles: The number of tiles in the X and Y directions in the texture. For example, the value X = 2 and Y = 1 implies that there are 2 tiles per row and 1 row of tiles in the texture.
• Animation: The tiles can be animated Whole Sheet or Single Row. If you specify Whole Sheet for this property then every tile in the texture will be used to animation the particle. Single Row means that the particle should be animated using only a single row of tiles in the texture.
• Random Row: If checked, then one row of tiles will be chosen at random when the particle is emitted. This parameter is only available if Single Row property is chosen.
• Row: If Random Row is not checked then this property determines the row in the texture to be used for the texture animation.
• Frame over Time: Determines the frame to use over the lifetime of the particle. This property can be a Constant, Curve, Random Between Two Constants, or a Random Between Two Curves. To render each frame in sequence, use a linear increasing curve.
• Cycles: How many times the animation will loop during the lifetime of the particle. This value must be a whole number.

For example, the following image contains a single row of 2 tiles:

Sparks (2×1)

The Renderer module determines how the particles are rendered to the screen.

Unity – Particle System Modules (Renderer Module)

The Renderer module defines the following properties:

• Render Mode: Determines how the particles are rendered. The Render Mode property can have one of the following values:
  • Billboard: The particle is rendered as a screen-aligned quad. That is, the particle will always face the viewer.
  • Stretched Billboard: The particle will be screen aligned and it will be stretched according to the additional properties:
    • Camera Scale: How much of the speed of the camera is taken into consideration when determining the stretching of the particle. Setting this parameter to 0 will not apply any additional stretching of the particle if the camera is moving.
    • Speed Scale: The additional scaling of the particle along the particles velocity vector. Setting this value to 0 will not apply any additional scaling along the velocity vector of the particle.
    • Length Scale: Scales the length of the particle relative to its width. A value of 1 implies the particle is square.
  • Horizontal Billboard: The particle will be aligned to a horizontal plane in world-space. The particles will seem to disappear when viewed from the side.
  • Vertical Billboard: The particle will be aligned a vertical plane in world-space. The particles will seem to disappear when viewed from above or below.
  • Mesh: Renders each particle as a mesh.
    • Mesh: The Mesh property becomes available if the Render Mode is set to Mesh. This property determines the Mesh to use to represent the particle. This can be a Mesh asset in the Project or a Mesh that has been assigned to a GameObject in the Scene.
• Material: The Material that is used to render the particle.
• Sort Mode: Sorts the particles within the Particle System. Particles should only be sorted when unsorted particles cause rendering artifacts.
  • None: The particles are not sorted.
  • Distance: Particles closer to the camera will be drawn after particles further away. This ensures that alpha blended particles will be rendered correctly.
  • Youngest First: Particles are sorted by age and older particles will be drawn over younger particles.
  • Oldest First: Particles are sorted by age and younger particles will be drawn over older particles.
• Sorting Fudge: The Sorting Fudge property can be used to effect the draw order of Particle Systems. Particle Systems with a lower Sorting Fudge value will more likely be drawn last and thus appear in front of other transparent objects (including other particles).
• Cast Shadows: If enabled, the particles in the Particle System will cast shadows. The particle must be rendered using an opaque material (no alpha blending). This is useful for Mesh emitters with non-transparent materials.
• Receive Shadows: If enabled, then shadows will be cast on the particles in this Particle System. The particles must be rendered with opaque (non-transparent) material. This is useful for Mesh emitters with non-transparent materials.

Now that we have a understanding of the underlying components that makeup a Particle System let’s put our knowledge to good use and build a simple Particle Effect.

For this example, we will go through the steps to build a simple flare particle effect.

Open Unity and either create a new project or open an existing project.

Unity – Flare Particle Effect (1)

Download the following Unity Package and import it into your project.

ParticleEffects.unitypackage

You can import this package into your Unity project by double-clicking on the package file or by selecting Assets > Import Package > Custom Package… from the Main Menu in Unity.

Unity – Import ParticleEffects package

After you click the Import button, you should get the 3 textures imported into your project:

• Flare_Diffuse: The diffuse texture for the flare Particle System.
• Smoke_Diffuse: The diffuse texture for the smoke Particle System.
• Sparks_Tiles: A tile texture that contains 2 tiles of spark textures.

After you import this package, your project might look like this:

Unity – Flare Particle Effect (2)

Create a new Particle System GameObject by selecting GameObject > Create Other > Particle System from the Main Menu.

Unity – Flare Particle Effect (3)

This Particle System will be the root of the Particle Effect. Rename this GameObject to Flare Particle Effect.

Open the Particle Effect view by selecting Window > Particle Effect from the Main Menu or click the Open Editor… button on the Particle System component in the Inspector view.

Unity – Flare Particle Effect (4)

The first thing we’ll create are the Particle System that renders the sparks for our flare effect.

Set the following properties of the Initial Module:

• Duration: 5.00
• Looping: true
• Prewarm: true
• Start Lifetime: 0.05
• Start Speed: 0
• Start Size: Random Between Two Curves with a max curve at 1.0 and a minimum curve set to 0.5 as shown in the image below.

  

• Start Rotation: Random Between Two Curves with a max curve set at 180 and a min curve set at 0 as shown in the image below.

  

• Start Color: Random Between Two Colors:
  • First Color: White:
    • Red: 255
    • Green: 255
    • Blue: 255
    • Alpha: 255

    

  • Second Color: Light Orange:
    • Red: 255
    • Green: 198
    • Blue: 114
    • Alpha: 255

    

• Gravity Modifier: 0
• Inherit Velocity: 0
• Simulation Space: Local
• Play On Awake: true
• Max Particles: 2

You should have something similar to what is shown below.

Unity – Flare Particle Effect (5)

Next, make sure the Emission module is enabled and set the Rate parameter to 20. Make sure the units are set to Time.

Unity – Flare Particle Effect (6)

Expand the Shape module and set the following properties:

• Shape: Sphere
• Radius: 0.01
• Emit from Shell: false
• Random Direction: false

Unity – Flare Particle Effect (7)

For the next step, we need to create a new Material that will be used to render the particles for this Particle System.

Create a new Material in the Project view and call it Flare_Sparks.

Set the Shader to Particles > Additive and set the Tint Color to gray.

• Tint Color: Gray
  • Red: 128
  • Green: 128
  • Blue: 128
  • Alpha: 128
  

  Unity – Color Picker (Gray)

Particle Texture property to Sparks_Tiles(2×1) texture that you imported earlier. The Flare_Sparks material should look like this:

Unity – Flare_Sparks Material

Return to the Particle System and expand the Renderer module and set the following properties:

• Render Mode: Billboard
• Material: Flare_Sparks
• Sort Mode: None
• Sorting Fudge: 0
• Cast Shadows: false
• Receive Shadows: false
• Max Particle Size: 0.5


Unity – Flare Particle Effect (8)

You may have noticed that the sparks don’t look right yet. This is because we are using a tiled texture but we did not specify that in the Particle System.

Enable the Texture Sheet Animation module and set its properties to the following values:

• Tiles:
  • X: 2
  • Y: 1
• Animation: Whole Sheet
• Frame over Time: Random Between Two Constants with a minimum value of 0 and a maximum value of 2.
• Cycles: 1


Unity – Flare Particle Effect (9)

Smoke Particle System

Create a nested Particle System by clicking the (+) button in the Particle Effect view or add a nested GameObject to the Flare Particle Effect GameObject in the scene and add a Particle System component to it.



Unity – Flare Particle Effect (10)

Set the properties of the Initial module to the following values:

• Duration: 5
• Looping: true
• Prewarm: true
• Start Lifetime: 5
• Start Speed: 1
• Start Size: Random Between Two Curves with a maximum curve set to 3.4 and a minimum curve set to 1.75 as shown in the image below.

  

• Start Rotation: Random Between Two Curves with a max curve set at 180 and a min curve set at 0 as shown in the image below.

  

• Start Color: Dark-gary Color with the following components:
  • Red: 29
  • Green: 29
  • Blue: 29
  • Alpha: 255

  

• Gravity Modifier: -0.05
• Inherit Velocity: 0
• Simulation Space: Local
• Play On Awake: true
• Max Particles: 10000

You should have something similar to what is shown below.



Unity – Flare Particle Effect (11)

Next, expand the Emission module and set its properties to the following values:

• Rate: 5
• Units: Time
• Bursts:
  

  Time	Particles
  0.00	1
  2.00	1
  2.50	1



Unity – Flare Particle Effect (12)

Enable the Shape module and set its properties to the following values:

• Shape: Cone
• Angle: 25
• Radius: 0


Unity – Flare Particle Effect (13)

Instead of the smoke coming straight up, I would like the smoke to come out from the side. To modify the direction the Particle System is emitted, you must rotate the Transform node the Particle System is assigned to.

Select the Smoke Particle System GameObject in the Hierarchy view and rotate the game object so that it’s local Z axis is pointing to the side as shown in the image below:



Unity – Flare Particle Effect (14)

Enable the Color over Lifetime module and set the Color property to a Gradient similar to the gradient shown in the image below.



Unity – Smoke Particle System (Color over Life)

You should have something similar to what is shown below.



Unity – Flare Particle Effect (15)

Enable the Size over Lifetime module and set its Size property to a Curve resembling the curve shown below:



Unity – Smoke Particle System (Size over Lifetime)

This should result in something similar to what is shown below.



Unity – Flare Particle Effect (16)

Enable the Rotation over Lifetime module and set the Angular Velocity parameter to a Random Between Two Curves. Set the minimum curve to -15 and the maximum curve to +15 as shown in the image below.



Unity – Smoke Particle System (Rotation over Lifetime)

To render the Smoke particle let’s create a new Material using the Smoke_Diffuse texture that was imported from the Unity package. Call the new Material Flare_Smoke and set its properties to the following values:

• Shader: Particles/Additive
• Tint Color: White with 50% Alpha:
  • Red: 255
  • Green: 255
  • Blue: 255
  • Alpha: 128
• Particle Texture: Smoke_Diffuse


Unity – Flare Smoke Material

Expand the Renderer module and set its properties to the following values:

Render Mode: Billboard
• Material: Flare_Smoke
• Sort Mode: Oldest First
• Sorting Fudge: 0
• Cast Shadows: false
• Receive Shadows: false
• Max Particle Size: 1

This should result in something similar to what is shown below.



Unity – Flare Particle Effect (17)

The particle effect is already looking nice but lets add one more Particle System to our Particle Effect.

Sparks Particle System

For this particle system we will add some sparks that will emit from the center of the Particle Effect.

Add one more Particle System by clicking the (+) button in the Particle Effect view while the Flare Particle Effect is selected in the Hierarchy view. You can also add another Particle System GameObject in the scene and parent it to the Flare Particle Effect and zero the position and rotation.

Rename this new Particle System to Sparks Particle System.



Unity – Flare Particle Effect (18)

The the properties of the Initial module to the following values:

• Duration: 5.00
• Looping: true
• Prewarm: true
• Start Lifetime: 3
• Start Speed: Random Between Two Curves with a minimum curve at 3 and a maximum curve at 5 as shown in the image below:
  

  Unity – Sparks Particle System (Start Lifetime)

• Start Size: Random Between Two Constants with a minimum value of 0 and a maximum value of 0.03.
• Start Rotation: Random Between Two Curves with a minimum curve of -180 and a maximum curve of 180.
• Start Color: Random Between Two Colors:
  • First Color: White
    • Red: 255
    • Green: 255
    • Blue: 255
    • Alpha: 255
    

    Unity – Color Picker (White)

  • Second Color: Orange
    • Red: 255
    • Green: 144
    • Blue: 0
    • Alpha: 255
    

    Unity – Color Picker (Orange)

• Gravity Modifier: 1
• Inherit Velocity: 0
• Simulation Space: Local
• Play On Awake: true
• Max Particles: 10000

You should have something similar to the image shown below.



Unity – Flare Particle Effect (19)

Expand the Emission module and set the Rate to 50 and the units to Time.



Unity – Flare Particle Effect (20)

Expand the Shape module and set it properties to the following values:

• Shape: Sphere
• Radius: 0.02
• Emit from Shell: false
• Random Direction: false


Unity – Flare Particle Effect (21)

Enable the Color over Lifetime module and set the Color property to a Gradient that resembles the gradient shown in the image below.



Sparks Particle System (Color over Lifetime)

You should have something similar to what is shown below.



Unity – Flare Particle Effect (22)

Enable the Color by Speed module. Set the Color property to a Gradient that matches the Gradient shown in the image below.



Sparks Particle System (Color by Speed)

And set the Speed Range property to 0 to 1.

This should now look something like this:



Unity – Flare Particle Effect (23)

For the sparks, we’ll create a new Material called Flare_Flare.

Set the Materials Shader property to Particles/Alpha Blended and set the Tint Color to gray with 50% alpha:



Unity – Color Picker (Gray)

Set the Material’s Particle Texture property to the Flare_Diffuse texture that you imported from the Unity package.



Unity – Flare_Flare Material

Expand the Renderer module on the Sparks Particle System and set its properties to the following values:

• Renderer Mode: Stretched Billboard
• Camera Scale: 0
• Speed Scale: 0.05
• Length Scale: 1
• Material: Flare_Flare
• Sort Mode: None
• Sorting Fudge: 0
• Cast Shadows: false
• Receive Shadows: false
• Max Particle Size: 0.5

You should have sometime similar to what is shown below:



Unity – Flare Particle Effect (24)

At this point, the Particle Effect is finished. You can save a Prefab of the Particle Effect in your Project view so that you can create instances of it easily later.

There is one more effect I want to achieve and that’s to make the sparks do collision with the ground plane. This will allow the sparks to bounce off the ground and come to a rest before they fade away.

To achieve this, add an empty game object in the scene. Zero the position and rotation of the new GameObject. Rename this new GameObject to Flare Collider or something similar.

Select the Sparks Particle System and enable the Collision module and set its properties to the following values:

• Planes: Flare Collider (The empty GameObject we just created)
• Dampen: 0.5
• Bounce: 0.75
• Lifetime Loss: 0
• Min Kill Speed: 0
• Visualization: Solid
• Scale Plane: 1.00

If the Flare Particle Effect is at the same height as the Flare Collider GameObject, then move it up a bit in the Y-axis so it is above the virtual plane.

You should now see the sparks from the flare bouncing off the virtual plane.



Unity – Flare Particle Effect (25)

Congratulations. Your particle effect is finished.

Exercise

Try to create your own interesting particle effects.

References

Unity Manual – Particle Systems

The Particle Effect used in the article comes from the Unity 3.5 Developer Preview Page here:
http://unity3d.com/unity/preview/download. There is a link to download the ShurikenExamples.zip file at the bottom of the page that contains the Flare particle effect as well as several other interesting particle effects.

]]> http://3dgep.com/?feed=rss2&p=4313 6 http://3dgep.com/?p=4151 http://3dgep.com/?p=4151#comments Fri, 26 Oct 2012 20:56:54 +0000 Jeremiah van Oosten http://3dgep.com/?p=4151 Continue reading →]]>

CUDA 5

In this article, I will introduce the reader to CUDA 5.0. I will briefly talk about the architecture of the Kepler GPU (Graphics Processing Unit) and I will show you how you can take advantage of the many CUDA (Compute Unified Device Architecture) cores in the GPU to create massively parallel programs.

Table of Contents

1. List of Figures
2. List of Tables
3. Introduction
4. Kepler Architecture
   1. Dynamic Parallelism
   2. Hyper-Q
   3. Grid Management Unit
   4. NVIDIA GPUDirect
5. Getting Started with CUDA
   1. System Requirements
   2. Verify your GPU
   3. Install CUDA
   4. Verify the Installation
   5. Run Compiled Sample
6. Creating your First Project
7. Threading Model
   1. CUDA Threads
   2. Matrix Addition Example
   3. The Matrix Addition Kernel Function
8. Thread Synchronization
9. Thread Assignment
10. Thread Scheduling
11. Thread Divergence
12. Memory Model
13. CUDA Memory Types
    1. Register
    2. Local
    3. Shared
    4. Global
    5. Constant
14. Properties of Memory
15. Pointers to Memory
16. Minimize Global Memory Access
    1. Matrix Multiply using Global Memory
    2. Matrix Multiply using Shared Memory
17. Resources as a Limiting Constraint
18. CUDA GPU Occupancy Calculator
19. Exercises
20. References

 

List of Figures

Figure 1. Floating Point Operations per Second
Figure 2. Memory Bandwidth
Figure 3. Kepler GK110 Die
Figure 4. Kepler Architecture
Figure 5. Kepler Streaming Multiprocessor (SMX)
Figure 6. Warp Scheduler
Figure 7. Dynamic Parallelism
Figure 8. Dynamic Parallelism
Figure 9. Hyper-Q
Figure 10. Grid Management Unit
Figure 11. GPUDirect
Figure 12. Control Panel
Figure 13. System Manager
Figure 14. Device Manager
Figure 15. Command Prompt
Figure 16. Device Query
Figure 17. New Project Dialog
Figure 18. Cuda Execution Model
Figure 19. CUDA Grid Example
Figure 20. Warp Scheduler
Figure 21. Thread Divergence
Figure 22. CUDA Memory Model
Figure 23. Matrix Multiply – Global Memory
Figure 24. Tiles
Figure 25. Matrix Multiply – Tiles
Figure 26. CUDA Occupancy Calculator

List of Tables

Table 1. Threading Compute Capability
Table 2. Memory Compute Capability
Table 3. Properties of Memory Types

Introduction

Using the power of the NVIDIA GPU, CUDA allows the programmer to create highly parallel applications that can perform hundreds of times faster than an equivalent program that is written to run on the CPU alone. The NVIDIA CUDA Tookit provides several API’s for integrating a CUDA program into your C and C++ applications.

CUDA supports a heterogeneous programming environment where parts of the application code is written for the CPU and other parts of the application are written to execute on the GPU. The application is compiled into a single executable that can run on both devices simultaneously.

In a CUDA intensive application, the CPU is used to allocate CUDA memory buffers, execute CUDA kernels and retrieve and analyze the result of running a kernel on the GPU. The GPU is used to synchronously process large amounts of data or to execute a simulation that can easily be split into a large grid where each grid executes a part of the simulation in parallel.

The NVIDIA GPU consists of hundreds (even thousands) of CUDA cores that can work in parallel to operate on extremely large datasets in a very short time. For this reason, the NVIDIA GPU is much more suited to work in a highly parallel nature than the CPU.

The image below shows the computing power of the GPU and how it compares to the CPU. The vertical axis shows the theoretical GFLOP/s (Giga Floating Point Operations per Second). The horizontal axis shows the advances in technology over the years^[1].



Figure 1. Floating Point Operations Per Second

As can be seen from the image, the latest GPU from NVIDIA (The GTX 680 at the time of this writing) can theoretically perform 3 Trillion () Floating Point Operations per Second (or 3 teraFLOPS)^[1].

The GPU is also capable of transferring large amounts of data through the AGP bus. The image below shows the memory bandwidth in GB/s of the latest NVIDIA GPU compared to the latest desktop CPUs from Intel^[1].



Figure 2. Memory Bandwidth

In this article, I will introduce the latest GPU architecture from NVIDIA: Kepler. I will also introduce the CUDA threading model and demonstrate how you can execute a CUDA kernel in a C++ application. I will also introduce the CUDA memory model and I will show how you can optimize your CUDA application by making use of shared memory.

Kepler Architecture

Kepler is the name given to the latest line of desktop GPUs from NVIDIA. It is currently NVIDIA’s flagship GPU replacing the Fermi architecture.

The Kepler GPU consits of 7.1 billion transistors^[2] making it the fastest and most complex microprocessor ever built.



Figure 3. Kepler GK110 Die

Despite it’s huge transistor count, the Kepler GPU is much more power efficient than its predecessor delivering up to 3x the performance per watt of the Fermi architecture^[2].

The Kepler GPU was designed to be the highest performing GPU in the world. The Kepler GK110 consists of 15 SMX (streaming multiprocessor) units and six 64-bit memory controllers^[2] as shown in the image below.



Figure 4. Kepler Architecture

If we zoom into a single SMX unit, we see that each SMX unit consists of 192 single-precision CUDA cores, 64 double-precision units, 32 special function units (SFU), and 32 load/store units (LD/ST).



Figure 5. Kepler Streaming Multiprocessor (SMX)

The 192 single-precision CUDA cores each contain a single-precision floating-point unit (FPU) as well as a 32-bit integer arithmetic logic unit (ALU).

Each SMX supports 64 KB of shared memory, and 48 KB of read-only data cache. The shared memory and the data cache are accessible to all threads executing on the same streaming multiprocessor. Access to these memory areas is highly optimized and should be favored over accessing memory in global DRAM.

The SMX will schedule 32 threads in a group called a warp. Using compute capability 3.5, the GK110 GPU can schedule 64 warps per SMX for a total of 2,048 threads that can be resident in a single SMX at a time (not all threads will be active at the same time as we will see in the section describing the threading model).

Each SMX has four warp schedulers and eight instruction dispatch units (two dispatch units per warp scheduler) allowing four warps to be issued and executed concurrently on the streaming multiprocessor^[2].



Figure 6. Warp Scheduler

Dynamic Parallelism

The GK110 GPU supports a feature called Dynamic Parallelism. Dynamic Parallelism allows the GPU to create new work for itself by creating new kernels as they are needed without the intervention of the CPU.



Figure 7. Dynamic Parallelism

As can be seen from the image, on the left, the Fermi GPU requires the CPU to execute kernels on the GPU. On the right side of the image, the Kepler GPU is capable of launching kernels from within a kernel itself. No intervention from the CPU is required.

This allows the GPU kernel to be more adaptive to dynamic branching and recursive algorithms which has some impact on the way we can implement certain functions on the GPU (such as Ray Tracing, Path Tracing and other rasterization techniques).

Dynamic Parallelism also allows the programmer to better load-balance their GPU based application. Threads can by dynamically launched based on the amount of work that needs to be performed in a particular region of the grid domain. In this case, the initial compute grid can be very coarse and the kernel can dynamically refine the grid size depending on the amount of work that needs to be performed.



Figure 8. Dynamic Parallelism

As can be seen from the image, the left grid granularity is too coarse to produce an accurate simulation. The grid in the center is too fine and many kernels are not performing any actual work. On the right image we see that using dynamic parallelism, the grid can be dynamically refined to produce just the right balance between granularity and workload.

Hyper-Q

The Fermi architecture relied on a single hardware work queue to schedule work from multiple streams. This resulted in false intra-stream dependencies requiring dependent kernels within one stream to complete before additional kernels in a separate stream could be executed^[2].

The Kepler GK110 resolves this false intra-stream dependency with the introduction of the Hyper-Q feature. Hyper-Q increases the total number of hardware work-queues to 32 compared to the single work-queue of the Fermi architecture.



Figure 9. Hyper-Q

CUDA applications that utilize multiple streams will immeditaly benifit from the multiple hardware work queues offered by the Hyper-Q feature. These stream intensive applications can see a potential increase in performance of up to 32x^[2].

Grid Management Unit

In order to facilitate the Dynamic Parallelism feature introduced in the GK110 GPU a new Grid Managment Unit (GMU) needed to be designed. In the previous Fermi architecture, grids were passed to the CUDA Work Distributor (CWD) directly form the stream queue. Since it is now possible to execute more kernels directly in a running CUDA kernel, a bi-directional communication link is required from the SMX to the CWD via the GMU.



Figure 10. Grid Management Unit

NVIDIA GPUDirect

The Kepler GK110 supports the Remote Direct Memory Access (RDMA) feature in NVIDIA GPUDirect^[2]. GPUDirect allows data to be transferred directly from one GPU to another via 3rd-party devices such as InfiniBand (IB), Network Interface Cards (NIC), and Solid-State disc drives (SSD).



Figure 11. GPUDirect

Getting Started with CUDA

In this article, I will use Visual Studio 2010 to create a CUDA enabled application. The settings and configurations for Visual Studio 2008 will be similar and you should be able to follow along even if you have not yet upgraded to VS2010.

System Requirements

Before you can run a CUDA program, you must make sure that your system meets the minimum requirements.

• CUDA-capable GPU
• Microsoft Windows XP, Vista, 7, or 8 or Windows Server 2003 or 2008
• NVIDIA CUDA Toolkit
• Microsoft Visual Studio 2008 or 2010 or a corresponding version of Microsoft Visual C++ Express

Verify your GPU

To verify you have a CUDA enabled GPU first check the graphics device you have installed.

1. Open the Contol Panel from the Start Menu.
   

   Figure 12. Control Panel

2. Double-Click the System applet to open the System Control Panel.
3. In Windows XP, click on the Hardware tab then click the Device Manager button. In Windows 7 click the Device Manager link.
   

   Figure 13. System Manager

4. In the Device Manager window that appears, expand the Display Adapters node in the device tree.
   

   Figure 14. Device Manager

   If your device is listed at https://developer.nvidia.com/cuda-gpus then you have a CUDA-capable GPU.

Install CUDA

Download and install the latest NVIDIA CUDA Toolkit. The CUDA Toolkit is available at https://developer.nvidia.com/cuda-downloads.

At the time of this writing, the latest version of the CUDA toolkit is CUDA 5.0 Production Release.

The CUDA Toolkit contains the drivers and tools needed to create, build and run a CUDA application as well as libraries, header files, and CUDA samples source code and other resource^[3].

By default, the CUDA toolkit is installed to C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v#.#, where #.# refers to the CUDA version you have installed. For the CUDA 5.0 toolkit, the complete path to the CUDA installation will be C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0.

The installation will include the following directories:

• bin: This folder contains the CUDA compiler and runtime libraries (DLLs)
• include: The C header files that are needed to compile your CUDA programs.
• lib: The library files that are needed to link your CUDA programs.
• doc: This directory contains the documentation for the CUDA Toolkit such as the CUDA C Programming Guide, the CUDA C Best Practices Guide and the documentation for the different CUDA libraries that are available in the Toolkit.

The CUDA Samples contain sample source code and projects for Visual Studio 2008 and Visual Studio 2010. On Windows XP, the samples can be found in C:\Document and Settings\All Users\Application Data\NVIDIA Corporation\CUDA Samples\v#.# and for Windows Vista, Windows 7, and Windows Server 2008, the samples can be found at C:\ProgramData\NVIDIA Corporation\CUDA Samples\v#.# where #.# is the installed CUDA version.

Verify the Installation

Before you start creating a CUDA application, it is important to verify that your CUDA installation is working correctly.

1. Open a Command Prompt window by going to Start Menu > All Programs > Accessories > Command Prompt
   

   Figure 15. Command Prompt

2. In the Command Prompt window type:

   nvcc -V
   

   You should see something similar to what is shown in the Command Prompt screenshot above. The output may differ slightly depending on the version of the CUDA Toolkit you installed but you should not get an error.

Run Compiled Sample

The CUDA Toolkit comes with both the source code and compiled executable for the Toolkit samples. On Windows XP the compiled samples can be found at C:\Document and Settings\All Users\Application Data\NVIDIA Corporation\CUDA Samples\v#.#\bin\win32\Release\ and on Windows 7, Windows 8, Windows Server 2003, and Windows Server 2008 the compiled samples can be found at C:\ProgramData\NVIDIA Corporation\CUDA Samples\v#.#\bin\win32\Release. On a 64-bit version of Windows, you can replace the win32 with win64 to run the 64-bit version of the samples.

Try to run the deviceQuery sample in a Command Prompt window. You should see some output similar to the following image:



Figure 16. deviceQuery

Of course the output generated on your system will be different than this (unless you also have a GeForce GT 330M mobile GPU). Of course, the important thing is that your device(s) is(are) found and the device information is displayed without any errors.

Creating your First Project

For this article, I will create a CUDA application using Microsoft Visual Studio 2010. If you are still using Microsoft Visual Studio 2008 the steps will be very similar and you should still be able to follow along.

Open your Visual Studio IDE and create a new project.

As of CUDA Toolkit 5.0, Visual Studio project templates will be available that can be used to quickly create a project that is ready for creating a CUDA enabled application. Previous to CUDA Toolkit 5.0, Visual Studio project templates were only available when you installed NVIDIA Nsight Visual Studio Edition.

In the New Project dialog box, select NVIDIA > CUDA from the Installed Templates pane. In the right pane, select the CUDA 5.0 Runtime template.



Figure 17. New Project Dialog

Give your project a meaningful name such as “CUDATemplate” or something similar.

Click OK to create a new project.

This will create a new Visual Studio C++ project with a single CUDA source file called kernel.cu

You should be able to compile and run this sample already at this point to confirm it is working. You should get the following output:

{1,2,3,4,5} + {10,20,30,40,50} = {11,22,33,44,55}

If you got any errors or something went wrong, then you should check that do have a CUDA enabled GPU and that you installed the CUDA Toolkit prior to installing Visual Studio 2010. Follow the steps in the previous sections again and make sure you did everything correctly.

Using the Visual Studio project template for the CUDA 5.0 Runtime will automatically configure the build settings necessary to compile a CUDA enabled application. If you want to know how to add the configure necessary to build CUDA source files to an existing C/C++ project, then you can refer to my previous article titled Introduction to CUDA that I wrote last year. That article focuses on CUDA 4.0 using Visual Studio 2008 but the steps are almost identical for CUDA 5.0 using Visual Studio 2010.

Threading Model

The CUDA threading model describes how a kernel is executed on the GPU.

CUDA Threads

Each kernel function is executed in a grid of threads. This grid is divided into blocks also known as thread blocks and each block is further divided into threads.



Figure 18. Cuda Execution Model

In the image above we see that this example grid is divided into nine thread blocks (3×3), each thread block consists of 9 threads (3×3) for a total of 81 threads for the kernel grid.

This image only shows 2-dimensional grid, but if the graphics device supports compute capability 2.0 or higher, then the grid of thread blocks can actually be partitioned into 1, 2 or 3 dimensions, otherwise if the device supports compute capability 1.x, then thread blocks can be partitioned into 1, or 2 dimensions (in this case, then the 3rd dimension should always be set to 1).

The thread block is partitioned into individual threads and for all compute capabilities, threads in a block can be partitioned into 1, 2, or 3 dimensions. The maximum number of threads that can be assigned to a thread block is 512 for devices with compute capability 1.x and 1024 threads for devices that support compute capability 2.0 and higher.

Table 1. Threading Compute Capability

Technical Specifications	1.0	1.1	1.2	1.3	2.x	3.0	3.5
Maximum dimensionality of a grid of thread blocks.	2				3
Maximum x-, dimension of a grid of thread blocks.	65535					231-1
Maximum y- or z-dimension of a grid of thread blocks.	65535
Maximum dimensionality of a thread block.	3
Maximum x- or y-dimension of a block.	512				1024
Maximum z-dimension of a block.	64
Maximum number of threads per block.	512				1024
Warp size.	32
Maximum number of resident blocks per multiprocessor.	8					16
Maximum number of resident warps per multiprocessor.	24		32		48	64
Maximum number of resident threads per multiprocessor.	768		1024		1536	2048

The number of blocks within a gird can be determined within a kernel by using the built-in variable gridDim and the number of threads within a block can be determined by using the built-in variable blockDim.

A thread block is uniquely identified in a kernel function by using the built-in variable blockIdx and a thread within a block is uniquely identified in a kernel function by using the built-in variable threadIdx.

The built-in variables gridDim, blockDim, blockIdx, and threadIdx are each 3-component structs with members x, y, z.

With a 1-D kernel, the unique thread ID within a block is the same as the x component of the threadIdx variable.



and the unique block ID within a grid is the same as the x component of the blockIdx variable:



To determine the unique thread ID in a 2-D block, you would use the following formula:



and to determine the unique block ID within a 2-D grid, you would use the following formula:



I’ll leave it as an exercise for the reader to determine the formula to compute the unique thread ID and block ID in a 3D grid.

Matrix Addition Example

Let’s take a look at an example kernel that one might execute.

Let’s assume we want to implement a kernel function that adds two matrices and stores the result in a 3rd.

The general formula for matrix addition is:



That is, the sum of matrix A and matrix B is the sum of the components of matrix A and matrix B.

Let’s first write the host version of this method that we would execute on the CPU.

void MatrixAddHost( float* C, float* A, float* B, unsigned int matrixDim )
{
    for( unsigned int j = 0; j < matrixDim; ++j )
    {
        for ( unsigned int i = 0; i < matrixDim; ++i )
        {
            unsigned int index = ( j * matrixDim) + i;
            C[index] = A[index] + B[index];
        }
    }
}

This is a pretty standard method that loops through the rows and columns of a matrix and adds the components and stores the results in a 3rd. Now let’s see how we might execute this kernel on the GPU using CUDA.

First, we need to think of the problem domain. I this case, the domain is trivial: it is the components of a matrix. Since we are operating on 2-D arrays, it seems reasonable to split our domain into two dimensions; one for the rows, and another for the columns of the matrices.

We will assume that we are working on square matrices. This simplifies the problem but mathematically matrix addition only requires that the two matrices have the same number of rows and columns but does not have the requirement that the matrices must be square.

Since we know that a kernel is limited to 512 threads/block with compute capability 1.x and 1024 threads/block with compute capability 2.x and 3.x, then we know we can split our job into square thread blocks each consisting of 16×16 threads (256 threads per block) with compute capability 1.x and 32×32 threads (1024 threads per block) with compute capability 2.x and 3.x.

If we limit the size of our matrix to no larger than 16×16, then we only need a single block to compute the matrix sum and our kernel execution configuration might look something like this:

    dim3 gridDim( 1, 1, 1 );
    dim3 blockDim( matrixDim, matrixDim, 1 );
    MatrixAddDevice<<<gridDim, blockDim>>>( C, A, B, matrixDim );

In this simple case, the kernel grid consists of only a single block with matrixDim x matrixDim threads.

However, if we want to sum matrices larger than 512 components, then we must split our problem domain into smaller groups that can be processed in multiple blocks.

Let’s assume that we want to limit our blocks to execute in 16×16 (256) threads. We can determine the number of blocks that will be required to operate on the entire array by dividing the size of the matrix dimension by the maximum number of threads per block and round-up to the nearest whole number:



And we can determine the number of threads per block by dividing the size of the matrix dimension by the number of blocks and round-up to the nearest whole number:



So for example, for a 4×4 matrix, we would get



and the number of threads is computed as:



resulting in a 1×1 grid of 4×4 thread blocks for a total of 16 threads.

Another example a 512×512 matirx, we would get:



and the number of threads is computed as:



resulting in a 32×32 grid of 16×16 thread blocks for a total of 262,144 threads.

The host code to setup the kernel granularity might look like this:

    size_t blocks = ceilf( matrixDim / 16.0f );
    dim3 gridDim( blocks, blocks, 1 );
    size_t threads = ceilf( matrixDim / (float)blocks );
    dim3 blockDim( threads, threads, 1 );

    MatrixAddDevice<<< gridDim, blockDim >>>( C, A, B, matrixDim );

You may have noticed that if the size of the matrix does not fit nicely into equally divisible blocks, then we may get more threads than are needed to process the array. It is not possible to configure a gird of thread blocks with 1 block containing less threads than the others. The only way to solve this is to execute multiple kernels – one that handles all the equally divisible blocks, and a 2nd kernel invocation that handles the partial block. The other solution to this problem is simply to ignore any of the threads that are executed outside of our problem domain which is generally the easier (and more efficient) than invoking multiple kernels (this should be profiled to be proven).

The Matrix Addition Kernel Function

On the device, one kernel function is created for every thread in the problem domain (the matrix elements). We can use the built-in variables gridDim, blockDim, blockIdx, and threadIdx, to identify the current matrix element that the current kernel is operating on.

If we assume we have a 9×9 matrix and we split the problem domain into 3×3 blocks each consisting of 3×3 threads as shown in the CUDA Grid below, then we could compute the i^th column and the j^th row of the matrix with the following formula:



So for thread (0,0) of block (1,1) of our 9×9 matrix, we would get:



for the column and:



for the row.

The index into the 1-D buffer that store the matrix is then computed as:



and substituting gives:



Which is the correct element in the matrix. This solution assumes we are accessing the matrix in row-major order.



Figure 19. CUDA Grid Example

Let’s see how we might implement this in the kernel.

__global__ void MatrixAddDevice( float* C, float* A, float* B, unsigned int matrixDim )
{
    unsigned int column = ( blockDim.x * blockIdx.x ) + threadIdx.x;
    unsigned int row    = ( blockDim.y * blockIdx.y ) + threadIdx.y;

    unsigned int index = ( matrixDim * row ) + column;
    if ( index < matrixDim * matrixDim ) // prevent reading/writing array out-of-bounds.
    {
        C[index] = A[index] + B[index];
    }
}

The kernel function is defined using the __global__ declaration specifier. This specifier is used to identify a function that should execute on the device. Optionally you can also specify host functions with the __host__ declaration specifier within a CUDA source file but this is implied if no specifier is applied to the function declaration.

On line 3, and 4 we compute the column and row of the matrix we are operating on using the formulas shown earlier.

On line 6, the 1-d index in the matrix array is computed based on the size of a single dimension of the square matrix.

We must be careful that we don’t try to read or write out of the bounds of the matrix. This might happen if the size of the matrix does not fit nicely into the size of the CUDA grid (in the case of matrices whose size is not evenly divisible by 16) To protect the read and write operation, on line 7 we must check that the computed index does not exceed the size of our array.

Thread Synchronization

CUDA provides a synchronization barrier for all threads in a block through the __syncthreads() method. A practical example of thread synchronization will be shown in a later article about optimization a CUDA kernel, but for now it’s only important that you know this functionality exists.

Thread synchronization is only possible across all threads in a block but not across all threads running in the grid. By not allowing threads across blocks to be synchronized, CUDA enables multiple blocks to be executed on other streaming multiprocessors (SM) in any order. The queue of blocks can be distributed to any SM without having to wait for blocks from another SM to be complete. This allows the CUDA enabled applications to scale across platforms that have more SM at it’s disposal, executing more blocks concurrently than another platforms with less SM’s.

Thread synchronization follows strict synchronization rules. All threads in a block must hit the synchronization point or none of them must hit synchronization point.

Give the following code block:

if ( threadID % 2 == 0 )
{
    __syncthreads();
}
else
{
    __syncthreads();
}

will cause the threads in a block to wait indefinitely for each other because the two occurrences of __syncthreads are considered separate synchronization points and all threads of the same block must hit the same synchronization point, or all of them must not hit it.

Thread Assignment

When a kernel is invoked, the CUDA runtime will distribute the blocks across the SM’s on the device. With compute compatibility 1.x and 2.x a maximum of 8 blocks will be assigned to each SM and with compute compatibility 3.x a maximum of 16 blocks will be assigned to each SM as long as there are enough resources (registers, shared memory, and threads) to execute all the blocks. In the case where there are not enough resources on the SM, then the CUDA runtime will automatically assign less blocks per SM until the resource usage is below the maximum per SM.

The total number of blocks that can be executed concurrently is dependent on the device. In the case of the Fermi architecture a total of 16 SM’s can concurrently handle 8 blocks for a total of 128 blocks executing concurrently on the device. Kepler devices can handle 16 thread blocks per SMX for a total of 240 thread blocks that can execute concurrently on a single device.

Both the Fermi and Kepler architecture support thread blocks consisting of at most 1024 threads. The Fermi device can support a maximum of 48 warps per SM. The Kepler architecture increases the amount of resident warps per SMX to 64.

The Fermi device can support a maximum of 1,536 resident threads (32×48) per SM. Kepler supports 2,048 threads per SMX (32×64). With 15 SMX units, the Kepler GPU can have a total of 30,720 resident threads on the device. This does not mean that every clock tick the devices is executing 30,720 instruction simultaneously (there are only 2,880 CUDA Cores on the GK110 device). In order to understand how the blocks are actually executed on the device, we must look one step further to see how the threads of a block are actually scheduled on the SM’s.

Thread Scheduling

When a block is assigned to a SMX, it is further divided into groups of 32 threads called a warp. Warp scheduling is different depending on the platform, but if we take a look at the Kepler architecture, we see that a single SMX consists of 192 CUDA cores (a CUDA core is also sometimes referred to a streaming processor or SP for short).

Each SMX in the Kepler architecture features four warp schedulers allowing four warps to be issued and executed concurrently. Kepler’s quad-warp scheduler selects four warps and issues two independent instructions from each warp every cycle^[2].



Figure 20. Warp Scheduler

You might be wondering why it would be useful to schedule 16 blocks of a maximum of 1024 threads if the SMX only has 192 cuda cores? The answer is that each instruction of a kernel may require more than a few clock cycles to execute (for example, an instruction to read from global memory will require multiple clock cycles). Any instruction that requires multiple clock cycles to execute incurs latency. The latency of long-running instructions can be hidden by executing instructions from other warps while waiting for the result of the previous warp. This technique of filling the latency of expensive operations with work from other threads is often called latency hiding.

Thread Divergence

It is reasonable to imagine that your CUDA program contains flow-control statements like if-then-else, switch, while loops, or for loops. Whenever you introduce these flow-control statements in your code, you also introduce the possibility of thread divergence. It is important to be aware of the consequence of thread divergence and also to understand how you can minimize the negative impact of divergence.

Thread divergence occurs when some threads in a warp follow a different execution path than others. Let’s take the following code block as an example:

__global__ void TestDivergence( float* dst, float* src )
{
    unsigned int index = ( blockDim.x * blockIdx.x ) + threadIdx.x;
    float value = 0.0f;

    if ( threadIdx.x % 2 == 0 )
    {
        // Threads executing PathA are active while threads
        // executing PathB are inactive.
        value = PathA( src );
    }
    else
    {
        // Threads executing PathB are active while threads 
        // executing PathA are inactive.
        value = PathB( src );
    }
    // Threads converge here again and execute in parallel.
    dst[index] = value;
}

Then our flow control and thread divergence would look something like this:



Figure 21. Thread Divergence

As you can see from this example, the even numbered threads in each block will execute PathA while the odd numbered threads in the block will execute PathB. This is pretty much the worst-case scenario for simple divergence example.

Both PathA and PathB cannot be executed concurrently on all threads because their execution paths are different. Only the threads that execute the exact same execution path can run concurrently so the total running time of the warp is the sum of the execution time of both PathA and PathB.

In this example, the threads in the warp that execute PathA are activated if the condition is true and all the other threads are deactivated. Then, in another pass, all the threads that execute PathB are activated if the condition is false are activated and the other threads are deactivated. This means that to resolve this condition requires 2-passes to be executed for a single warp.

The overhead of having the warp execute both PathA and PathB can be eliminated if the programmer takes careful consideration when writing the kernel. If possible, all threads of a block (since warps can’t span thread blocks) should execute the same execution path. This way you guarantee that all threads in a warp will execute the same execution path and there will be no thread divergence within a block.

Memory Model

There are several different types of memory that your CUDA application has access to. For each different memory type there are tradeoffs that must be considered when designing the algorithm for your CUDA kernel.

Global memory has a very large address space, but the latency to access this memory type is very high. Shared memory has a very low access latency but the memory address is small compared to Global memory. In order to make proper decisions regarding where to place data and when, you must understand the differences between these memory types and how these decisions will affect the performance of your kernel.

In the next sections, I will describe the different memory types and show examples of using different memory to improve the performance of your kernel.

CUDA Memory Types

Every CUDA enabled GPU provides several different types of memory. These different types of memory each have different properties such as access latency, address space, scope, and lifetime.

The different types of memory are register, shared, local, global, and constant memory.

On devices with compute capability 1.x, there are 2 locations where memory can possibly reside; cache memory and device memory.

The cache memory is considered “on-chip” and accesses to the cache is very fast. Shared memory and cached constant memory are stored in cache memory with devices that support compute capability 1.x.

The device memory is considered “off-chip” and accesses to device memory is about ~100x slower than accessing cached memory. Global memory, local memory and (uncached) constant memory is stored in device memory.

On devices that support compute capability 2.x, there is an additional memory bank that is stored with each streaming multiprocessor. This is considered L1-cache and although the address space is relatively small, it’s access latency is very low.



Figure 22. CUDA Memory Model

In the following sections I will describe each type and when it is best to use that memory type.

Register

Scalar variables that are declared in the scope of a kernel function and are not decorated with any attribute are stored in register memory by default. Register memory access is very fast, but the number of registers that are available per block is limited.

Arrays that are declared in the kernel function are also stored in register memory but only if access to the array elements are performed using constant indexes (meaning the index that is being used to access an element in the array is not a variable and thus the index can be determined at compile-time). It is currently not possible to perform random access to register variables.

Register variables are private to the thread. Threads in the same block will get private versions of each register variable. Register variables only exists as long as the thread exists. Once the thread finishes execution, a register variable cannot be accessed again. Each invocation of the kernel function must initialize the variable each time it is invoked. This might seem obvious because the scope of the variable is within the kernel function, but this is not true for all variables declared in the kernel function as we will see with shared memory.

Variables declared in register memory can be both read and written inside the kernel. Reads and writes to register memory does not need to be synchronized.

Local

Any variable that can’t fit into the register space allowed for the kernel will spill-over into local memory. Local memory has the same access latency as global memory (that is to say, slow). Accesses to local memory is cached only on GPU’s with compute capability 2.x or higher^[4].

Like registers, local memory is private to the thread. Each thread must initialize the contents of a variable stored in local memory before it should be used. You cannot rely on another thread (even in the same block) to initialize local memory because it is private to the thread.

Variables in local memory have the lifetime of the thread. Once the thread is finished executing, the local variable is no longer accessible.

You cannot decorate a variable declaration with any attribute but the compiler will automatically put variable declarations in local memory under the following conditions:

• Arrays that are accessed with run-time indexes. That is, the compiler can’t determine the indices at compile time.
• Large structures or arrays that would consume too much register space.
• Any variable declared that exceeds the number of registers for that kernel (this is called register-spilling).

The only way that you can determine if the compiler has put some function scope variables in local memory is by manual inspection of the PTX assembly code (obtained by compiling with the -ptx or -keep option). Local variables will be declared using the .local mnemonic and loaded using the ld.local mnemonic and stored with the st.local mnemonic.

Variables in local memory can be both read and written within the kernel and access to local memory does not need to be synchronized.

Shared

Variables that are decorated with the __shared__ attribute are stored in shared memory. Accessing shared memory is very fast (~100 times faster than global memory) although each streaming multiprocessor has a limited amount of shared memory address space.

Shared memory must be declared within the scope of the kernel function but has a lifetime of the block (as opposed to register, or local memory which has a lifetime of the thread). When a block is finished execution, the shared memory that was defined in the kernel cannot be accessed.

Shared memory can be both read from and written to within the kernel. Modification of shared memory must be synchronized unless you guarantee that each thread will only access memory that will not be read-from or written-to by other threads in the block. Block synchronization is acheived using the __syncthreads() barrier function inside the kernel function.

Since access to shared memory is faster than accessing global memory, it is more efficient to copy global memory to shared memory to be used within the kernel but only if the number of accesses to global memory can be reduced within the block (as we’ll see with the matrix multiply example that I will show later).

Global

Variables that are decorated with the __device__ attribute and are declared in global scope (outside of the scope of the kernel function) are stored in global memory. The access latency to global memory is very high (~100 times slower than shared memory) but there is much more global memory than shared memory (up to 6GB but the actual size is different across graphics cards even of the same compute capability).

Unlike register, local, and shared memory, global memory can be read from and written to using the C-function cudaMemcpy.

Global memory has a lifetime of the application and is accessible to all threads of all kernels. One must take care when reading from and writing to global memory because thread execution cannot be synchronized across different blocks. The only way to ensure access to global memory is synchronized is by invoking separate kernel invocations (splitting the problem into different kernels and synchronizing on the host between kernel invocations).

Global memory is declared on the host process using cudaMalloc and freed in the host process using cudaFree. Pointers to global memory can be passed to a kernel function as parameters to the kernel (as we will see in the example later).

Reads from global memory is cached only on devices that support compute capability 2.x or higher^[4] but any write to global memory will invalidate the cache thus eliminating the benefit of cache. Access to global memory on devices that support compute capability 1.x is not cached.

It is a bit of an art-form to reduce the number of accesses to global memory from within a kernel by using blocks of shared memory because the access latency to shared memory is about 100 times faster than accessing global memory. Later, I will show an example of how we can reduce the global memory access using shared memory.

Constant

Variables that are decorated with the __constant__ attribute are declared in constant memory. Like global variables, constant variables must be declared in global scope (outside the scope of any kernel function). Constant variables share the same memory banks as global memory (device memory) but unlike global memory, there is only a limited amount of constant memory that can be declared (64KB on all compute capabilities).

Access latency to constant memory is considerably faster than global memory because constant memory is cached but unlike global memory, constant memory cannot be written to from within the kernel. This allows constant memory caching to work because we are guaranteed that the values in constant memory will not be changed and therefor will not become invalidated during the execution of a kernel.

Constant memory can be written to by the host process using the cudaMemcpyToSymbol function and read-from using the cudaMemcpyFromSymbol function. As far as I can tell, it is not possible to dynamically allocate storage for constant memory (the size of constant memory buffers must be statically declared and determined at compile-time).

Like global memory, constant memory has a lifetime of the application. It can be accessed by all threads of all kernels and the value will not change across kernel invocations unless explicitly modified by the host process.

Properties of Memory

The amount of memory that is available to the CUDA application is (in most cases) specific to the compute capability of the device. For each compute capability, the size restrictions of each type of memory (except global memory) id defined in the table below. The application programmer is encouraged to query the device properties in the application using the
cudaGetDeviceProperties method.

Table 2. Memory Compute Capability

Technical Specifications	1.0	1.1	1.2	1.3	2.x	3.0	3.5
Number of 32-bit registers per thread	128				63		255
Maximum amount of shared memory per SM	16 KB				48 KB
Amount of local memory per thread	16 KB				512 KB
Constant memory size	64 KB

The following table summarizes the different memory types and the properties of those types.

Table 3. Properties of Memory Types

Memory	Located	Cached	Access	Scope	Lifetime
Register	cache	n/a	Host: None Kernel: R/W	thread	thread
Local	device	1.x: No 2.x: Yes	Host: None Kernel: R/W	thread	thread
Shared	cache	n/a	Host: None Kernel: R/W	block	block
Global	device	1.x: No 2.x: Yes	Host: R/W Kernel: R/W	application	application
Constant	device	Yes	Host: R/W Kernel: R	application	application

Pointers to Memory

You can use pointers to memory in a kernel but you must be aware that the pointer type does not determine where the memory is located.

For example, the following code declares a pointer to constant memory and a pointer to global memory. You should be aware that only the pointer variable is constant – not what it points to.

__constant__ float* constPtr;
__device__ float* globalPtr;

__global__ void KernelFunction(void)
{
    // Assign the pointer to global memory to a pointer to constant memory.
    // This will not compile because the pointer is constant and you can't change
    // what a const-pointer points to in the kernel.
    constPtr = globalPtr;

    // This will compile because what the const pointer points to is not 
    // necessarily const (if it is, you'll probaly get a runtime error).
    *constPtr = *globalPtr;
}

Since you can’t dynamically allocate constant memory, this example would not be very useful anyways.

Be careful when using pointers like this. It is a best-practice rule to ensure that a declared pointer only points to one type of memory (so a single pointer declaration will only point to global memory and another pointer declaration will only point to shared memory).

Minimize Global Memory Access

Since access latency is much higher for global memory than it is for shared memory, it should be our objective to minimize accesses to global memory in favor of shared memory. This doesn’t mean that every access to data in global memory should first be copied into a variable in shared (or register) memory. Obviously we will not benefit from the low latency shared memory access if our algorithm only needs to make a single access to global memory. But it happens in some cases that multiple threads in the same block will all read from the same location in global memory. If this is the case, then we can speed-up our algorithm by first allowing each thread in a block to copy one part of the global memory into a shared memory buffer and then allowing all of the threads in a block to access all elements in that shared memory buffer.

To demonstrate this, I will show several flavors the classic matrix multiply example. The first example I will show is the standard implementation of the matrix multiply using only global memory access. Then, I will show an optimized version of the algorithm that uses shared memory to reduce the number of accesses to global memory for threads of the same block.

Matrix Multiply using Global Memory

This version of the matrix multiply algorithm is the easiest to understand however it is also a very naive approach.

__global__ void MatrixMultiplyKernel_GlobalMem( float* C, const float* A, const float* B, unsigned int matrixDim )
{
    // Compute the row index
    unsigned int i = ( blockDim.y * blockIdx.y ) + threadIdx.y;
    // Compute the column index
    unsigned int j = ( blockDim.x * blockIdx.x ) + threadIdx.x;

    unsigned int index = ( i * matrixDim ) + j;
    float sum = 0.0f;
    for ( unsigned int k = 0; k < matrixDim; ++k )
    {
        sum += A[i * matrixDim + k] * B[k * matrixDim + j];
    }
    C[index] = sum;
}

The parameters A, B, and C all point to buffers of global memory.

The fist step is to figure out which row (i) and which column (j) we are operating on for this kernel.

On line 10, we loop through all of the elements of row i of matrix A and the column j of matrix B and compute the summed product of corresponding entries (the dot product of row i and column j). A visual aid of this algorithm is shown below.



Figure 23. Matrix Multiply – Global Memory

If we analyze this algorithm, we may notice that the same row elements of matrix A are being accessed for every resulting row element of matrix C and all the column elements of matrix B are being accessed for every resulting column element of matrix C. If we say that the resulting matrix C is N x M elements, then each element of matrix A is being accessed M times and each element of matrix B is being accessed N times. That seems pretty wasteful to me.

Matrix Multiply using Shared Memory

What if we could reduce the number of times the elements of matrix A and B are accessed to just 1? Well, depending on the size of our matrix, we could just store the contents of matrix A and matrix B into shared memory buffers then just compute the resulting matrix C from those buffers instead. This might work with small matrices (remember that shared memory is local to a single block and with compute capability 1.3, we are limited to matrices of about 20 x 20 because we are limited to 512 threads that can be assigned to a single block).

But what if we had larger matrices to multiply? If we can find a way to split the problem into “phases” then we could simply load each “phase” into shared memory, process that “phase”, then load the next “phase” and process that one until we have exhausted the entire domain.

This technique of splitting our problem domain into phases is called “tiling” named because of the way we can visualize the technique as equal sized tiles that represent our problem domain.



Figure 24. Tiles

For this particular problem, the best partitioning of the problem domain is actually the same as partitioning of the grid of threads that are used to compute the result.

If we split our grid into blocks of 16 x 16 threads (which I showed previously in the section about CUDA thread execution to be a good granularity for this problem) then we can create two buffers in shared memory that are the same size as a single thread block in our kernel grid, one that holds a “tile” of matrix A, and other to store a “tile” of matrix B.

Let’s see how this might look:



Figure 25. Matrix Multiply – Tiles

So the idea is simple, each thread block defines a pair of shared memory buffers that are used to “cache” a “tile” of data from matrix A and matrix B. Since the “tile” is the same size as the thread block, we can just let each thread in the thread block load a single element from matrix A into one of the shared memory buffers and a single element from matrix B into the other. Using this technique, we can reduce the number of global memory access to matrixDim / BLOCK_SIZE per thread (where BLOCK_SIZE is the size of the thread block and shared memory buffer in a single dimension).

But will this work? We only have access to 16 KB (16,384 Bytes) of shared memory per streaming multiprocessor for devices of compute capability 1.x. If our BLOCK_SIZE is 16 then we need 16² floating point values (4-bytes each) per shared memory buffer. So the size in bytes of each shared memory buffer is:



And we need 2 buffers, so we will need 2,048 Bytes of shared memory per block. If you remember from the previous article about the CUDA thread execution model,
thread blocks of size 16 x 16 will allow 4 resident blocks to be scheduled per streaming multiprocessor. So 4 blocks each requiring 2,048 Bytes gives a total requirement of 8,192 KB of shared memory which is 50% of the available shared memory per streaming multiprocessor. So this this tiling strategy will work.

So let’s see how we might implement this in the kernel.

#define BLOCK_SIZE 16

__global__ void MatrixMultiplyKernel_SharedMem( float* C, const float* A, const float* B, unsigned int matrixDim )
{
    unsigned int tx = threadIdx.x;
    unsigned int ty = threadIdx.y;
    unsigned int bx = blockIdx.x;
    unsigned int by = blockIdx.y;

    // Allocate share memory to store the matrix data in tiles
    __shared__ float sA[BLOCK_SIZE][BLOCK_SIZE];
    __shared__ float sB[BLOCK_SIZE][BLOCK_SIZE];

    // Compute the column index
    unsigned int j = ( blockDim.x * bx ) + tx;
    // Compute the row index
    unsigned int i = ( blockDim.y * by ) + ty;

    unsigned int index = ( i * matrixDim ) + j;
    float sum = 0.0f;

    // Loop through the tiles of the input matrices
    // in separate phases of size BLOCK_SIZE
    for( unsigned int phase = 0; phase < matrixDim/BLOCK_SIZE; ++phase )
    {
        // Allow each thread in the block to populate the shared memory
        sA[ty][tx] = A[i * matrixDim + (phase * BLOCK_SIZE + tx)];
        sB[ty][tx] = B[(phase * BLOCK_SIZE + ty) * matrixDim + j];
        __syncthreads();

        for( unsigned int k = 0; k < BLOCK_SIZE; ++k )
        {
            sum += sA[ty][k] * sB[k][tx];
        }
        __syncthreads();
    }

    C[index] = sum;    
}

On line 5-8, we just store some “shorthand” versions of the thread and block indexes into private thread variables (these are stored in registers).

On line 11, and 12 the two shared memory buffers are declared to store enough values that each thread in the thread block can store a single entry in the arrays.

On line 15, the index of the column is computed and stored in another registry variable j and on line 16, the row is computed and stored in registry variable i.

On line 20, the 1-D index into the result matrix C is computed and the sum of the products is stored in the float variable sum.

On line 25, we will loop over the “tiles” (called phases here) of matrix A and matrix B. You should note that this algorithm assumes the size of the matrix is evenly divisible by the size of the thread block.

On lines 28 and 29 is where the magic happens. Since the shared memory is accessible to every thread in the block, we can let every thread in the block copy 1 element from matrix A and one element from matrix B into the shared memory blocks.

Before we can access the data in the shared memory blocks, we must ensure that all threads in the entire block have had a chance to write their data. To do that we need to synchronize the execution of all the threads in the block by calling the __syncthreads() method.

Then the for loop on line 32 will loop through the elements of shared memory and sum the products.

Before we leave this loop and start filling the next “tile” into shared memory, we must ensure that all threads are finished with the shared memory buffers. To do that, we must execute __syncthreads() again on line 36.

This will repeat until all phases (or tiles) of the matrix have been processed.

Once all phases are complete, then the value stored in sum will contain the final result and it is written to the destination matrix C.

Running the global memory version of the matrix multiply on my laptop with a 512 x 512 matrix runs in about 45 milliseconds. Running the shared memory version on the same matrix completes in about 15 milliseconds (including copying memory from host to device and copying the result back to host memory). This provides a speed-up of 300%!

Resources as a Limiting Constraint

It is entirely possible to allocate more shared memory per block than 2,048 bytes, but the block scheduler will reduce the number of blocks scheduled on a streaming multiprocessor until the shared memory requirements are met. If you want to allocate all 16 KB of shared memory in a single block, then only a single block will be resident in the streaming multiprocessor at any given moment which will reduce the occupancy of the streaming multiprocessor to 25% (for a 16 x 16 thread block on compute capability 1.x).

This reduced thread occupancy is not ideal, but it is conceivable to imagine that a single block might have this requirement. In most cases the GPU will still out-perform the CPU if the benefit of using the low-latency memory is fully realized.

This is also true for the number of registers that can be allocated per block. If a single kernel declares 32 32-bit variables that must be stored in registers and the thread block consists of 16 x 16 threads, then the maximum number of blocks that can be active in a streaming multiprocessor on a device with compute capability 1.3 is 2 because the maximum number of 32-bit registers that can be used at any moment in time is 16,384.



So the number of 32-bit registers/block is 8,192. So the streaming multiprocessor can accommodate a maximum of 8,192 / 16,384 = 2 blocks.

CUDA GPU Occupancy Calculator

Since version 4.1, the CUDA Toolkit comes with a tool called the CUDA GPU Occupancy Calculator. This tool is a Microsoft Excel file that can be used to compute the maximum thread occupancy of the streaming multiprocessor given a set of limiting constraints (threads per block, registers per thread, and shared memory (bytes) per block). This tool is provided in the following folder:

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\vX.X\tools



Figure 26. CUDA Occupancy Calculator

The CUDA Occupancy Calculator allows you to compute the best thread granularity for your thread blocks given a specific compute capability and resource constraints.

You can refer to the second worksheet titled “Help” to learn how to use the CUDA GPU Occupancy Calculator.

Exercises

Q1. Would the MatrixAddDevice kernel function shown in this article benefit from the use of shared memory? Explain your answer.

A1. No, it would not benefit from the use of shared memory because each matrix element is only accessed once. You would still need to access each matrix component to store it in shared memory only to require an access from shared memory to access it again. In this case, store the data in shared memory will only increase the time to execute the kernel because more load/store operations will need to be performed.

Q2. In almost all of the examples shown here, I decided to use a 16×16 thread granularity for the thread blocks. Can you explain why this is a good choice for thread granularity on devices of compute capability (you can assume that register use and shared memory allocation are within the limits in each case):

1. 1.3?
2. 2.0?
3. 3.0?

A2. To answer this question, let’s take a look at each individual compute capability.

a. For Compute Capability 1.3 threads are split into groups of 32 threads called warps. The maximum number of warps/SM is 32. If we create a 16×16 thread block, then we have a total of 256 threads/block. Each block will be split into 8 warps to be scheduled on the SM. Since we know that the maximum number of warps/SM for devices with compute capability 1.3 is 32, then 4 thread blocks will be scheduled on each SM. Each SM can support up to 8 resident blocks per SM and 4 is still within our limit. Also with a maximum resident thread limit of 1024 threads and we exactly meet this requirement (4×256) so we also achieve 100% thread occupancy on the SM! So yes, a 16×16 thread block is a good choice for devices with compute capability 1.3.

b. For devices with compute capability 2.0 threads are also split into groups of 32 threads called warps. In this case, the maximum number of warps/SM is 48. Again, we have 256 threads per block which are split into 8 warps to be scheduled on the SM then 6 thread blocks will be scheduled per SM (48/8). 6 blocks is within the 8 block limit, so we haven’t exceeded the block limit. And with a maximum resident thread limit of 1536 threads, we exactly meet this requirement (6×256) so we also achieve a 100% thread occupancy on the SM! So yes, a 16×16 thread block is also a good choice for devices with compute capability 2.0.

c. For devices with compute capability 3.0 the threads are also split into groups of 32 threads called warps. So again, each block will be split into 8 warps. The maximum number of warps that can be active in a SM is 64. This allows for 8 thread blocks to be scheduled per SM. This is within the limit of 16 blocks/SM and again matches exactly the maximum number of threads of 2048 threads (8×256) that can be scheduled for each SM so we also achieve 100% thread occupancy. So yes, a 16×16 thread block is also a good choice for devices with compute capability 3.0 (and consequently this is also true for devices of compute capability 3.5).

Q3. Assuming we have a block of 256 threads each, what is the maximum amount of shared memory we can use per block and still maintain 100% thread occupancy for devices of compute capability (assume the register count is not a limiting resource):

1. 1.3?
2. 2.0?
3. 3.0?

a. In the previous exercise we already established that with a thread blocks of 256 threads, we will have 4 resident blocks per SM. Since devices of compute capability 1.3 have a maximum 16 KB (16,384 bytes) of shared memory then each block can use a maximum of 4,096 bytes (16,384/4) of shared memory while still maintaining 100% thread occupancy.

b. In the previous exercise we saw that we could schedule 6 blocks of 256 threads. Devices of compute capability 2.0 have a maximum of 48 KB (49,152 bytes) of shared memory per SM. This means that we can allocate a maximum of 8,192 bytes (49,152/6) of shared memory while still maintaining 100% thread occupancy.

c. In the previous exercise we saw that we could schedule 8 blocks of 256 threads to get 100% thread occupancy. Devices with compute capability 3.0 also have a maximum of 48 KB (49,152 KB) of shared memory per SM. In this case, we can only allocate 6,144 bytes (49,152/8) of shared memory while still maintaining 100% thread occupancy.

Q4. In the case (c) above, what would happen if we created thread blocks of 1024 threads? Would we still have 100% thread occupancy? How much shared memory could we allocate per thread block and maintain 100% thread occupancy? Explain your answer.

Q5. Answer question (3) and (4) again but this time compute the number of registers you have available per thread while still maintaining 100% thread occupancy. In this case, you can assume that shared memory is not a limiting resource.

Hint: To answer Q5 correctly, you must also take the register allocation granularity and unit size into consideration. For compute capability 1.3, the register allocation granularity is at the block level and the register allocation unit size is 512. For compute capability 2.x register allocation granularity is at the warp level and the register allocation unit size is 64. For compute capability 3.x, the register allocation granularity is at the warp level and the register allocation unit size is 256.

References

1. NVIDIA Corporation (2012, October). CUDA C Programming Guide. (PG-02829-001_v5.0). USA. Available from: http://docs.nvidia.com/cuda/pdf/CUDA_C_Programming_Guide.pdf. Accessed: October 2012.


2. NVIDIA Corporation (2012, October). NVIDIA’s Next Generation CUDA Compute Architecture: Kepler GK110. (V1.0). USA. Available from: http://www.nvidia.com/content/PDF/kepler/NVIDIA-Kepler-GK110-Architecture-Whitepaper.pdf. Accessed: October 2012.

3. NVIDIA Corporation (2012, October). NVIDIA CUDA Getting Started Guide For Microsoft Windows. (DU-05349-001_v5.0). USA. Available from: http://developer.download.nvidia.com/compute/cuda/5_0/rel/docs/CUDA_Getting_Started_Guide_For_Microsoft_Windows.pdf. Accessed: October 2012.


4. NVIDIA Corporation (2012, October). CUDA C Best Practices Guide. (DG-05603-001_v5.0). USA. Available from: http://docs.nvidia.com/cuda/pdf/CUDA_C_Best_Practices_Guide.pdf. Accessed: October 2012.

5. Kirk, David B. and Hwu, Wen-mei W. (2010). Programming Massively Parallel Processors. 1st. ed. Burlington, MA 01803, USA: Morgan Kaufmann Publishers.

]]> http://3dgep.com/?feed=rss2&p=4151 0 http://3dgep.com/?p=4027 http://3dgep.com/?p=4027#comments Mon, 01 Oct 2012 15:55:05 +0000 Jeremiah van Oosten http://3dgep.com/?p=4027 Continue reading →]]> .table_cell_text { color: #FFF; text-align: center; font-weight: bold; background-color: #666; }


Physics in Unity

In this article, I will introduce the reader to the Physics system used in the Unity game engine. First, I will introduce the Physic Material Asset that is used to define physics properties for collider surfaces. I will also introduce Colliders and talk about the different kinds of Collider types you can create. The Rigidbody component is absolutely essential for performing physics simulations on GameObjects. I will show you how you can create a Rigidbody GameObject that can be user controlled. I will also talk about the Character Controller component that is provided by Unity to control upright characters. And finally, I will introduce the different Joints that are available in Unity.

Table of Contents

1. Introduction
2. Physics Material
   1. Frictionless Physic Material
3. Colliders
   1. Trigger Collider
   2. Static Collider
   3. Rigidbody Collider
   4. Kinematic Rigidbody Collider
   5. Collision Matrix
   6. Trigger Matrix
   7. Box Collider
   8. Sphere Collider
   9. Capsule Collider
   10. Mesh Collider
   11. Compound Colliders
4. Rigidbodies
   1. Physics Rigidbody
   2. Kinematic Rigidbody
   3. Properties of a Rigidbody
   4. Rigidbody Tutorial
      1. Create a New Scene
      2. Create a Plane
      3. Create a Rigidbody Collider
      4. Create a Static Collider
      5. Create a Trigger Collider
      6. Trigger Script
      7. Create a Controllable Rigidbody
5. Character Controller
   1. Character Controller Tutorial
      1. Create a New Scene
      2. Add a Character Controller
      3. Character Controller Push Script
      4. Try This...
6. Joints
   1. Hinge Joint
   2. Spring Joint
   3. Fixed Joint
   4. Character Joint
7. Conclusion
8. References

 

Introduction

There is nothing real or natural about how things behave in computer games. They don’t know anything about the natural physical phenomenon that exists in reality. If you place a bunch of objects in a scene in Unity, these objects will not naturally know what they are supposed to do. They won’t even be affected by gravity unless you explicitly tell them what gravity is. Game engines (like Unity) require Physics to be simulated using a Physics Engine. The Physics Engine tries to simulate physics in your game so that the objects in your game demonstrate natural physical phenomenon.

Physics components in Unity are split into several categories:

• Physics Material: The Physic Material is an Asset type that describes how a physically controlled object reacts to other physically controlled objects.
• Collider: The Collider components are used to describe the collision shape of an object.
• Rigidbody: The Rigidbody component is required to allow your GameObject to be controlled by the physics engine and influence other physics controlled objects.
• Character Controller: The Character Controller component is most commonly used on up-right character models. It’s used to move the character around the scene without a Rigidbody attached to the GameObject but still performs collision detection on other colliders in your scene.
• Cloth: Unity provides a few components that can be used to simulate cloth behavior in your game. This is useful for capes or dresses, or simulating flags or banners.
• Joints: Joints allow you to define a constraint between two Rigidbodies. This is useful for hinges or creating springs between two objects.

In this article, I will introduce you to the physics system in Unity and give you an idea of how it works so that you can implement your physics controlled objects correctly in your own games.

Physics Material

The Physic Material is an Asset type that can be assigned to Colliders. The Physic Material describes both the friction and bounciness of a physics controlled object.



Unity – Physic Material

The Physic Material has the following properties:

• Dynamic Friction: The Dynamic Friction property determines the friction that is applied while the object is in motion. This property usually has a value in the range 0 to 1. A value of 0 will cause no friction to be applied to the surface and a value of 1 will cause the object to slow down very quickly when it is in contact with another surface.
• Static Friction: The Static Friction property determines the friction that is applied while the object is not moving. A value of 0 will allow the object to start moving very easily. A value of 1 will take a lot of force to get the object to start moving.
• Bounciness: Determines how much the object will bounce when it hits another collider. With a value of 0, the object will not bounce at all (all kinetic energy will be absorbed). With a value of 1, the object will bounce indefinitely (all kinetic energy will be maintained). With a value greater than 1 will cause the object to bounce higher (it will gain kinetic energy).
• Friction Combine: Determines how the friction of the two colliding objects is combined:
  • Average: The applied friction is the average friction between the two colliders.
  • Multiply: The applied friction is the product of the friction of both colliders.
  • Minimum: The applied friction is the minimum friction of either collider.
  • Maximum: The applied friction is the maximum friction of either collider.
• Bounce Combine: Determines how the bounciness of the two colliding objects is combined:
  • Average: The applied bounciness is the average bounciness between the two colliders.
  • Multiply: The applied bounciness is the product of the bounciness of both colliders.
  • Minimum: The applied bounciness is the minimum bounciness of either collider.
  • Maximum: The applied bounciness is the maximum bounciness of either collider.
• Friction Direction 2: The Friction Direction 2 is a vector in object local space that can be used to simulate surfaces that can slide easier in one direction than in the other. For example, a corrugated surface that can slide easily in the direction of the corrugated grooves, but tend to resist motion opposite to the corrugated groves.
• Dynamic Friction 2: The amount of dynamic friction to apply in the direction of Friction Direction 2 while the object is in motion.
• Static Friction 2: The ammount of static friction to apply in the direction of Friction Direction 2 while the object is at rest.

Unity provides a few default Physic Materials in the standard packages for Ice, Metal, Rubber, and Wood.

Frictionless Physic Material

To create a completely friction-less material, create a new Physic Material asset in the Project view and set it’s properties to the following values:

• Dynamic Friction: 0
• Static Friction: 0
• Friction Combine: Minimum

Leave the other properties as their defaults.

The Bounciness properties don’t effect friction, so you can set them to anything you want.

We’ll use this frictionless Physic Material later when we start playing with Rigidbody components.

Colliders

Colliders are used to define the collision shape of objects in your scene. Unity provides three primitive collider types: Box, Sphere and Capsule. Unity also provides a Mesh Collider component that can be used to represent a simplified version of your complex meshes. For vehicles, Unity also provides a Wheel Collider component and a Terrain Collider component that can be used on terrains.

Trigger Collider

Any Collider type (Box, Sphere, Capsule, Mesh, and Terrain) can be used as a Trigger by setting the Is Trigger property to true. If the Collider is a Trigger we call it a Trigger Collider. Trigger Colliders will not participate in physics simulations but they will fire the OnTriggerEnter, OnTriggerStay, and OnTriggerExit events on the GameObject they are attached to as long as the collider that intersected with the trigger is a Rigidbody Collider (see below).

If you place a Rigidbody on a Trigger Collider, it will be effected by gravity (if the Use Gravity property is true on the Rigidbody component) but it will not collide with other colliders in your scene. If you have Rigidbody objects in your scene that are falling through the floor, make sure the collider component does not have the Is Trigger property set to true.

Trigger Colliders can be used for many different things. You can place a Trigger Collider near a doorway that opens the door when the player enters the collider and closes the door when the user exits the Trigger Collider.



Unity – Trigger Collider

In the image above, we see a screenshot from the game AngryBots that ships with Unity 3.5. The green box centered on the door is used to play the door opening animation when the player enters the trigger area and plays the door opening animation in reverse when the player exits the trigger area.

Static Collider

A Static Collider is any non-trigger Collider without a Rigidbody component. Without a Rigidbody component, an object will not be influenced by physics. Static Colliders can be used to block GameObjects with Rigidbody components but no matter how hard another Rigidbody component hits a Static Collider, the Static Collider will not move. Static Colliders are ideal for the walls, floors, and other fixed (static) level decoration in your scene.

Rigidbody Collider

A Rigidbody Collider on the other hand, is a Collider with a Rigidbody component. Rigidbody Colliders will be simulated by physics and they will collide with other Static Colliders and Rigidbody Colliders. They will not collide with (be blocked by) Trigger Colliders but they will receive the OnTriggerEnter, OnTriggerStay, and OnTriggerExit events if they move into the area defined by the Trigger Collider.

Kinematic Rigidbody Collider

A Kinematic Rigidbody Collider is a Rigidbody Collider with the Is Kinematic flag set to true on the Rigidbody component. Kinematic Rigidbody Colliders will not be influenced by physics and they must be moved using the GameObject’s Transform component (using the transform.position and transform.rotation). Kinematic Rigidbody Colliders are commonly used on animated characters. While the character is animated, the Rigidbody component will be kinematic but if you want to switch the character to a Ragdoll state, you will disable the Is Kinematic flag and the character will act like a limp doll and fall to the floor.

Kinematic Rigidbody Colliders will only collide with other Rigidbody Colliders. Kinematic Rigidbody Colliders will push other Rigidbody Colliders but they will not react to being pushed by other Rigidbody Colliders.

Kinematic Rigidbody Colliders will not collide with Static Colliders.

Collision Matrix

The following table shows which collider types will perform collision detection. The OnCollisionEnter(), OnCollisionStay(), and OnCollisionExit() messages will also be sent on GameObjects that meet the collision requirements. Also keep in mind that only colliders that also have a Rigidbody will react to collisions, that is, they will be pushed by other Rigidbody colliders.

Collision detection occurs and messages are sent upon collision
	Static Collider	Rigidbody Collider	Kinematic Rigidbody Collider	Static Trigger Collider	Rigidbody Trigger Collider	Kinematic Rigidbody Trigger Collider
Static Collider		Yes
Rigidbody Collider	Yes	Yes	Yes
Kinematic Rigidbody Collider		Yes
Static Trigger Collider
Rigidbody Trigger Collider
Kinematic Rigidbody Trigger Collider

[Source]

Trigger Matrix

The following table shows which collider types will fire Trigger events. The OnTriggerEnter(), OnTriggerStay(), and OnTriggerExit() events will also be called on colliders that meet the trigger requirements. Keep in mind that trigger events will only be called on Trigger Colliders.

Trigger messages are sent upon collision
	Static Collider	Rigidbody Collider	Kinematic Rigidbody Collider	Static Trigger Collider	Rigidbody Trigger Collider	Kinematic Rigidbody Trigger Collider
Static Collider					Yes	Yes
Rigidbody Collider				Yes	Yes	Yes
Kinematic Rigidbody Collider				Yes	Yes	Yes
Static Trigger Collider		Yes	Yes		Yes	Yes
Rigidbody Trigger Collider	Yes	Yes	Yes	Yes	Yes	Yes
Kinematic Rigidbody Trigger Collider	Yes	Yes	Yes	Yes	Yes	Yes

[Source]

Box Collider

The Box Collider is a basic cube-shaped collision primitive. It is commonly used to mimic the shape of cube like objects such as crates and boxes, the hull of a car, walls, doors, tables, and other level geometry that resembles the shape of a cube.



Unity – Box Collider

The Box Collider is also a very common primitive collider that is used to create triggers in your game (as shown in the Angry Bots screenshot above).

The Box Collider has the following properties:



Unity – Box Collider Properties

• Is Trigger: If true, this collider will be considered a Trigger Collider and will no longer be influenced by physics but it will fire Trigger events on other Rigidbody colliders.
• Material: The Physics Material that determines the friction and bounce of this object. The Physics Material is irrelevant if this is a Trigger Collider.
• Center: The X, Y, Z, position of the Collider relative to the GameObject’s Transform.
• Size: The scale of the collider relative to the GameObjects’s scale.

[Source]

Sphere Collider

The Sphere Collider is similar to a Box Collider except it resembles the shape of a sphere instead of a cube.



Unity – Sphere Collider Properties

The Sphere Collider has the following properties:

• Is Trigger: If true, this collider will be considered a Trigger Collider and will no longer be influenced by physics but it will fire Trigger events on other Rigidbody colliders.
• Material: The Physics Material that determines the friction and bounce of this object. The Physics Material is irrelevant if this is a Trigger Collider.
• Center: The X, Y, Z, position of the Collider relative to the GameObject’s position.
• Radius: The radius of the collider relative to the GameObjects’s scale.

[Source]

Capsule Collider

The Capsule Collider resembles the shape of a capsule. It is most commonly used to approximate the size and shape of a character. The Capsule Collider is also commonly used on the bones of an animated character. When the character is hit by something, the capsule colliders can be switched from kinematic to physics controlled so the character falls to the floor like a ragdoll.



Unity – Ragdoll



Unity – Capsule Collider Properties

The Capsule Collider has the following properties:

• Is Trigger: If true, this collider will be considered a Trigger Collider and will no longer be influenced by physics but it will fire Trigger events on other Rigidbody colliders.
• Material: The Physics Material that determines the friction and bounce of this object. The Physics Material is irrelevant if this is a Trigger Collider.
• Center: The X, Y, Z, position of the Collider relative to the GameObject’s position.
• Radius: The radius of the capsule’s body.
• Height: The length of the capsule body.
• Direction: The axis of the capsule’s lengthwise orientation relative to the the GameObject’s local space.

[Source]

Mesh Collider

The Mesh Collider uses a mesh to define the shape of the collider. Mesh Collider can produce more accurate representations of the collision shape of the object, but it is much more expensive to compute collision detection on complex mesh colliders than using primitive colliders (The Box, Sphere, and Capsule colliders are considered primitive colliders). Don’t use a mesh collider when a primitive collider will work just as well.



Unity – Mesh Collider

The Mesh Collider has the following properties:

• Is Trigger: If true, this collider will be considered a Trigger Collider and will no longer be influenced by physics but it will fire Trigger events on other Rigidbody colliders.
• Material: The Physics Material that determines the friction and bounce of this object. The Physics Material is irrelevant if this is a Trigger Collider.
• Convex: If the Convex property is true, a simplified version of the mesh collider will be generated. Convex mesh colliders will collide with other Mesh Colliders.
• Smooth Sphere Collision: Collision mesh normals are smoothed across the collision faces. This should be enabled on gradually slopped surfaces such as terrains and roads.
• Mesh: The Mesh asset that is used to generate the collision mesh for this Mesh Collider.

Primitive Rigidbody Colliders will perform collision detection on Static Mesh Colliders but Rigidbody Mesh Colliders will not collide with other Mesh Colliders unless one of them is set to Convex.

Compound Colliders

Sometimes it is better to combine several primitive colliders to represent an object rather than use a complex mesh collider. Or maybe you want to combine several objects together so they behave as a single object.

To do this, we simply create a parent-child hierarchy of colliders.



Unity – Complex Colliders

The image above shows a Cylinder with a Sphere at each end of it. The Sphere GameObjects are parented to the Cylinder GameObject. As a result, the combination of all three GameObjects will behave as a single object. If you need the GameObject to be physics controlled, then add a Rigidbody component to the top-level object only. Do not add Rigidbody components to the child GameObjects (if you do, they will behave as separate objects and break off the compound shape).

[Source]

Rigidbodies

The Rigidbody component is required for objects to act under the influence of Physics. You can apply forces and torques to the Rigidbody component from scripts or you can directly manipulate the linear and angular velocity of the Rigidbody if you want more control over it’s behavior.

A Rigidbody component requires a Collider component to be present on the GameObject for correct Physics simulation.

A Rigidbody can either be Physics controlled or Kinematic controlled.

Physics Rigidbody

A Physics Rigidbody is fully controlled by the Physics engine. You can apply forces and torques to manipulate the linear and angular velocities but you cannot move the Rigidbody directly by using the GameObject’s Transform component (well, actually you can update the position and orientation of a Physics Rigidbody but it isn’t recommended).

To create a Physics Rigidbody, simply add the Rigidbody component to the GameObject you want to be influenced by physics and make sure the Is Kinematic property is not checked.



Unity – Physics Rigidbody

Kinematic Rigidbody

A Kinematic Rigidbody will not act under the influence of the physics engine. You cannot apply forces or torques to to a Kinematic Rigidbody (well, actually you can apply forces and torques to a Kinematic Rigidbody but they just wont do anything). You also cannot rely on the Rigidbody’s linear and angular velocity properties being valid.

The only way you can move a Kinematic Rigidbody around the scene is by directly updating the GameObject’s Transform component.



Unity – Kinematic Rigidbody

Properties of a Rigidbody

The Rigidbody component has the following properties:

• Mass: The mass of the Rigidbody. The mass of a Rigidbody should be based on the relative size and density of the object it is attached to. For example, a large feather will have a much lower mass than relatively small rock or stone. The mass has a direct influence on how much force is required to move the Rigidbody. A very large mass will require more force to move it than a similar sized object with less mass. If you remember the formula from your basic physics lessons, then you will know that in order to get am object that weighs 10 kg to a speed of 5 meters per second (m/s) in just one second, you must apply a force of 50 newtons () assuming we neglect all other external forces such as friction, drag, and gravity. An object that has a mass of 5 kg only requires 25 newtons to accelerate it to a speed of 5 meters per second in one second.
• Drag: The Drag parameters controls how fast the object the object’s linear velocity is reduced due to air resistance. With a Drag value of 0, the object will not be affected by air resistance (this simulates how Rigidbodies will behave in outer space). A very high drag can be used to make the object slow down very quickly if no external forces are applied to the rigidbody. An object with a mass of 1 requires a Drag value of approximately 998 to resist the force of gravity.
• Angular Drag: The Angular Drag property is similar to the Linear Drag property in that it is used to slow the angular velocity of the Rigidbody. If you want your Rigidbodies to stop spinning very quickly, set the Angular Drag property to a high value. A value of 0 will allow the Rigidbody to keep spinning indefinitely unless acted upon by an external force (such as friction).
• Use Gravity: Should this Rigidbody be affected by gravity?
• Is Kinematic: This property should be set to true if you want to directly control the position and orientation of the Rigidbody using the GameObject’s Transform component. Kinematic Rigid Bodies will not be influenced by physics and will only collide with other non-kinematic Rigidbody Colliders. Kinematic Rigidbodies will not collide with Static Colliders or other Kinematic Rigidbodies.
• Interpolate: If you find that your Rigidbody is not moving smoothly, you can adjust the interpolation method.
  • None: The position and orientation of the Rigidbody is not smoothed between frames. This is the default value.
  • Interpolate: The position and orientation of the Rigidbody is smoothed based on the position and orientation of the previous frame.
  • Extrapolate: The position and orientation of the Rigidbody is smoothed based on the estimated position and orientation of the next frame.
• Collision Detection: This property determines how this Rigidbody performs collision detection with other Rigidbodies in the scene.
  • Discreet: This is the simplest form of collision detection. At each frame, the current position and orientation of the object is sampled and collision intersection tests are performed on nearby colliders. Using this method of collision detection, it is possible that small, fast moving objects will appear to pass directly through solid objects.
  • Continuous: This Rigidbody will perform Continuous Collision Detection (CCD) against other Static Colliders and also on Rigidbody Colliders whose Collision Detection method is set to Continuous Dynamic. On all other collider types, it will only perform Discreet collision detection.
  • Continuous Dynamic: You should only set this value on fast moving objects. Rigidbodies whose Collision Detection method is set to Continuous Dynamic will perform CCD on other Rigidbodies that are either set to Continuous or Continuous Dynamic. Continuous Dynamic Rigidbodies will also perform CCD on Static Colliders. For all other collider types, it will only perform Discreet collision detection.
• Constraints: The position and orientation of the Rigidbody can be constrained so that it doesn’t move or rotate along specific axes. These constraints will not effect Kinematic Rigidbodies.
  • Freeze Position: Constrain the linear motion of the Rigidbody along one or more global axes. This is useful if you are making a 2D game and you don’t want objects to fly towards or away from the viewer. To prevent motion in the depth, you can simply constrain the motion in the Z-axis.
  • Freeze Rotation: To prevent an object from rotation due to Torque forces, you can constrain the rotation of the Rigidbody along one or more global axes. This may be useful if you want to make a 2D game and you only want objects to rotate around the look-at direction. In this case, you would constrain both the X and Y axes and allow free rotation along the Z-axes.

[Source]

Rigidbody Tutorial

In some cases, you may want to represent your main character by another shape other than an upright capsule. Maybe your main character is a cube, or a sphere? The Character Controller component (described in the next section) may not be suitable for you in this case. But how can we get a Rigidbody Collider to act like a Character Controller?

Create a New Scene

Open Unity and either open an existing project or create a new one.

Create a new Scene if you don’t already have one.



Unity – Rigidbody Tutorial (1)

Create a Plane

Add a Plane GameObject and set it’s properties to:

• Plane
  • Position
    • X: 0
    • Y: 0
    • Z: 0
  • Rotation
    • X: 0
    • Y: 0
    • Z: 0
  • Scale
    • X: 10
    • Y: 1
    • Z: 10

Create a Rigidbody Collider

Create a Cube GameObject and add a Rigidbody component to it. Place it just above the plane so that it doesn’t fall through. Rename the cube to “Rigidbody Collider”



Unity – Rigidbody Tutorial (2)

Create a red Diffuse material and add it to the newly created cube (to learn about materials, refer to my previous article titled Render and Special Effects in Unity 3.5).



Unity – Rigidbody Tutorial (3)

Create a Static Collider

Create another cube without a Rigidbody. Make this one blue. Rename the GameObject to “Static Collider“.



Unity – Rigidbody Tutorial (4)

Create a Trigger Collider

Create another cube without a Rigidbody and set the Is Trigger property on the Box Collider to true. Make it green and rename the GameObject to “Trigger Collider“.



Unity – Rigidbody Tutorial (5)

Trigger Script

Add the following JavaScript (let’s call the script “TriggerAnimation.js”) to the Trigger Collider GameObject:

#pragma strict

@script RequireComponent(AudioSource)
@script RequireComponent(Animation)

var animationClip : AnimationClip;

var enterAudioClip : AudioClip;
var exitAudioClip : AudioClip;

function Awake()
{
	// Add the animation clip and make it default.
	animation.AddClip( animationClip, animationClip.name );
	animation.clip = animationClip;
}

function OnTriggerEnter( other : Collider )
{
	animation[animationClip.name].speed = 1.0;
	animation[animationClip.name].time = 0.0f;
	animation.Play();
	
	audio.clip = enterAudioClip;
	audio.Play();
}

function OnTriggerExit( other : Collider )
{
	animation[animationClip.name].speed = -1.0;
	animation[animationClip.name].time = animation[animationClip.name].length;
	animation.Play();
	
	audio.clip = exitAudioClip;
	audio.Play();
}

This script simply plays an Animation Clip and Audio Clip when another Rigidbody Collider enters and exits the area defined by the Trigger Collider.

Create a simple Animation Clip using the Animation view and drag-and-drop the animation clip from the Project view on to the the Animation Clip property for Trigger Animation script component in the Inspector view.

Get two Audio Clip assets and drag-and-drop the audio clips from the Project view onto the Enter Audio Clip and Exit Audio Clip properties for the Trigger Animation script component in the Inspector view.

Create a Controllable Rigidbody

Add a fourth cube GameObject to the scene. Rename this GameObject to “Rigidbody Controller“.



Unity – Rigidbody Tutorial (6)

Add the following JavaScript (let’s call it “RigidbodyController.js”) to the Rigidbody Controller GameObject.

#pragma strict

@script RequireComponent(Rigidbody)

private var isGrounded = false;

enum MotionMethod
{
	VELOCITY_BASED_MOTION,
	MOVE_BASED_MOTION,
}

var motionMethod = MotionMethod.VELOCITY_BASED_MOTION;

// Multiply the velocity when using the velocity based motion.
var velocityMultiplier = 200.0f;

// Multiply the move distance when using move based motion.
var moveMultipler = 5.0f;

// Multiply the force to make the cube jump.
var jumpMultipler = 500.0f;

function FixedUpdate() 
{
	// Calculate the velocity/move direction based on the user input.
	var moveDirection = Vector3( Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical") ) * Time.deltaTime;
	moveDirection = Camera.main.transform.TransformDirection( moveDirection );
	
	if ( rigidbody != null && !rigidbody.isKinematic )
	{
		switch ( motionMethod )
		{
			case MotionMethod.VELOCITY_BASED_MOTION:
				// Speed up the rigidbocy in the x-z plane. The velocy in the y-axis is maintained so that gravity still works.
				rigidbody.velocity = Vector3( moveDirection.x * velocityMultiplier, rigidbody.velocity.y, moveDirection.z * velocityMultiplier);
				break;

			case MotionMethod.MOVE_BASED_MOTION:

				rigidbody.MovePosition( rigidbody.position + ( moveDirection * moveMultipler ) );
				// Zero the velocity in the X,Z plane.
				// We could do this by "Freezing" the X, Z position of the rigid body in the inspector, but then it would
				// pass-through other rigid bodies without doing collision.
				rigidbody.velocity = Vector3( 0, rigidbody.velocity.y, 0 );
				break;
		}
	
		if ( Input.GetButtonDown("Jump") && isGrounded )
		{
			rigidbody.AddForce( Vector3.up * jumpMultipler );
		}
	}
	else
	{
		// Static Colliders and Kinematic Rigidbody Colliders manipulate the transform directly.
		transform.position += moveDirection;
	}
}

function  OnCollisionStay(collisionInfo : Collision)
{	
	// To be more accurate, you may want to check if the collision normal 
	// is pointing in the opposite direction as gravity.  Then it is more reasonable to 
	// assume that it is colliding with the ground.
	isGrounded = true;
}

function OnCollisionExit( collisionInfo : Collision )
{
	isGrounded = false;
}

The RequireComponent script attribute ensures that the GameObject that this script is being attached to will have a Rigidbody component attached to it.

We also declare a private variable called isGrounded which is used to check if the character is currently standing on the ground.

The Enumeration called MotionMethod is used to switch between velocity-based motion (where the velocity of the Rigidbody is directly affected in order to make the Rigidbody move, and move-based motion where the rigidbody is moved using the Rigidbody.MovePosition method to move the rigidbody. By default, we will use velocity-based motion.

On lines 16, 19, and 22 a few public variables are declared that will be used to multiply the base veclocity, move speed, and jump height to achieve the desired movement.

Since we are performing motion operations on Physics bodies, we should perform these operations in the FixedUpdate method (as opposed to the Update method). The reason for this was discussed in the article titled “Scripting in Unity“.

In the FixedUpdate method, we first determine the relative direction to move based on the input axes. The moveDirection vector is transformed by the transformation matrix of the main camera. This makes the move direction always relative to whatever direction the main camera is facing (so left is always left and right is always right depending on the direction the camera is facing).

On line 30, we first check to see if the rigidbody component is set to Kinematic. If it isn’t then we will use the rigidbody’s velocity property to move the rigidbody through the scene.

If the motion method property is set to velocity-based motion (the first case) then we will create a vector that will be used to manipulate the velocity of the rigidbody directly. Notice that we don’t change the Y-axis of the velocity vector. We do this because we don’t want to cancel the effect of gravity on the rigidbody.

If the motion method property is set to move-based motion (the second case) then we use the rigidbody’s MovePosition method to move the rigidbody in the scene. If we use this method to move the rigidbody, then we must also zero the veloctiy (line 45). If we don’t do this, the rigidbody will maintain any velocity that may have been introduced by a collision. Notice that I don’t zero the velocity in the Y-axis because I don’t want to remove the effect of gravity.

On line 49, we apply a “Jump” force only if the rigidbody is grounded (we don’t want to allow jumping in mid-air). The jump is applied as an upward force on the rigidbody multiplied by the jumpMultiplier.

The else statement on line 54 will be executed if the rigidbody is set to a Kinematic Rigidbody. In this case, the rigidbody will be moved by manipulating it’s Transform component directly.

The OnCollisionStay and OnCollisionExit functions are used to determine if the rigidbody is on the ground or not.

If you play the game now, you may notice the Rigidbody Controller cube will move, but it rolls… How can we fix this?

Hint: Frictionless Physic Material.

Character Controller

The Character Controller component is commonly used on upright biped characters. Using a Character Controller does not require a Rigidbody to be present on the character to get the character to move. Although collision detection will work correctly on Character Controllers, collision resolution will not work automatically; that is, when a Character Controller hits a Rigidbody Collider, it will not automatically apply forces to the Rigidbody Collider in order to get it to move. If you want a (non-static) Rigidbody Collider to react to the Character Controller colliding with it, you must script this yourself.



Unity – Character Controller

The image above shows the green capsule around the Constructor character. The green capsule shows the radius and height of the Capsule Collider created by the Character Controller. It is currently not possible to change the collision shape of the Character Controller to something other than a Capsule.

The Character Controller has the following properties:

• Slope Limit: The maximum slope angle (measured in degrees) the character controller can walk up before he will be pushed back. This is useful for preventing your character from climbing steep slopes on a terrain for example.
• Step Offset: The maximum height the character controller will step over. If an obstacle is higher than Step Offset above the current height of the character controller (measured from the ground), the Character Controller will be blocked by that obstacle. Otherwise, he will step onto the obstacle. Of course, if you want your character to visually look like he is stepping onto the obstacle, you must create an animation for that and play it at the right time.
• Skin Width: This value allows the Collider to interpenetrate with other Colliders. If your character motion is jittery or your character is getting stuck in some cases, chances are your Skin Width is too low. A good rule of thumb is the Skin Width should be about 10% of the Radius property.
• Min Move Distance: If the character is moved less distance than this value, the character will not move at all. Generally, this value should be left at 0.
• Center: The center point of the Capsule Collider relative to the GameObject’s position.
• Radius: The width of the Capsule Collider along the Y-axis. If your character seems to be able to walk partially through walls, you may want to increase the Radius value. If you character can’t get close enough to objects, you may want to decrease the Radius value.
• Height: The height of the Capsule Collider. If the character seems to be floating above the ground, you will want to decrease the Height value. If the character’s feet are sinking into the ground, then you will want to increase the Height value.

Character Controller Tutorial

What do we do if we want our Character Controller to apply forces to other Rigidbody Colliders? The only way we can accomplish this is to apply a force to the other Rigidbody Collider in script.

Create a New Scene

Open Unity with an existing project, or create a new project and create a new Scene.



Unity – Character Controller Tutorial (1)

Add a Plane GameObject and set it’s properties to:

• Plane
  • Position
    • X: 0
    • Y: 0
    • Z: 0
  • Rotation
    • X: 0
    • Y: 0
    • Z: 0
  • Scale
    • X: 10
    • Y: 1
    • Z: 10


Unity – Character Controller Tutorial (2)

Add a Cube and a Sphere GameObject to your scene. Make sure they are placed just above the Plane so that they are not intersecting with the Plane.



Unity – Character Controller Tutorial (3)

Add a Rigidbody Component to both the Cube and the Sphere GameObject. This will allow them to be influenced by Physics.

Duplicate (Ctrl+D) the Cube and the Sphere objects a few times in your scene and place the duplicates so that they are neither intersecting each other nor the Plane.



Unity – Character Controller Tutorial (4)

Add a light to your scene to illuminate the objects.



Unity – Character Controller Tutorial (5)

Optionally, you can also add various Physic Materials to the GameObjects to see how different values for the Physic Material effect the way the Rigidbody Colliders react to being pushed. If you havn’t done so already, you can import the Physic Material standard package that comes with Unity by selecting Assets -> Import Package -> Physic Material from the main menu. You can also create a frictionless material by following the steps outlined in the section about Physics Materials.

Add a Character Controller

If you haven’t done so already, import the Character Controller standard package into your project (select Assets -> Import Package -> Character Controller from the main menu).

The Character Controller prefab provides prefabs for a standard first-person controller and a third-person controller.

Drag-and-drop the “3rd Person Controller” prefab from the “Standard Assets\Character Controllers” folder in your project view into the scene. Make sure the character is placed above and not intersecting with the Plane.



Unity – Character Controller Tutorial (6)

In the Third Person Controller script component attached to the 3rd Person Controller prefab you just created, make sure you set the Idle Animation property to the idle Animation Clip, the Walk Animation property to the walk animation clip, the Run Animation property to the run animation clip, and the Jump Pose Animation property to the jump_pose animation clip.

If you play this now, you will notice that the Constructor character will collide with the Rigidbody Colliders in the scene, but will not push any of them out of the way.

Character Controller Push Script

Fortunately, we can create a script that will push the Rigidbody Colliders by applying a force to the Rigidbody when the Character Controller collides with it.

Create a new JavaScript script asset in your project. You can call it whatever you want, but I called mine “CharacterControllerPushRigidbody“.

Open the newly created script in Mono and add the following code:

#pragma strict

var forceMode : ForceMode = ForceMode.VelocityChange;
var pushPower = 2.0f;

function OnControllerColliderHit (hit : ControllerColliderHit) 
{
	// Get the hit rigidbody (if there is one).
    var body : Rigidbody = hit.rigidbody;

    // no rigidbody
    if (body == null || body.isKinematic)
        return;
        
    // We dont want to push objects below us
    if (hit.moveDirection.y < -0.3) 
        return;
    
    // Calculate push direction from move direction, 
    // we only push objects to the sides never up and down
    var pushDir : Vector3 = Vector3 (hit.moveDirection.x, 0, hit.moveDirection.z);

    // Apply the push
	body.AddForceAtPosition( pushDir * pushPower, hit.point, forceMode );
}

The first thing we see in this script (after the "#pragma strict" statement) is a variable called forceMode of type ForceMode. This variable determines how the force is applied to the Rigidbody that we collided with. The ForceMode enumeration has the following values:

• Force: Adds a force to the Rigidbody taking the Rigidbody's mass into consideration. Using this method, larger forces will be needed in order to accelerate Rigidbodies with greater mass.
• Acceleration: Adds a continuous acceleration to the Rigidbody, ignoring it's mass. Using this mode, the object will immediately accelerate regardless of it's mass.
• Impulse: Adds an instatnous force impulse to the Rigidbody taking it's mass into consideration.
• VelocityChange: Instantly changes the velocity of the Rigidbody regardless of it's mass.

On line 4, we declare a variable called pushPower. This value determines the amount of force, acceleration, impulse, or velocity (depending on the value of the forceMode variable) that will be applied to the Rigidbody we collided with.

On line 6, we declare a function called OnControllerColliderHit. This method is valid on GameObjects with a Character Controller component attached to them. It is invoked when the Character Controller collides with another Collider (Rididbody Collider or Static Collider) while performing a Move. This method takes a single argument called hit of type ControllerColliderHit that is used to determine which other Collider was hit and where it was hit.

On line 9, we extract the Rigidbody component that was hit (if there is one).

If the Collider we hit is a Static Collider (that is, it does not have a Rigidbody) or it is a Kinematic Rigidbody Collider (in which case, it is not physics controlled), then we don't want to do anything.

For this script, we will also ignore collisions that occured while the Character Controller is falling (it's move direction in the Y-axis is less than 0).

On line 21, we create a direction vector which represents the direction the Character Controller was moving (in the XZ-plane) when the collision occured.

And finally on line 24, we apply a force to the Rigidbody at a paticular point in global space. This is done by calling the AddForceAtPosition method on the Rigidbody.

The Rigidbody.AddForceAtPosition function takes the following arguments.

• force : Vector3: The direction and magnitude of the force to apply to the Rigidbody.
• position : Vector3: The position in world space to apply the force. If this position is not the same as the current position of the Rigidbody then an angular force as well as a linear force will be applied to the Rigidbody. This could cause the Rigidbody to start spinning.
• mode : ForceMode: The type of force that will be applied to the Rigidbody (see ForceMode described above).

Now attach this script to your 3rd Person Controller GameObject and run the game again. Your character should be able to push the Rigidbody Colliders out of the way if he tries to walk through them.

Don't forget to save your scene.

Try This...

Assign different Physic Materials to the Rigidbodies to see how it changes the way the Character Controller interacts with them.

Change the value of the Push Power property to change the amount of force that is applied to the Rigidbody.

Change the Force Mode property. Which mode works the best?

Joints

Unity provides several types of Joints that you can use in your scene. A Joint is a constraint that is defined between two Rigidbodies. For example, the Hinge Joint can be used to create a door that can swing open along a particular axis.

A Spring Joint can be used to create an invisible spring that tries to keep two rigid bodies together.

A Fixed Joint can be used to keep two Rigidbody objects together at a constant distance and orientation. This is useful if you need to "parent" a Rigidbody to another Rigidbody and possibly them to break-apart if the force or torque between them exceeds a certain threshold.

The Configurable Joint allows you to create complex joint configuration that can either mimic the Spring and Hinge joint types, but also allow you to create other types of joints as well (such as pivot, ball-and-socket, saddle, and gliding joints).

Hinge Joint

A Hinge Joint component can be used to constrain one Rigidbody to another along a particular axis.

The GameObject that will be used to create a Hinge Joint must have a Rigidbody component. If you don't want the Rigidbody to be influenced by the forces applied by the joint, then make the Rigidbody Kinematic.

When referring to the Rigidbody components that participate in the joint constraint, the Primary body will refer to the Rigidbody that defines the joint and the Connected body will refer to the Rigidbody that is connected to the joint.



Unity - Hinge Joint

The Hinge Joint has the following properties:

• Connected Body: The other Rigidbody that this hinge joint is dependent on. This parameter is optional. If it is not specified, then it will be connected to a fixed point in space. This is simlar to attaching the joint to a Kinematic Rigidbody.
• Anchor: The Anchor point defines the position of the joint relative to the primary body. This will be the point at which the primary and connected bodies rotate.
• Axis: The axis of rotation for the joint relative to the primary body. For a door hinge, this will alsmost always be (0,1,0) (if the primary body isn't rotated).
• Use Spring: If Use Spring is checked, then the spring properties will be used to apply a spring force on the hinge joint that will try to keep the primary and connected Rigidbodies at a relative angle from eachother.
  • Spring: The spring force constant to apply to the joint to try to get to the target angle. Greater values will create a very strong spring while lower values will create a weak spring.
  • Damper: The damper is used to slow the spring recoil. If you don't want the spring to overshoot when it recoils, set the Damper value high. If you want the spring to overshoot and swing back and forth before it comes to rest, set the damper value to 0.
  • Target Position: This property is actually used determine the relative angle (measured in degrees) where the rest is considered "at rest". This angle can be animated at runtime through scripting to simulate automatic opening doors.
• Use Motor: If this value is checked, then a motor force will be applied to the hinge joint. The motor joint can be used to simulate propellors, turnstiles, or revolving doors.
  • Target Velocity: The motor will try to maintain this velocity (measured in degrees per second) to keep the hinge rotating around it's Axis.
  • Force: The amount of force to apply to the joint in order to maintain the desired velocity. With a force of 0, the motor will not start working until it is influenced by an outside force and it will stop very easily if something gets in it's way. With a large force, it will start spinning immediatly and it will push other Rigibodies out of the way if they are hit by the Rigidbody attached to the hinge.
  • Free Spin: If enabled, the motor will not be used to slow the joint's rotation velocity (if for example, it starts spinning faster than the Target Velocity because an external force hit the door very hard) but it will only be used to accelerate the door to the Target Velocity if it was spinning slower.
• Use Limits: If this is checked, then angular limits will be imposed on the hinge joint.
  • Min: The minimum angle (measured in degrees) that this hinge can swing.
  • Max: The maximum angle (measured in degrees) that this hinge can swing.
  • Min Bounce: How much the hinge will bounce when it reaches the minumum limit angle. A bounce value of 0 will cause the hinge not to bounce while a bounce value of 1 will cause the hinge to bounce with no loss of energy.
  • Max Bounce: How much the hinge will bounce when it reaches the maximum limit angle. A bounce value of 0 will cause the hinge not to bounce while a bounce value of 1 will cause the hinge to bounce with no loss of energy.
• Break Force: If the amount of linear force imposed on the hinge joint is greater than this value, the hinge will break and the participating Rigidbodies will no longer be constratined.
• Break Torque: If the amount of angular force imposed on the hinge joint is greater than this value, the hinge will break and the participating Rigidbodies will no longer be constratined.

[Source]

Spring Joint

TODO

[Source]

Fixed Joint

TODO

[Source]

Character Joint

TODO

[Source]

Conclusion

References

The Unity Component Reference Manual was used to gather the information required to write this article.

The Unity Component Reference Manual can be accessed here:

http://docs.unity3d.com/Documentation/Components/index.html

]]> http://3dgep.com/?feed=rss2&p=4027 4 http://3dgep.com/?p=3856 http://3dgep.com/?p=3856#comments Mon, 24 Sep 2012 14:29:32 +0000 Jeremiah van Oosten http://3dgep.com/?p=3856 Continue reading →]]>

Lightmapping

In this article, I will introduce the reader to the different rendering components in Unity. I will introduce the Camera component as well as the different lighting components that are available. I will also talk about materials in Unity and introduce you to a few of the shaders that are available. And finally, I will also introduce light-mapping in Unity.

If you haven’t used Unity before, you can refer to my previous article titled “Introduction to Unity” available here: http://3dgep.com/?p=3246.

Table of Contents

1. Introduction
2. Rendering Components
   1. Camera
      1. About Cameras
         1. Position and Orientation
         2. Projection
      2. Camera Component
   2. Skybox
   3. Lights
      1. Directional Lights
      2. Point Lights
      3. Spot Lights
      4. Light Properties
3. Materials and Shaders
   1. Normal Shaders
      1. Vertex Lit
      2. Diffuse
      3. Specular
      4. Bumped Diffuse
      5. Bumped Specular
      6. Parallax Diffuse
      7. Parallax Specular
      8. Decal
      9. Diffuse Detail
   2. Transparent Shaders
   3. Transparent Cutout Shaders
   4. Self-Illuminated Shaders
   5. Reflective Shaders
4. Light Mapping
   1. Create a New Scene
   2. Create a Box
   3. Add Some Color
   4. Create a Light
   5. Create the Lightmap
      1. Single vs Dual Lightmaps
      2. Direct vs Indirect Lighting
   6. Bake Settings
   7. Make Objects Static
   8. Ligtmapping Lights
   9. Emissive Materials (Pro Only)
   10. Emissive Materials on Dynamic Objects
5. Conclusion
6. Resources

 

Introduction

Lighting and special effects are an integral part of every polished game. Lighting is very import when setting the general mood or atmosphere of your game. Proper lighting can mean the difference between a game that looks like it has been made by a group of programmers, or a highly polished game made by professionals. The general mood of your game is set by the use of lighting in your levels. To convey a mood of “fear” is achieved through sparse use of lighting in strategic locations. However, you can achieve the opposite mood by using bright lights that bring out the vivid colors of your game.

Lighting can be achieved using a few dynamic light sources, or through a process known as lightmapping where the lighting information is rendered into a texture that is placed on the static objects in your scene. But the best application of lighting is a combination of both dynamic light sources and baked lightmapping.

Special effects are used to add that “wow” factor to your game. When used correctly, they can add an extra boost to your gameplay that will keep the players coming back for more. In this article, I will introduce the Shuriken particle editor that was added to Unity in version 3.5. I will talk about the various module that are used to make an individual particle system and how you can combine particle systems to make complex particle effects.

I will also introduce a technique called lightmapping. Unity includes the Beast lightmapper and doesn’t require a pro license to use it.

Rendering Components

The Render Components are the group of components that effect in-game rendering such as cameras and lights.

Camera

The Camera component is used to capture a view of the world and display it to the player. Without at least one Camera component attached to a GameObject in the scene, you will simply see a gray screen. When you create a new scene, Unity will automatically place a single GameObject called “Main Camera” in your new scene by default.

You can have as many cameras in your scene as you want, but generally you will only have one main camera that is used to display your game.



Unity – Camera Component

About Cameras

The Camera determines what you see and how it appears on screen. The camera has several properties that are common to all camera types regardless if it is used by Unity or not. It is important to understand these properties to properly configure your camera’s view. These properties include position and orientation, projection, near and far clipping planes, field of view (for perspective projection), size (width and height for orthographic projection), and in some cases viewport size.

Position and Orientation

In Unity, the Camera component is attached to a GameObject that is placed in your scene. The GameObject’s position and orientation in the world will determine what the Camera is looking at. The Camera will always look in the direction of the GameObject’s positive Z axis.



Unity – Camera View – Perspective

As can be seen in the image, the camera is pointing in the positive Z axis (represented by the blue arrow in the image).

Projection

The Projection determines how objects are mapped from a 3D space (usually View Space) into a clipped camera space (called Clip Space). There are two common types of projections that can be applied to the camera: Perspective Projection or Orthographic Projection.

Perspective Projection

A Perspective Projection is the most common type of projection you will use in your game. Using this type of projection, objects that are close to the camera will appear larger than objects that are placed farther away from the camera. This is also how the human eye works.

Using a Perspective Projection an additional property becomes available called the Field of View. This value measures the vertical viewing angle. Making the Field of View angle smaller (closer to 0), objects will appear zoomed-in and making the Field of View larger (angle closer to 180) will cause objects to appear zoomed-out.

Using this type of projection the View Frustum resembles a Pyramid with it’s top cut-off (see the image above).

Orthographic Projection

An Orthographic Projection is more commonly used for 2D side-scrolling or platforming games. The Orthographic projection is also useful when displaying GUI elements on screen (although Unity handles this for your when you use GUITexture and GUIText and when using the GUI API to create menus). With an Orthographic Projection, objects will appear the same size regardless of how far they are from the camera.

Using the Orthographic Projection you will have an additional property called Size that determines the width and height (but not the depth) of the view frustum. Making the Size smaller will cause objects to appear zoomed-in and making the Size larger will cause objects to appear zoomed-out.

The shape of the View Frustum resembles an elongated box (see image below).



Unity – Camera View – Orthographic

Camera Component

The Camera component has the following properties:



Unity – Camera Component

• Clear Flags: Determines how the screen is cleared before the scene is rendered. The following options are available:
  • Skybox: This is the default clear flag. If the GameObject the Camera component is attached to also has a Skybox component, the Skybox material will be used to clear the screen before rendering. If no Skybox is configured, the Background color property is used to clear the screen.
  • Solid Color: Use the Background color to clear the screen.
  • Depth Only: Do not clear the color buffer, only clear the depth buffer. This is useful for some post-processing effects where only the depth values are taken into consideration.
  • Don’t Clear: Neither the color buffer nor the depth buffer are cleared.
• Background: Specifies a background color to use when either Solid Color is specified for the Clear Flags or when Skybox is specified for the Clear Flags but no Skybox has been configured.
• Culling Mask: The Culling Mask property allows you to specify which Layers should be rendered with this Camera component. By default, all layers are rendered.
• Projection: Specifies the type of camera view. Valid values are Perspective and Orthographic.
  • Perspective: This is the default view type. With a Perspective projection objects closer to the Camera will appear larger than objects farther away. This is the default view and the one most commonly used to render 3D games.
  • Orthographic: With an Orthographic projection, objects that are farther away from the Camera will not appear smaller than objects closer to the Camera. In other words, objects in your game will not demonstrate perspective. This view type is useful for 2D games, isometric games, and top-down views of your game world (for example, to generate a mini-map display).
• Field of View: This option is only available when the Projection property is set to Perspective. This option controls the zoom level of your Camera. This is similar to putting a zoom lens on your own Camera or looking through a pair of binoculars. With a smaller field of view, objects will appear zoomed-in but with a large field of view, things will appear very far away. The default value is 60 degrees but values in the range of 45 degrees to 90 degrees will generally still look okay. Smaller or larger field of view may appear distorted.
• Size: This option is only available when the Projection property is set to Orthographic. This property determines the size of the box that is formed by the orthographic view. Making the orthographic size smaller will make the objects in your scene appear zoomed-in and making the size larger will make the objects in your scene appear zoomed-out.
• Clipping Planes: The clipping planes determine the range of your camera’s view. Objects outside of the range of the clipping planes will be clipped. It’s generally a good idea to keep the Near and Far clipping planes close together. Setting the clipping planes too far apart will result in a rendering artifact known as Z-Fighting.
  • Near: The Near clipping plane determines how close an object can be to the Camera before it will be clipped from view. It is generally a good idea to keep this value in the range 0.1 to 0.5.
  • Far: The Far clipping plane determines how far an object can be from the Camera before it will be clipped from view. This value should only be as large as absolutely necessary and not larger. For indoor environments, the Far clipping plane can be set fairly close to the Near clipping plane since objects far away will be occluded by the walls of your level. For outdoor scenes you may need to make Far clipping plane farther away but don’t make it larger than needed.
• Normalized View Port Rect: The View Port Rect determines where this Camera will be rendered on the screen. This parameter is useful for implementing split-screen gameplay.
  • X: The normalized distance from the left side of the screen to display the view of the Camera.
  • Y: The normalized distance from the bottom of the screen to display the view of the Camera.
  • W: The normalized width of the view of the Camera.
  • H: The normalized height of the view of the Camera.
• Depth: This property determines the order in which this Camera will be rendered. Valid values for the Depth of the Camera are -100 to 100. Camera components with a lower Depth value will be rendered before Camera components with a higher Depth value. The default value is 0.
• Rendering Path: This property determines the rendering method used for this Camera.
  • Use Player Settings: The Camera will use whatever settings are configured in the Player Settings dialog.
  • Vertex Lit: Lighting is computed per-vertex instead of per-pixel. This rendering method is faster than forward rendering but produces lower quality renders.
  • Forward: This is the standard rendering method used. It produces high quality results but is performance bound by the number of lights used in your scene.
  • Deferred Lighting (Pro Only): Deferred lighting means that lighting information will be computed after all other information (such as depth, screen-space normals, and specular contribution) has been rendered into several screen-space buffers (called the G-Buffer). Deferred lighting allows for many dynamic lights to be computed efficiently. Deferred lighting requires graphics hardware with support for Shader Model 3.0 (SM3.0) which is available on most desktop GPUs but currently not available on most mobile platforms.
• Target Texture (Pro Only): This allows you to specify a texture (actually a Render Target) where the view of the Camera will be rendered into. This texture can then be applied as a standard texture to other objects in your scene. This is useful for implementing things like a security camera in your scene that is displayed on a monitor somewhere else in the scene. It can also be used to create a “Picture-in-Picture” effect for your main GUI. If set to None (the default value) then the Camera will render to the screen.
• HDR (Pro Only): Enable High Dynamic Range rendering for this Camera. By default, the red, green, and blue channels have a value in the range 0 to 1.0 (with 256 shades per channel). With HDR enabled, colors are stored as 32-bit floating-point values that can exceed 1.0. This means that overly bright colors will be handled correctly and post-processing effects (like HDR bloom) can be applied correctly. Before being rendered on-screen, the HDR colors will be shifted back in the 0 to 1.0 range using a technique called HDR tonemapping. For more information about HDR rendering, please refer to the online documentation here: http://docs.unity3d.com/Documentation/Manual/HDR.html

[Source]

Skybox

The Skybox component is used to draw an environment that appears infinitely far away from the camera. You can imagine it as an infinitely large box that is centered at the position of the Camera. The Skybox component has a single property called Custom Skybox which allows you to assign a skybox material.



Unity – Skybox Component

A Skybox material uses the RenderFX/Skybox Shader which uses 6 textures to render the sides of the skybox cube (front, back, left, right, top, and bottom).



Unity – Skybox Material

If you want to define a default Skybox that will be automatically applied to all cameras in your scene (whose Clear Flags parameter is set to Skybox) you can assign a Skybox material to the Skybox Material property in the Render Settings dialog (select Edit -> Render Settings from the main menu).



Unity – Render Settings – Skybox Material

If you specify the Skybox Material in the Render Settings dialog, that Skybox will also appear in the Scene view.

Unity comes with a few Skybox materials that you can use in your own games. To import the Skyboxes package, select Assets -> Import Package -> Skyboxes from the main menu.

Lights

By default when you create a new scene, you will not have any lights in your scene. Without lights, all objects in the scene will have a dark-gray color. This dark-gray color is the default color of the Ambient Light property defined in the Render Settings dialog (select Edit -> Render Settings from the main menu).



Unity – Ambient Light Only

Unity provides 3 light types (excluding the Area Light which is only available with the Pro license):

• Directional Lights
• Point Lights
• Spot Lights

Each light type is implemented with the Light component but the light type is chosen from the Type property of the light.

Directional Lights

Directional Lights are most common in outdoor scenes. Directional Lights mimic the behavior of the Sun, that is, they will illuminate everything in the scene regardless of the position of the directional light relative to other objects in the scene. If you place an object behind a directional light, the object will be lit according to the direction of the light but the position of the light will be ignored. Directional Lights will always point in the direction of the GameObject‘s Z axis.



Unity – Directional Light

As you can see from the image above, the directional light is placed above the sphere and pointing in the direction of the capsule, but all three shapes are lit as if the light was placed infinitely far away.

Directional Lights are also the only light type that can be used to generate shadows in the default rendering mode (forward rendering).

Real-time dynamic shadows are only supported with a Unity Pro license but you can achieve static shadows using light mapping.

Point Lights

Point lights emit light evenly in all directions and unlike Directional Lights, the position of point lights is very important but their direction is irrelevant.

Point Lights are most commonly used as localized light sources such as light bulbs, illuminating explosions, or used to complement other particle effects like fire and flames.



Unity – Point Lights

As can be seen from the image, the Point Light has a maximum range indicated by the yellow sphere. You can click and drag the handles on the yellow sphere to adjust the range of the light.

You will also notice that the intensity of the light decreases as the point being lit is further away from the light. This effect is called Attenuation of the light. The Attenuation of the light is dependent on both the Range and the Intensity of the light.

Spot Lights

Spot Lights are a combination of Point Lights and Directional Lights. The Spot Light is the only light type for which both the position and direction of the light are taken into consideration when computing the contribution of the light. Just like Directional Lights, Spot Lights will always point in the direction of the GameObject‘s positive Z axis.

Spot Lights are most commonly used as light sources for flashlights, headlights for a vehicle, or light emitting from a street lamp.



Unity – Spotl Light

Spot Lights also exhibit Attenuation (as the point being lit is further away from the light, the intensity of the light decreases). Again, the range and intensity of the light will contribute to the Attenuation of the light.

The size of the Spot Light’s cone angle is controlled by the Spot Angle property. The intensity of the Spot Light is also effected by the difference in the angle to the spot being lit and the direction of the Spot Light. As the angle between these increases, the intensity of the light decreases. This effect is called intensity fall-off. This fall-off effect produces a more realistic lighting result but unfortunately, the intensity fall-off factor is not configurable in Unity.

Light Properties

The Light component has the following properties:

• Type: Determines the type of the Light component.
  • Spot: A Spotlight which simulates a cone shaped light pointing in the local Z-axis.
  • Directional: A Directional light which illuminates all objects in the scene from a single direction. Position is irrelevant.
  • Point: A Point light shines light in every direction equally. Only objects within Range distance are affected by the light.
• Range: This property is only available if the Type is either Spot or Point. This value determines the distance (in world units) at which the light will affect an object. Objects beyond this distance from the light will not be illuminated by the light.
• Spot Angle: This property is only available if the Type is set to Spot. This value determines the cone angle (measured in degrees) of the spotlight cone.
• Color: The primary color of the light. This value determines both the diffuse and specular contributions of the light.
• Intensity: The brightness of the light.
• Cookie: The alpha channel of the Cookie texture is used to determine the brightness of the light. If the Light is of Type Spot or Directional, then this must be a 2D Texture. If the Light is of Type Point, then this must be a Cubemap.
• Cookie Size: This property is only available if the Type is set to Directional. This property allows you to scale the cookie texture that is applied to the Directional light.
• Shadow Type (Pro only): Shadows are only available with the Pro license. Using the Forward rendering path (see Camera Properties), only Directional lights produce shadows. Using the Deferred rendering path, Point and Spot lights also produce shadows.
  • No Shadows: This light does not produce shadows.
  • Hard Shadows: The light produces hard shadows. This is the preferred method for generating shadows because it is cheaper to compute.
  

  Unity – Hard Shadows

  • Soft Shadows: This method produces shadows with blurred edges. This method is slower than Hard Shadows, but it produces a better result.
  

  Unity – Soft Shadows

• Strength: The darkness of the shadow will be multiplied by this value to reduce the intensity of shadows produced by this light.
• Resolution: This property determines the size of the shadow map texture used by this light. Very High Resolution will produce better shadows at the expensive of speed and memory.
• Bias: If the light produces an effect called Shadow Acne then you can adjust the Bias parameter to resolve the artifacts. However, setting the Bias parameter too high may cause Peter Panning.
  

  Unity – Shadow Acne

  

  Unity – Peter Panning

  In the image above, the cylinder appears to be “floating” above the plane when in fact, the cylinder is placed exactly on the plane.

• Softness: This parameter is only available if Shadow Type is set to Soft Shadows. This parameter is used to scale the size of the soft are of the shadow (the outer edge of the shadow where it begins to soften). Valid values are in the range [1 .. 8]. With a value of 1, the shadow will appear to be a Hard Shadow. With a value of 8, the shadow will appear soft around the “penumbra”.
• Softness Fade: This parameter is only available when Shadow Type is set to Soft Shadows. This value determines the intensity of the shadow penumbra (the soft edge of the shadow that is partially in shadow) based on the distance from the camera.
• Draw Halo: Draws a Halo effect at the position of the light. Although this property can be assigned to Directional lights, it usually doesn’t make sense to add this to a directional light because Directional lights don’t really have a position, only a direction. This property should only be set on positional lights light Point and Spot lights. Optionally, a Halo effect can also be achieved using a Halo component.
• Flare: Adds a Flare effect to the light. The Flare effect mimics a Lens Flare effect that is seen on camera lenses in real reality. This parameter accepts a Flare texture. Optionally, this effect can be achieved using a Flare component.
• Render Mode: This property determines how and when the light is applied to objects.
  • Auto: The quality of the light renderer is determined by the proximity and intensity of the light relative to the object being rendered.
  • Important: This light will always be rendered using per-pixel lighting shaders.
  • Not Important: This light will always be rendered using per-vertex lighting shaders.
• Culling Mask: Include or exclude objects assigned to different layers from being affected by the light.
• Lightmapping: This property determines how this light contributes to the Ligthmapping process.
  • Auto: Uses real-time dynamic lighting when the light is close to the camera and baked lighting information is used when the light is far away from the camera. This technique requires dual lightmaps to be baked for your scene.
  • Realtime Only: Lighting information for this light will not be baked into the lightmap. This is useful if your light’s properties (Color or Intensity for example) will change at run-time.
  • Baked Only: This light is not simulated at run-time. It is only used as a light source for the light map. This is useful for static lights that will not change at runtime. Do not use this setting on lights that should generate dynamic shadows at run-time.

Materials and Shaders

A Shader is the source code that defines how a particular effect is rendered. A Material uses a Shader and the Material exposes the properties defined in the Shader to the Inspector. Also, you cannot apply a Shader directly to a GameObject in the scene, but instead you must apply a Material to the GameObject.

Unity provides a set of built-in shaders that you can use in your games. The built-in shaders are split into groups called Shader Families. Each Shader Family defines several variants of the base shader type for that family.

The different Shader Families you have available in Unity are:

• Normal Shader Family: These are probably the most common shader type. It is used on opaque objects that do not need to appear transparent or light-emitting.
• Transparent Shader Family: These shaders are used on transparent objects that are either fully, or semi-transparent.
• Transparent Cutout Shader Family: These shaders are used on objects that have either opaque or fully transparent pixels. This is useful for solid objects that contain holes like a fence, or a chain link, or blades of grass.
• Self-Illuminated Shader Family: These shaders will simulate an object that emits light. In this case, the object will appear lit even if there are no lights illuminating the object. Objects with a Self-Illuminated shader applied to them will not illuminate other objects!
• Reflective Shader Family: These shaders allow you to apply a reflective cube map on the material. The alpha channel of the base texture is used to determine the amount of reflectivity that is applied at each pixel.

[Source]

Normal Shaders

The Normal Shader Family define the most basic shaders used in Unity. This shader type is used on opaque objects that do not have any transparency or emissive properties.

This shader family has several variants and each variant defines different properties that effect the way the shader is rendered.

Vertex Lit

The Vertex Lit variant performs only per-vertex lighting and does not perform any per-fragment lighting or lighting effect that require per-fragment processing like light cookies, normal mapping, or shadows.

This is a fast shader and should be used whenever correct lighting results are not very important. It is recommended you use this shader type on small objects or objects that are placed far away from the camera.



Unity – Vertex Lit

The Vertex Lit shader has the following properties that are exposed in the Material:

• Main Color: The Main Color property can be used to lighten or darken the Base texture. If the Main Color is white, then the texture will appear as it is in the Base texture. If it is black, then the texture will appear black.
• Sepc Color: This Spec Color is used to determine the color of the specular highlight.
• Emissive Color: The Emissive Color is added to the base texture and can be used to brighten the object even in the absence of light.
• Shininess: The Shininess property determines how shiny the surface of the object appears. A low shininess value will result in a large specular highlight and a high shininess value will result in a small specular highlight.


Unity – Vertex Lit (low shininess)



Unity – Vertex Lit (high shininess)

• Base (RGB): The Base texture that is used to apply the image to the object. Textures can be scaled on the object by adjusting the Tiling property and the texture can be offset by adjusting the Offset parameter.
  • Tiling: This property determines how many times the texture is repeated across the surface of the object in each direction.
  

  Unity – Vertex Lit (2 x Tiling)

  

  Unity – Vertex Lit (half tiling)

  • Offset: As the name suggests, the Offset parameter is used to shift the texture across the object.

[Source]

Diffuse

The Diffuse shader computes per-pixel lighting contribution using the Lambert reflectance lighting model. This shader will not produce specular highlights.



Unity – Diffuse

Specular

The Specular shader adds an additional parameter to control the specular shininess.



Unity – Specular

Bumped Diffuse

The Bumped Diffuse shader adds an additional texture parameter called the Normalmap. The Normalmap texture is used to add additional detail to the surface of the object without adding additional vertices to the model. This shader does not produce a specular highlight.



Unity – Bumped Diffuse

Bumped Specular

The Bumped Specular shader adds a specular highlight property to the material.



Unity – Bumped Specular

Parallax Diffuse

The Parallax Diffuse shader adds additional parameters for Height and Heightmap. The Height property is a scalar property that is used to adjust the apparent height of the surface of the object and the Heightmap texture property uses the Alpha channel of the texture to determine high and low parts of the surface. The opaque parts of the alpha map will appear extruded while transparent parts of the alpha map will appear recessed.

This shader is generally applied to brick and mortar textures where you want the bricks to appear higher than the mortar grout.



Unity – Parallax Diffuse

Parallax Specular

The Parallax Specular shader is similar to the Parallax Diffuse shader except it has an additional property for the Specular Color and the Shininess values.



Unity – Parallax Specular

Decal

The Decal shader is similar to the Diffuse shader with an additional texture that is placed on top of the original texture. The Decal texture is not blended with the Base texture, it just replaces the pixel behind it.



Unity – Decal

Diffuse Detail

The Diffuse Detail shader exposes an addition texture parameter that is used to add detail to a texture when the camera is close to the surface. The Detail texture will be faded-in as the camera gets close to the surface. The purpose of this shader is to hide the filtering artifacts that become visible when you look closely at low-resolution textures.



Unity – Diffuse Detail

Transparent Shaders

TODO

[Source]

Transparent Cutout Shaders

TODO

[Source]

Self-Illuminated Shaders

TODO

[Source]

Reflective Shaders

TODO

[Source]

Light Mapping

Lightmapping is the process of computing high-quality lighting information and storing this information in a texture. This texture is “mapped” over the static objects in your scene which gives the impression of high-quality lighting at run-time. The process of generating the light maps is called baking the lightmaps.

Unity comes with a built-in lightmapping program called Beast that you can use in the free version of Unity to generate static lightmaps for your scenes.

To understand how lightmapping works in Unity, we will create a simple scene that uses lightmapping to generate direct and indirect lighting information for your scene.

Create a New Scene

Start Unity and create a new empty project. Let’s call this new project Lightmapping. For this example, you do not need to import any of the standard packages.



Unity – New Project (Lightmapping)

Unity will automatically create a new empty scene for you.



Unity – New Scene (Lightmapping)

Save the scene and call it Lightmapping.

Create a Box

Create 5 planes in your scene with the following properties:

• Back Plane
  • Name: Back
  • Position
    • X: 0
    • Y: 0
    • Z: 5
  • Rotation
    • X: 270
    • Y: 0
    • Z: 0
• Bottom Plane
  • Name: Bottom
  • Position
    • X: 0
    • Y: -5
    • Z: 0
  • Rotation
    • X: 0
    • Y: 0
    • Z: 0
• Left Plane
  • Name: Left
  • Position
    • X: 0
    • Y: -5
    • Z: 0
  • Rotation
    • X: 0
    • Y: 0
    • Z: 270
• Right Plane
  • Name: Right
  • Position
    • X: 5
    • Y: 0
    • Z: 0
  • Rotation
    • X: 0
    • Y: 0
    • Z: 90
• Top Plane
  • Name: Top
  • Position
    • X: 0
    • Y: 5
    • Z: 0
  • Rotation
    • X: 0
    • Y: 180
    • Z: 180

Your scene should look something similar to what is shown below.



Unity – Lightmapping (1)

Add Some Color

The scene looks pretty boring at this point with no colors. Let’s color two of the walls in our room. We’ll color the left wall red, and the right wall blue.

Create two new materials. Name the first material to Red_Material and the second material to Blue_Material



Unity – Lightmapping (2)

Select the Red_Material and set it’s Main Color property to Red.



Unity – Lightmapping (3)

Select the Blue_Material and set it’s Main Color property to Blue.



Unity – Lightmapping (4)

Drag-and-Drop the Red_Material from the Project view onto the Left wall.
Drag-and-Drop the Blue_Material from the Project view onto the Right wall.



Unity – Lightmapping (5)

Place 2 cubes in the scene with the following properties:

• Cube
  • Name: Cube01
  • Position
    • X: 2
    • Y: -1.5
    • Z: 1
  • Rotation
    • X: 0
    • Y: 45
    • Z: 0
• Cube
  • Name: Cube02
  • Position
    • X: -2.5
    • Y: -3
    • Z: 0
  • Rotation
    • X: 0
    • Y: 0
    • Z: 0

Your scene should now look something like this:



Unity – Lightmapping (6)

Save your scene.

Create a yellow material (call it Yellow_Material) and place it on Cube02.



Unity – Lightmapping (7)

Now let’s put a light in the scene.

Create a Light

Create a Point light in the scene with the following properties:

• Point light
  • Position
    • X: 0
    • Y: 4.5
    • Z: 0
  • Range: 12

Leave all other properties as the default.



Unity – Lightmapping (8)

Our scene is looking a little better now with this point light, but I think it can get better.

Create the Lightmap

Up to this point, we havn’t done anything that we havn’t seen before (if you have been following the previous articles then you will already have had some experience placing lights in the scene). Now we are going to add some realism to the scene by pre-computing the lighting information into a lightmap that is otherwise very difficult to achieve at real-time frame-rates.

Open the Lightmapping view (select Window -> Lightmapping from the main menu) .



Unity – Lightmapping Dialog

Click the Bake button at the top of the Lightmapping view to show the Bake settings.

Set the Mode to Single Lightmaps.

Single vs Dual Lightmaps

Single lightmaps will generate a single lightmap for the entire scene. Single lightmaps will generate full lighting information for the lights in your scene that are set to Auto or Baked Only. Single lightmaps take less time to bake because Beast only needs to generate one set of lightmaps instead of two. Single lightmaps are required when using the forward rendering mode.

Dual lightmaps are supported for deferred rendering mode. Dual lightmaps will generate two sets of lightmaps; Near, and Far lightmap sets. The Near lightmaps will store indirect lighting information for real-time lights while the direct lighting contributions will be computed from the real-time lights in the scene (unless they are set to Baked Only). The Far lightmaps will be baked with both direct and indirect lighting contributions for lights in the scene that are marked Auto or Baked Only. Realtime Only lights will still be used to compute direct lighting on Far objects but dynamic shadows will be disabled.

The transition between the Near and Far lightmaps is determined by the Shadow Distance property in the project’s Quality Settings window (select Edit -> Project Settings -> Quality from the main menu).

For the purpose of this exercise, we will only use Single lightmaps.

For more information on Single and Dual lightmaps in Unity, please refer to the Lightmapping In-Depth page on the Unity website here: http://docs.unity3d.com/Documentation/Manual/LightmappingInDepth.html.

Direct vs Indirect Lighting

Direct lighting is the light that comes directly from the light source. In reality, when light hits an object, the light will “bounce” (or reflect) off of an object’s surface and it may go on to hit something else. This “bounced” light causes the indirect illumination of surfaces around that object.

Indirect light is the contribution of light that is reflected from surfaces and contributes to the illumination of surfaces in close proximity.

Indirect light cannot be simulated using standard rasterization techniques that are generally used to render your game. But the indirect lighting contribution from environment lighting or lighting that is reflected from nearby objects can be simulated by baking this information into a lightmap. The lightmap generator will use a rendering technique that is well suited for computing the indirect lighting contributions but is not well suited for real-time rendering and therefor this information can be pre-baked into the lightmaps for use at run-time.

Bake Settings

Open the Lightmapping view if it isn’t open already.



Unity – Lightmapping Dialog

Set the Mode to Single Lightmaps.

Set the Quality to High. The quality setting will determine the overall quality of the generated lightmap. While you are trying to get the lighting right, it is a good idea to keep this setting at Low quality because the lightmap generation will take considerably less time to produce and give a good overall indication of how the high quality lightmaps will look. When you are satisfied with how the lightmaps look, don’t forget to change this setting back to High and rebake the lightmaps.

Set the Bounces to 1. Setting the Bounces property higher than 0 will enable indirect lighting to be computed on objects. Setting the Bounces property to 0 will cause only direct lighting contributions to be baked into the lightmap.

Set the Sky Light Intensity to 0. We don’t want to have any skylight contributions added to our lightmap. Setting this value to 0 effectively disables the Sky Light.

Set the Bounce Boost and the Bounce Intensity values to 2.0. This will increase the contribution of indirect light on objects.

Set the Final Gather Rays to 1000. This value controls the number of Final Gather Rays that are generated at each Final Gather Point (see Contrast Threshold below). Increasing this value will improve the quality of the final lightmap at the expense of computational cost. Gernally, 1000 is a good value to use but if you find the quality of the final lightmap is insufficient, then you can increase this value but keep in mind this will have an adverse effect on the time it takes to generate the lightmap.

Set the Contrast Threshold to 0.05. The Contrast Threshold value tells Beast how often to generate Final Gather Points and thus effecting the total number of Final Gather Rays that need to be generated to lightmap the scene. Setting this value lower will cause more Final Gather Points to be generated (because the contrast variance required to generate a Final Gather Point will be less). Setting this value higher will cause less Final Gather Points to be generated because more contrast variance is required to generate a Final Gather Point. Higher values of Contrast Threshold will generate smother results in the final lightmap at the expense of detail.

Set the Interpolation value to 0.5. The Interpolation value controls the interpolation method used to interpolate the colors between the Final Gather Points. A value of 0 means a simple linear interpolation between points will be used to determine the intermediate colors. A value of 1 will give smoother results but can also reduce the detail in the final result.

Set the Interpolation Points to 15. This property controls the number of Final Gather Points to interpolate to produce the color at the current pixel in the lightmap. Higher values can create smoother (more blurred) results at the cost of detail in the lightmap.

Set Ambient Occlusion to 0. Ambient occlusion is a rendering technique that approximates the brightness of a pixel based on nearby objects in the scene. It simulates the occlusion of environment lighting due to nearby geometry. Please refer to Chapter 17 of the GPU Gems text for a complete explanation of Ambient Occlusion (available online here: http://http.developer.nvidia.com/GPUGems/gpugems_ch17.html



Ambient Occlusion

This image shows an application of Ambient Occlusion. On the left image, the model is shaded with simple diffuse shading. The model on the right is shaded with both diffuse shading and ambient occlusion. Notice the darker areas on the inner thigh of the model and on the ground and around it’s feet.

Set the LOD Surface Distance to 1. This property effects the LOD Group component that is used to replace high-poly models with low-poly models as the camera moves further away from the GameObject. LOD Groups are only available in the Pro version of Unity, this option may not be available to users of the Free version.

Make sure the Lock Atlas option is not checked. The Texture Atlas determines the tiling and offset of objects in the lightmap. Since many objects share the same lightmap, Unity needs to know how much area of an object’s surface is occupying the lightmap texture. The Texture Atlas is automatically generated every time you bake the lightmaps. Checking the Lock Atlas option will prevent the Texture Atlas from being modified and the current tiling and offset settings will be retained for each renderer object (GameObjects with a Mesh Renderer component attached to them). You probably want Unity to figure out the Texture Atlas for you so you can leave the Lock Atlas option unchecked.

Set the Resolution property to 50. This value determines the number of texels per world unit that will be used to generate the lightmaps. Higher values will generate more detailed lightmaps at the expense of texture memory. Lower values will generate less detailed lightmaps.

Make Objects Static

Before we can bake the lightmaps, we need to make some geometry static. Only objects that are marked Lightmap Static will be considered during the lightmapping process.

In the Lightmapping view, select the Object button at the top of the window.

Select the Renderers button under Scene Filters to show only the GameObjects in the Hierarchy view that have a Mesh Renderer component attached to them.



Unity – Lightmap Objects

Select the Back, Bottom, Left, Right, Top, Cube01, and Cube02 GameObjects from the Hierarchy view.



Unity – Lightmapping (9)

With all of the static renderers selected in the Hierarchy view, make sure the Static option is checked in the Inspector as shown in the screenshot above.

You should also confirm that the Lightmap Static option is checked for your selected object in the Lightmapping view, but this should be the case if the object is marked Static in the Inspector.

Ligtmapping Lights

With the Lightmapping view open to the Object tab, select the Point light GameObject in the Hierarchy view.



Unity – Lightmap Objects

Set the Lightmapping mode to Baked Only. This will ensure the light is considered during the light baking process but the light is ignored at run-time.

Set the Baked Shadows property to On. It doesn’t matter if you choose the On (Realtime: Hard Shadows) option or the On (Raltime: Soft Shadows) option because real-time lighting contributions are ignored on lights that are set to Baked Only.

Leave all other settings default and click the Bake Scene button on the bottom of the Lightmapping window.

The resulting view should look something like this:



Unity – Lightmapping (10)

This looks better than it did with just a simple point light, but there are still a few issues we can improve. For example, the shadow edges are very hard. There is no softening of the shadow edges as the shadow surface gets further away from the the object that is casting the shadow.

With the Point light selected in the Hierarchy view, open the Lightmapping view and click the Object tab again.



Unity – Lightmap Objects (11)

Set the Shadow Samples property to 20. This value determines the number of shadow rays that are cast to determine if the pixel being rendered is actually in shadow or not. In reality, light is scattered off of an object’s surface in an infinite number of directions. Some of the light scattered off of an object’s surface will go on to hit another object that does not emit light, but some may also hit something else that emits light. Obviously, we can’t simulate an infinite number of scatter rays but we can simulate a fixed number of random ray directions to determine if an object is in light or in shadow. With only 1 shadow ray being cast, it is likely that a randomly generated ray will be cast in the wrong direction and produce a wrong shadow. This is why we got blotchy shadows before. To resolve this, we just need to increase the Shadow Samples parameter to allow more shadow rays to be cast from each pixel in the lightmap which will increase the likelihood that the shadows will be computed correctly.

Set the Shadow Radius to 0.5. The Shadow Radius parameter is used to adjust the radius of the currently selected Point light. In reality, no light can possibly have a radius of 0. In virtual reality, Point lights always have a radius of 0 but this does not produce realistic shadows. Lights that have a radius larger than 0 are actually called Area Lights because they have a surface area greater than 0. Area Lights are required to produce realistic shadows with a soft penumbra (the edge of the shadow that is neither completely in shadow nor completely in the light). Point lights with a radius of 0 will only produce hard shadows in the lightmap even if you select Soft Shadows in the Inspector view.

Now bake the lightmaps again by pressing the Bake Scene button.



Unity – Lightmapping (12)

Now you see that the shadows on the walls and floors are smoother and they also get smoother when the surface in shadow is further away from the shadow caster.

Emissive Materials (Pro Only)

What if we want to make something appear to be glowing, like radioactive slime for example. For this purpose we could use a self-illuminating material. Also known as an emissive material.

First, let’s create a self-illuminated material.

Create a new material in the project view and call it “Green_Emissive_Material“.



Unity – Emissive Material

Select the new material in the project view and change the Shader parameter to “Self-Illumin/Diffuse“.

Change the Main Color to green.

Set the Emission (Lightmapper) value to 2. This value determines the intensity of the light being emitted from the object. A value of 0 will not contribute anything to the lightmapping computations.

Add a sphere to your scene with the following properties:

• Sphere
  • Static: True
  • Position
    • X: 0
    • Y: -2.5
    • Z: -2.5


Unity – Lightmap Objects (13)

Drag-and-Drop the Green_Emissive_Material onto the Sphere in the Scene view.



Unity – Lightmap Objects (14)

Don’t forget to make sure the sphere is marked as Static!

Save your scene.

Open the Lightmapping view and click the Bake Scene button. When the bake is complete, you should see something similar to what is shown below.



Unity – Lightmapping with Self-Illuminating materials

Observe the green glow that is emitted from the sphere and illuminating the objects around it.

This works fine for static objects in our scene, but what if we wanted to achieve this glowing effect at run-time on dynamic objects?

Emissive materials (like the one used on the green sphere) cannot be used to emit light onto other objects in the scene dynamically at run-time. However, we can “fake” emissive materials with point lights.

Emissive Materials on Dynamic Objects

A similar effect can be achieved with dynamic objects by attaching a Point light to the emissive GameObject.

Un-check the Static flag on the green Sphere we just created. This will prevent the Sphere from being considered for lightmapping.

Attach a Rigidbody component to the sphere so that it will be physics controlled.

If the Sphere doesn’t have a Collider component, attach a Sphere Collider component and set it’s Material property to “Bouncy” (from the Physics Materials standard package).

Add a Point light GameObject as a child of the Sphere GameObject and set it’s properties to the following values:

• Point light
  • Position
    • X: 0
    • Y: 0
    • Z: 0
  • Type: Point
  • Color: Green
  • Render Mode: Important
  • Lightmapping: Realtime Only

Setting the light’s Render Mode property to Important will make sure it’s rendered with per-pixel lighting and setting the Lightmapping property to Realtime Only will ensure that it is not considered when generating the lightmap (which it won’t if we unchecked the Static flag).

You should see something similar to what is shown below.

Conclusion

In this article, you have been introduced to cameras, lights, materials and lightmapping in Unity. We have seen how we can use Self-Illuminating materials in our scene to create apparently glowing objects in the lightmap and I’ve also shown a technique that can be used to “fake” this effect in real-time (at the expense of GPU processing power).

Resources

Most of the content for this article has been derived from various sources in the Component Reference documentation on the Unity website:

http://docs.unity3d.com/Documentation/Components/index.html

]]> http://3dgep.com/?feed=rss2&p=3856 7 http://3dgep.com/?p=3474 http://3dgep.com/?p=3474#comments Wed, 05 Sep 2012 21:11:07 +0000 Jeremiah van Oosten http://3dgep.com/?p=3474 Continue reading →]]>

Unity – Scripting

In this article, I will introduce you to scripting in Unity 3.5. Unity is a powerful game editor that only limits you to what you can imagine. Scripting is where the magic happens which will bring your games to life. I assume the reader is familiar the Unity interface, if not you can refer to my previous article titled Introduction to Unity (http://3dgep.com/?p=3246).

This article is intended for designers and artists who have no previous programming experience. For this reason, I will go into details about JavaScript syntax that the experienced programmer may find boring.

Table of Contents

1. Introduction
   1. JavaScript
   2. C#
   3. Boo
2. JavaScript Basics
   1. Creating Scripts
   2. The Game Loop
      1. Update Loop
      2. Fixed Update Loop
      3. The OnRenderObject Method
   3. Variables
   4. Types
      1. Integer
      2. Float
      3. Double
      4. Strings
      5. Boolean
      6. Arrays
         1. Built-In Array
         2. JavaScript Array
         3. Accessing Array Elements
      7. Class
   5. Rotation Script
   6. Time
   7. Conditional Logic
      1. Boolean Logic
         1. If Statement
         2. If-Then-Else
         3. Switch Statement
         4. While Loops
         5. Do-While Loops
         6. For Loops
         7. For-In Loop
3. Wall Breaker
   1. Create A New Scene
   2. Create A Plane
   3. Create a Brick
   4. Create a Canon Ball Prefab
   5. Adding the Logic
      1. The Start Function
      2. The Update Function
   6. Adding the Logic to the Scene
   7. Tweaking and Polish
   8. Playing your Game
4. Conclusion
5. References

 

Introduction

The Unity game engine supports the ability to program game behaviours using a variaty of scripting languages. The primary scripting languages supported by Unity are JavaScript, C#, and a dialect of Python called Boo.

Unity has full support for the .NET 2.0 framework when deploying your game as a desktop application and a subset of the .NET 2.0 framework when deploying as a web player or mobile device.

JavaScript



JavaScript Icon

JavaScript is an easy to use, easy to learn scripting language and the primary scripting language used in this article.

JavaScript has a similar syntax to the Java programming language which is also similar to C++ style programming. It’s my recommended language for people who don’t have much programming experience.

C#



Visual C# Icon

C# can be considered a “Programming Language” more than a scripting language. It can be used to create stand-alone applications using Microsoft’s .NET Framework.

Boo



Boo Icon

Boo is a scripting language that is inspired by the popular Python scripting language. Although Boo is not widely used in Unity, it is one of the standard scripting languages supported by the Mono development API so naturally, it is supported by Unity as well.

 

In this article, I will focus on creating scripts using the JavaScript scripting language.

JavaScript Basics

Instead of simply writing JavaScript reference documentation, I will try to teach JavaScript by showing a series of examples that slowly build-up your knowledge of the JavaScript scripting language and how it is used in Unity.

If you haven’t done so already, launch your Unity editor and create a new empty project. If you are unsure how to get started with Unity, you can refer to my previous article titled Introduction to Unity. If you just want to skip to the part about creating your first project, click here.

Creating Scripts

If you created a new empty project, you should have a screen that looks something like the image below.



Unity – Empty Project

In the Project View create a new Folder called “Scripts”. Inside the Scripts folder, create a new folder called “JavaScript”. Your project view should look something like the image shown below.



Unity – Project View

Right-click on the “JavaScript” folder and select Create -> Javascript from the pop-up menu that appears.

Give the new script asset an interesting name like “HelloWorld” (Unity will add the “.js” extension for you automatically so you don’t have to add it in the file name here).

If you select the new JavaScript asset in the Project view, you will see the contents of the JavaScript file in the Inspector view.



Unity – JavaScript Import Settings

Press the “Open…” button on the Inspector view.

Unity comes with a built-in source code editor called MonoDevelop-Unity which is a customized version of the MonoDevelop source code editor. By default, the MonoDevelop-Unity editor will open and your “HelloWorld.js” script should open and you should see something similar to what is shown below.



MonoDevelop – HelloWorld

When you create a new JavaScript source file, Unity will provide some default template for you. Let’s take a look at what Unity provides by default.

#pragma strict

function Start () {

}

function Update () {

}

So this is not very interesting, but let’s take a look at what this script is doing.

On the first line you see “#pragma strict”. This is a special command (called a compiler directive) that is used to tell the JavaScript compiler to not allow dynamic typing in this script file. Basically this is an optimization that will allow your script to run faster. You should always use this command at the top of every JavaScript file.

The observant programmer will realize that this compiler directive is only available in JavaScript source files and not in C# or Boo scripts. This is because JavaScript has support for dynamic typing but this directive disables dynamic typing in this script file.

C# and Boo are statically typed languages and therefor this directive is always implied.

On line 3 a function called Start is defined.

A function is a group of commands that can be executed many times without having to rewrite any code. That function can be executed by accessing the name of the function.

For example, we could create a function called Jump in our script and anytime the user presses the “Jump” key on the keyboard or game controller, we would invoke the function that executes the group of commands that makes our character jump. Without functions, we would have to rewrite all of the commands needed to execute that action everywhere it is used. Imagine how difficult it becomes to keep this action the same everywhere it is used!

In this case, the Start function in this script is invoked when the game is started.

On line 7 another function called Update is declared. This function is called by the Unity engine on the script every time the game loop is ticked.

Before we go further, let’s take a look at what the game loop is.

The Game Loop

The game loop is a sequence of events that occur during the lifetime of your game. It usually starts off with some kind of initialization sequence, followed by an infinite (until the game is quit) loop which when terminated, is followed by some termination sequence. Which might look something like this:



Unity Game Flow Diagram

When the player starts the game, the script components that are attached to the GameObject’s in the scene are loaded. When the script is loaded, it’s Awake() method is invoked (if it has been defined on the script).

If there are any statements defined in the global scope, then these statements are executed just before the Start() function is called for each GameObject.

The Start() function is called after all of the GameObjects in the scene have been loaded but before the first call to Update() or FixedUpdate() method. The Start() function is the best place to query for references to other GameObjects in the scene because when Start() is called, you know that all other GameObjects have been loaded.

After the Start() function returns, the game enters the main update loop. The update loop is executed indefinitely until the game is quit. There are actually 2 update loops in Unity. The main update loop and the fixed-time update loop.

Update Loop

The main update loop is executed as fast as possible regardless of processing power or complexity of the game logic. This means that this Update loop may execute more times per second on computers with faster CPU’s and less times per second on computers with slower CPU’s than your own.

This Update Loop may look something like the diagram shown below.



Unity Update Loop

From the diagram, we can see that unless the user has quit the game, the Update() function will be called on all enabled script components in the scene that define the function.

After all script components have been updated, the LateUpdate() function is called. The LateUpdate() function can be used when you want to make sure that all GameObjects in the scene have been updated first before you do something else.

Fixed Update Loop

The FixedUpdate() function is executed at a fixed time step. You can configure the time between calls to FixedUpdate() in the project settings but generally you can leave the setting at it’s default value.

It is recommended to use the FixedUpdate() method rather than the Update() method to control things that effect physics objects (like the Rigidbody component) because this function is guaranteed to execute at a fixed time-step. When you can guarantee the time-step between frames, your simulations will be more stable and more predictable (and more reproducible) than if the time-step between frames is variable.

The flow diagram for the fixed update loop might look something like the image shown below.



Unity Fixed Update Loop

As you can see from the diagram, as long as the user hasn’t quit the game and the fixed-timestep time has elapsed, execute the FixedUpdate() function.

We can test the execution order of these functions with the following script:

#pragma strict

Debug.Log("ExecutionOrder::global");

function Awake() {
	Debug.Log("ExecutionOrder::Awake");	
}

function Start () {
	Debug.Log("ExecutionOrder::Start");
}

function Update () {
	Debug.Log("ExecutionOrder::Update");
}

function FixedUpdate() {
	Debug.Log("ExecutionOrder::FixedUpdate");
}

function LateUpdate() {
	Debug.Log("ExecutionOrder::LateUpdate");
}

function OnRenderObject() {
	Debug.Log("ExecutionOrder::OnRenderObject");
}

Copy this code to a new Javascript asset (called “ExecutionOrder” for example) then drag-and-drop this script asset onto one GameObject in the scene.

Open the Console window (Ctrl-Shift-C) and play the game for about 1-2 seconds. You should see the following statements in the Console window.

ExecutionOrder::Awake
ExecutionOrder::global
ExecutionOrder::Start
ExecutionOrder::FixedUpdate
ExecutionOrder::Update
ExecutionOrder::LateUpdate
ExecutionOrder::FixedUpdate
ExecutionOrder::Update
ExecutionOrder::LateUpdate
ExecutionOrder::OnRenderObject
...

From this output you can confirm that the Awake() function is called first, then the statements in the global section are executed followed by the Start() function. Thereafter the Update and FixedUpdate loops are entered. Whether the Update() method or the FixedUpdate() method are invoked first or how many times Update() is called compared to FixedUpdate() is not strictly guaranteed.

The OnRenderObject Method

The OnRenderObject() function is invoked after the camera has rendered the scene but before the rendered scene is displayed on the screen. So this function could be used to render a mesh or other geometry after everything else in the scene has been rendered. For example, you could use this function to draw a silhouette or highlight around any geometry even if it’s occluded by other geometry in the scene (x-ray vision?)

If you look at the output from the previous example, you may notice that the OnRenderObject() function is not necessarily invoked after every Update() function. This implies that the game is Updated as fast as possible, but the scene is only Rendered when the screen needs to be redrawn (based on the refresh rate of your screen but usually 60 frames/second).

Variables

Of course, it would be difficult to implement any interesting behaviours if we only had functions. We need something else to store the current State of our GameOjects. For this, we use variables.

A variable is something that can hold data.

A variable declaration has the following form in JavaScript

var variableName [: type] [= value];

The var keyword is required when declaring variables (similar to the function keyword when you declare a function). The var keyword is always follwed by the variable name.

A variable name must always begin with a letter (‘a’-'Z’) or an underscore (‘_’) followed by any combinations of letters (‘a’-'Z’), numbers (’0′-’9′), or underscore (‘_’) characters. Variable names may not contain spaces.

For example, the following variable declarations are valid:

var a;         // OK: Single letter variables are okay,
               //  but not recommended.
var b;         // OK: variable names should be more meaningful.
var a0;        // OK: Starts with a letter follwed by a number.

var _rotation; // OK: Starts with an underscore
var Rotation;  // OK: Starts with a capital letter
var rotation;  // OK: Variable names are case-sensitive so 
               //   Rotation is different from rotation.

The following declarations are not valid:

var 123;           // ERROR: Starts with a number.
var 123a;          // ERROR: Starts with a number.
var @foo;          // ERROR: @ is not a valid character.
var rotation rate; // ERROR: Variable names cannot contain spaces.
var var;           // ERROR: Variable names cannot be reserved keywords.

Optionally, you can assign a value to the variable in the variable declaration.

var foo = 5;                  // foo is an integer.
var bar = 5.0f;               // bar is a floating-point value.
var token = 'a';              // token is a character.
var message = "Hello World!"; // message is a string.
var isFun = false;            // isFun is a boolean.

JavaScript uses type inference which means that the JavaScript compiler can infer the type of the variable based on its value. In this case, you don’t have to explicitly declare the type. In the example above, the value foo becomes an integer (int), bar becomes a floating-point value (float), token becomes a character (char),message becomes a string of characters (string), and isFun becomes a boolean.

Types

Optionally, you can also explicitly specify the variable type when you declare a variable.

var foo : int;         // foo is explicitly an integer.
var bar : float;       // bar is explicitly a floating-point value.
var message : String;  // message is explicitly a character string.
var isFun : boolean;   // isFun is explicitly a boolean.

Let’s examine the different primitive types that are supported in JavaScript.

Integer

An integer is declared using the int type in JavaScript. An integer is implemented as a System.Int32 in the .NET Framework.

var foo : int;

An integer () can be used to store any positive or negative whole number. It cannot be used to store numbers with a decimal points.

Integers can be in the range -2,147,483,648 to 2,147,483,647.

Float

A floating-point value is declared with the float type in JavaScript. The float type is implemented as a System.Single in the .NET Framework.

var bar : float;

A floating-point value is a Real () number. Real numbers can be used to represent values that occur in-between the whole numbers but it can also be used to represent whole numbers.

For example, the following values are all valid single-precision floating-point numbers:

var foo = 3.14159265359f; //  PI
var bar = 0.5f;           //  1/2
var fooBar = -0.5f;       // -1/2
var fooFoo = 5.0f;        //  5

The “f” post-fix on the value tells the compiler that the number represents a single-precision 32-bit floating-point value. This post-fix is optional in JavaScript.

A single-precision 32-bit floating-point value can be in the range -3.402823e³⁸ to 3.402823e³⁸.

Double

If the single-precision 32-bit floating-point value is not accurate enough for you (99.99% of the time, a float has enough precision), then you can use a double-precision 64-bit floating-point value (double). A double is implemented as a System.Double in the .NET Framework.

var bar : double;

For example, the following variable declarations are valid double-precision floating-point values:

var foo : double = 3.1415926535897932384626433832795; //  PI
var bar : double = 0.5;           //  1/2
var fooBar : double = -0.5;       // -1/2
var fooFoo : double = 5.0;        //  5

If you really want a double, you should explicitly declare the type for the variable otherwise it will be declared as a single-precision 32-bit floating point value (float).

A double-precision 64-bit floating-point value can be in the range -1.79769313486232e³⁰⁸ to 1.79769313486232e³⁰⁸

It is recommended that you only use single-precision 32-bit floating-point values (float) in your game. In most cases these values provide enough precision for your needs.

Double-precision 64-bit floating-point values will run slower than single-precision 32-bit floating point values when deploying to 32-bit builds and they also consume twice as much space in memory.

It is recommended to only use doubles when absolutely necessary.

Strings

A string is used to store a character string. A character string is any sequence of characters enclosed in double-quotes or single-quote characters.

var bar : String;

A String is implemented as a System.String in the .NET Framework.

For example, the following string declarations are all valid.

var playerName = "Jeremiah";
var message = "Hello, my name is \"Jeremiah\"";
var quote = '"To be or not to be..."';

These three strings demonstrate some interesting syntax rules. The first string (“Jeremiah”) is a simple double-quoted string. This is probably the most common type you will use.

The second string on line 2 is a double-quoted string that contains the double-quote character inside the string. In this case, we must escape the double-quote character inside the string with the back-slash character (‘\‘).

The third string on line 3 is a single-quoted string that contains the double-quote character inside the string. In this case we do not need to use the escape character (‘\‘) to insert the double-quote character.

The table below shows the different escape sequences that can be used in strings.

Escape Sequence	Effect
\b	Backspace (rarly used)
\f	Form feed (rarly used)
\n	Newline. A newline character will be inserted and the text will wrap to the next line.
\r	Carriage return. Traditionally used to move the position of the cursor to the beginning of the current line. This escape sequence is generally not used.
\’	Single quote. Used in single-quoted strings to insert the single-quote character. It is not necessary to use this escape sequence in double-quoted strings.
\"	Double quote. Used in double-quoted strings to insert the double-quote character. It is not necessary to use this escape sequence in single-quoted strings.
\\	Backslash character. Used to insert the backslash character.

Strings can be concatenated together using the ‘+‘ operator.

var string1 = "Hello";
var string2 = "World!";
var concatString = string1 + " " + string2;

The concatString variable will contain the string “Hello World!”.

Boolean

A boolean is logic data type that can have 1 of 2 possible values: true or false.

var bar : boolean;

The boolean type is implemented as the System.Boolean type in the .NET Framework.

Some valid values for the boolean data types are:

var isTrue = true;    // Value is true.
var isFalse = false;  // Value is false. (This is a bad name for this variable!)

The variable name “isFalse” is actually a really bad name for a boolean value. Can you explain why?

Arrays

What do you do if you need to declare a lot of things of the same type but you don’t want to declare a separate variable for each one? You use arrays.

There are multiple ways to declare an array in JavaScript.

Built-In Array

The built-in array is the preferred way to declare an array. It’s the fastest way to access elements sequentially in script.

A built-in array is declared in the following way:

var floatArray : float[]; // Un-sized static array.

The statement above will declare an un-sized array of floats. Using this method of declaring an array requires the user to populate the array in the Inspector. This array cannot be re-sized in script.

Literal Array


You can also initialize an array with literal values during declaration.

var floatArray = [ 1.0f, 2.0f, 3.0f ]; // Static array with 3 values.

In this case, a 3-element array is created with its first element initialized to 1.0f, the second element initialized to 2.0f, and the third to 3.0f. Using this method, the array can only be resized in the Inspector. This array cannot be re-sized in script but you should also not assume the array contains any values at all because the user can set the number of elements in this array to 0 in the Inspector if they want.

JavaScript Array

Unity provides the JavaScript array type to be consistent with standard JavaScript syntax.

var javascriptArray = new Array(); // JavaScript Array

A JavaScript array is not actually an array at all but rather an Object that behaves like an array.

JavaScript arrays are not exposed in the Inspector but they can be dynamically sized in script.

JavaScript arrays can be converted to built-in arrays by using the ToBuiltin function on the JavaScript array object.

var builtinArray : String[] = javascriptArray.ToBuiltin(String);

Accessing Array Elements

Regardless of type of array the individual array elements are accessed in the same way. To refer to a particular element of the array you use the index of the element in the array enclosed in square brackets ([ ]). The first array element is at index 0 and the second array element is at index 1 etc…

var stringArray = new String[5];

stringArray[0] = "Hello, ";
stringArray[1] = "my ";
stringArray[2] = "name ";
stringArray[3] = "is ";
stringArray[4] = "Jeremiah ";

We can query the number of elements in an array using the Length property of the array.

Debug.Log( "The stringArray contains " + stringArray.Length + " elements." );

The previous line will print “The stringArray contains 5 elements.”.

Class

A Class is a complex type that can contain both variables and functions. Classes are declared using the class keyword.

A class is not the same as a variable. You cannot assign values to the member variables of a class unless you first create an instance of that class. Let’s take a look at an example.

Suppose we declare a class called “Person“:

class Person
{
	var firstName : String;
	var lastName : String;
	var age : int;
	var isMale : boolean;
}

The Person class contains four member variables (firstName, lastName, age, and isMale).

We can create an instance of the class by declaring a variable of the class type.

var person : Person;  // Declare a variable of type Person.
                      // Identifier names are case-sensitive so
                      // person and Person are two different things!
var jeremiah = new Person(); // Create a new instance of a Person.

jeremiah.firstName = "Jeremiah"; // OK: jeremiah is an instance of Person.
person.firstName = "First";      // OK: person is a variable of type Person.
Person.firstName = "First";      // ERROR: Person is NOT an instance!

We can then access the different properties of the instance.

jeremiah.firstName = "Jeremiah";
jeremiah.lastName = "van Oosten";
jeremiah.age = 35;
jeremiah.isMale = true;

We can delete a class by setting its reference to null.

jeremiah = null;

If you try to access the properties of a deleted reference, you will get a NullReferenceException at run-time.

We can extend our class to contain functions. A special function called a constructor can be defined using the name of the class:

class Person
{
    var firstName : String;
    var lastName : String;
    var age : int;
    var isMale : boolean;

    // Default constructor.
    function Person() {
    }        
}

We can also initialize the properties of our class if we supply a constructor that accepts arguments.

class Person
{
    var firstName : String;
    var lastName : String;
    var age : int;
    var isMale : boolean;

    // Parameterized constructor.
    function Person( firstName : String, lastName : String, age : int, isMale : boolean )
    {
        this.firstName = firstName;
        this.lastName = lastName;
        this.age = age;
        this.isMale = isMale;
    }
}

// Create an instance of a person using the parameterized constructor.
var jeremiah = new Person( "Jeremiah", "van Oosten", 35, true );

Within the scope of the class, we can use the this keyword to refer to the instance of the class. In the previous example, we use the this keyword to differentiate between the class member variables and the constructor arguments.

We can also define member functions in the class.

class Person
{
	var firstName : String = "John";
	var lastName : String = "Doe";
	var age : int = 19;
	var isMale : boolean = true;
	
	function Person()
	{}
	
	function Person( firstName : String, lastName : String, age : int, isMale : boolean )
	{
		this.firstName = firstName;
		this.lastName = lastName;
		this.age = age;
		this.isMale = isMale;
	}

	function ToString() : String
	{
		var asText : String;
		
		asText =  "Name: " + firstName + " " + lastName + "\n";
		asText += "Age: " + age + "\n";
		asText += "Gender: " + (isMale ? "Male" : "Female");
		
		return asText;
	}
}

In the previous example, we declare a function called ToString() within the scope of the class. This function also demonstrates a feature of functions that hasn’t been introduced yet: return values (return values are not unique to class functions).

A function can return a value to the caller using the return keyword. In this case, the ToString() function returns a value of type String.

Rotation Script

Now that we have a good understanding of functions, variables, types and classes, let’s put it to good use. We will create a script that will rotate an object around the global Y-axis. We will do this in 2 different ways which we will see changes the way the object behaves.

First, let’s create a new script. In your Unity project, create a new JavaScript asset called “RotateObject“.

Open the new script in MonoDevelop and copy-paste the following code into the script.

#pragma strict

var variableRotationRate = 0.0f;
var fixedRotationRate = 0.0f;

function Update () {
	transform.Rotate( Vector3.up * variableRotationRate );
}

function FixedUpdate() {
	transform.Rotate( Vector3.up * fixedRotationRate );
}

Now create a scene with 2 cubes. Place the cubes close together (without overlapping) so you can see both of them in the scene view. Name one cube “Cube01” and the other “Cube02“.

Make sure you aim the main camera at the cubes (hint: use the scene view to frame the cubes in the view then use the Align with View command (Ctrl+Shift+F) to align the main camera with the scene view).

Add a directional light as a child of the main camera GameObject to light the cubes. Zero the X, Y, Z position and rotation values of the directional light so it is always pointing in the direction of the camera.

Attach the RotateObject script component to each cube in the scene.

You should see something similar to what is shown below.



Unity – Rotate Object Scene

Select Cube01 and set it’s Variable Rotation Rate value in the inspector to 1.

Select Cube02 and set it’s Fixed Rotation Rate value in the inspector to 1.

Run the game. You should see something similar to what is shown below.

You will notice that the two cubes are not synchronized despite the fact that we set both rotation rates to the same value of 1. This is because one cube is performing its rotation in the Update() function and the other is performing its rotation in the FixedUpdate() function. These two functions are being updated at different frequencies.

The frequency that the Update() function is invoked is also CPU bound. It will run faster on computers with faster CPUs and slower on computers with slower CPUs. How can we ensure that the cubes rotate at the same rate regardless of the CPU speed?

To solve this, we must take time into consideration.

Time

Unity provides a class object called Time that we can use to solve our frame-rate issues. The Time class provides a static member variable called deltaTime that we can use to adjust our rotation rate.

You can declare a variable as static by using the static keyword. You do not need an instance of a class to access static variables.

Let’s adjust the script to take time into consideration.

#pragma strict

var variableRotationRate = 0.0f;
var fixedRotationRate = 0.0f;

function Update () {
	transform.Rotate( Vector3.up * Time.deltaTime * ( variableRotationRate * 360.0f ) );
}

function FixedUpdate() {
	transform.Rotate( Vector3.up * Time.deltaTime * ( fixedRotationRate * 360.0f ) );
}

If you copy paste this code to the RotateObject.js script asset and run the game again, you may notice that the cubes are rotating really fast. I multiplied the rotation rate by 360 to make the cubes rotate at RotationRate rotations per second. Previously, we set the rotation rate to 1 for both variable and fixed rotation rates which will cause the cubes to rotate one full rotation every second.

Select Cube01 and set its Variable Rotation Rate to 0.25 and its Fixed Rotation Rate to 0.

Select Cube02 and set its Variable Rotation Rate to 0 and its Fixed Rotation Rate to 0.25.

Now the cubes should rotate at a rate of 90 degrees per second. It should take exactly 4 seconds to make a full rotation.

Now run the game again and you will notice that the two cubes rotate at the same speed!

There will be many situations where using the Time.deltaTime value will be useful.

Conditional Logic

We now have a better understand of types and variables in JavaScript but there is one more extremely important concept we must understand before we can make interesting gameplay. Without conditional logic, we couldn’t make any choices in our gameplay. We couldn’t tell our player to jump, or shoot, or taunt the other players.

In order to use conditional logic correctly, we must first understand some basics about logic. We will now put the boolean type introduced earlier to good use.

Boolean Logic

The most basic concept of boolean logic is the concept of “true” and “false“. We have a boolean data type that can be used to store these values.

We can compare values to test if a certain condition is true or false.

The table below shows the different comparison operators that are available.

Operator	Operation	Desctiption
==	Equality	The equality operator is used to test if two values are the same.
!=	Inequality	The inequality operator is used to test if two values are not the same.
>	Greater than	The greater than operator is used to test if the value on the left of the operator is greater than the value on the right.
<	Less than	The less than opertator is used to test if the value on the left of the operator is less than the value on the right.
>=	Greater than or equal to	The greater than or equal operator is used to test if the value on the left of the operator is greater than or the same as the value on the right.
<=	Less than or equal to	The less than or equal operator is used to test if the value on the left of the operator is less than or the same as the value on the right.

We can use these comparison operators together with the following logical operators to form complex logical conditions.

Operator	Operation	Description
&&	And operator.	Returns true if both left and right operands are true.
||	Or operator.	Returns true if either the left or the right operands are true.
!	Not operator.	Reverses the value of the boolean expression (makes true false and false true).

The first type of conditional we will look at is the if statement.

If Statement

The If statement has the following syntax.

if ( condition )
{
    // Statements to execute if condition is true.
}

The following statements will all evaluate to true:

var a = 3;
var b = 5;
var c = 10;

var strHello = "Hello";
var strWorld = "World!";

var strHelloAgain = strHello;

if ( a < b ) // TRUE: 3 is LESS THAN 5
{}

if ( b < c ) // TRUE: 5 is LESS THAN 10
{}

if ( a < b && b < c ) // TRUE: 3 is LESS THAN 5 AND 5 is LESS THAN 10
{}

if ( c > a || a > c ) // TRUE: 10 is GREATER THAN 3 OR 3 is GREATER THAN 10
{}

if ( strHello != strWorld ) // TRUE: "Hello" is NOT EQUAL "World!"
{}

if ( strHello == strHelloAgain ) // TRUE: "Hello" is EQUAL to "Hello"
{}

The following statements all evaluate to false:

if ( a > b ) // FALSE: 3 is NOT GREATER THAN 5
{}

if ( b > c ) // FALSE: 5 is NOT GREATER THAN 10
{}

if ( a < b && b > c ) // FALSE: 3 is LESS THAN 5 but 5 is NOT GREATER THAN 10
{}

if ( a > b || b > c ) // FALSE: 3 is NOT GREATER THAN 5 and 5 is NOT GREATER THAN 10

if ( strHello == strWorld ) // FALSE: "Hello" is NOT EQUAL to "World!"
{}

Optionally, we can execute some other statements only if the if condition fails. This is called an if-then-else statement.

If-Then-Else

The if-then-else statement has the following syntax.

if ( condition )
{
    // Execute these statements if the condition is true.
}
else
{
    // Execute these statements if the condition is false.
}

We can also nest if-then-else statements.

if ( condition1 )
{
    // Execute these statements if condition1 is true.
}
else if ( condition2 )
{
    // Execute these statements if condition2 is true.
}
else
{
    // Execute these statements if neither condition1 or condition2 are true.
}

If you you find you have to write a lot of nested if-then-else statements, you may want to consider using a switch statement.

Switch Statement

The switch statement has the following syntax.

switch ( <expression> )
{
case <test1>:
    // Statements to execute if expression evaluates to test1.
    break; // Break-out of switch statement.
case <test2>:
    // Statements to execute if expression evaluates to test2.
    break; // Break-out of switch statement.
case <test3>:
    // Statements to execute if expression evaluates to test3.
    break;
default:
    // Statements to execute if no test passes.
}

Switch statements are very common way of implementing state-machines. Let’s look at a real-world example.

Suppose we have a character controller that can have the following states:

• Idle: The character is not moving. Perform some “Idle” animation.
• Walk: The character is walking. Perform the “Walk” animation.
• Run: The character is running. Perform the “Run” animation.
• Jump: The character is jumping. Perform the “Jump” animation.
• Fire: The character is firing a weapon. Perform the “Fire” animation.

We could implement this state machine using the following switch statement.

#pragma strict

enum State
{
	Idle,
	Walk,
	Run,
	Jump,
	Fire
}

private var currentState : State = State.Idle;

function Update () 
{
	switch ( currentState )
	{
	case State.Idle:
		DoIdle();
		break;
	case State.Walk:
		DoWalk();
		break;
	case State.Run:
		DoRun();
		break;
	case State.Jump:
		DoJump();
		break;
	case State.Fire:
		DoFire();
		break;
	default:
		currentState = State.Idle;
	}
}

In this code example, we use an enumeration to define some valid states the character can have. We must also define a variable which will store the character’s current state. This variable is marked “private” which means that this variable will neither be available in the Inspector nor will it be accessible by other scripts attached to the GameObject.

If the character is in the Idle state, we execute the DoIdle() function.

If the character is in the Walk state, we execute the DoWalk() function.

If the character is in the Run state, we execute the DoRun() function.

If the character is in the Jump state, we execute the DoJump() function.

If the character is in the Fire state, we execute the DoFire() function.

If the character is in some invalid state, then we set the current state to a valid state and do nothing until the next time Update() is invoked on this script.

While Loops

There might be a situation where you need to execute a block of code as long as some condition is true. In this case, we can use a while loop.

The syntax for the while loop is:

while ( condition )
{
    // Do something as long as condition is true.
}

For example, the following example shows how we can spawn 15 enemies.

var numEnemies = 15;

var i = 0;
while ( i < numEnemies )
{
    SpawnEnemy();
    ++i;
}

Do-While Loops

In some cases, you may want to make that a block of code gets executed at least once before the while condition is tested. For this, we can use the do-while loop.

The do-while loop has the following syntax.

do
{
    // Do something before we test the while condition.
} while ( condition ); // Keep doing it as long as condition is true.

For Loops

The for loop is useful when you want to iterate arrays or other types of enumerable containers or you want to execute a statement block a certain number of times.

The syntax of the for loop is:

for ( <initializer>; <condition>; <iterator> )
{
    // Operate on element.
}

We can convert the enemy spawn example to use a for loop instead of a while loop.

var numEnemies = 15;

for ( var i = 0; i < numEnemies; ++i )
{
    SpawnEnemy();
}

For-In Loop

Iterating (looping over the elements of) arrays is so common in programming that there is a special construct in JavaScript that allows you to loop over the elements of a container. For this purpose, we can use the for-in loop.

The syntax of the for-in loop is:

for ( element in container )
{
    // Operate on element.
}

For example, we can iterate arrays using the following code:

var stringArray = new String[5];

stringArray[0] = "Hello, ";
stringArray[1] = "my ";
stringArray[2] = "name ";
stringArray[3] = "is ";
stringArray[4] = "Jeremiah ";

for ( val in stringArray )
{
	Debug.Log( val );
}

This will output the following code in the debug console:

Hello, 
my 
name
is 
Jeremiah

Only containers that implement the System.Collections.IEnumerable interface can be enumerated using the for-in loop. Both JavaScript arrays and built-in arrays implement the IEnumerable interface.

So I think that's enough blah-blah-blah. Let's put all this knowledge to good use and make a simple prototype of a wall breaking game.

Wall Breaker

In this tutorial you will put all of the knowledge you just learned to good use. We are going to make a simple demo called "Wall Breaker".

First, we going to create a wall of bricks (cubes). The width and height of our brick-wall should be tweakable.

Then we want to be able to shoot a ball at our wall and see how it collapses. We should be able to tweak the initial velocity of the ball.

Create A New Scene

Open your test project in Unity (or create a new project) and create a new scene.



Unity - Wall Breaker - New Scene

Save your scene. I suggest you call your scene file "WallBreaker" and you save it in a folder called "Scenes".

Create A Plane

Create a new Plane GameObject in your scene (select GameObject -> Create Other -> Plane from the main menu).



Unity - Wall Breaker (2)

Set the Position and Rotation of the Plane GameObject to 0 in all axes.

Scale the Plane to 10 units in the X axis and 10 units in the Z axis. Make sure the Scale in the Y axis is 1.



Unity - Wall Breaker (3)

Save your scene!

Create a Brick

Create a new Cube GameObject in your scene (select GameObject -> Create Other -> Cube from the main menu).

Scale the Cube so that it is more "brick shaped". Set the Scale in the Y and Z axes to 0.5.



Unity - Wall Breaker (4)

If the Cube was placed at the origin (position is at 0, 0, 0) then the Cube GameObject will be sitting inside the plane. Use the transform gizmo to move the cube just above the plane. We've scaled the Cube to 0.5 units in the Y axis so if we translate the Cube to 0.25 units in the Y axes then the Cube will be sitting directly on the Plane.



Unity - Wall Breaker (5)

We want our Cube to be Physics controlled so we must add a Rigidbody component to the cube. Select the Cube GameObject in the Hierarchy view and select Component -> Physics -> Rigidbody from the main menu.



Unity - Wall Breaker (6)

Save the scene!

Create a Canon Ball Prefab

We will also create a canon ball that will be used shoot at our brick wall.

Create a new Sphere GameObject (select GameObject -> Create Other -> Sphere). The position of the sphere is irrelevant because it will only be used to create a Prefab.

We also want the Sphere to be physics controlled so let's add a Rigidbody component to the Sphere GameObject. Select the Sphere GameObject in the Hierarchy view and select Component -> Physics -> Rigidbody from the main menu.



Unity - Wall Breaker (7)

Create a folder in your Project view called Prefabs.

Now drag-and-drop the Sphere GameObject from the Hierarchy view into the Prefabs folder in the Project view. We now have a GameObject template (Prefab) that we can instantiate at run-time.

Delete the original Sphere GameObject from the scene.

We should have something similar to what is shown below.



Unity - Wall Breaker (8)

Save your scene!

Adding the Logic

Create a new JavaScript asset in your Scripts folder called "WallBreaker". Open the new WallBreaker JavaScript file in MonoDevelop.

Initially, your script will contain the default JavaScript template.

#pragma strict

function Start () {

}

function Update () {

}

First, we need to define a few parameters that will be exposed in the Inspector view.

var brickPrefab : GameObject;
var ballPrefab : GameObject;

At the top of the source file, we declare two variables that will be used to store references to Prefabs that we will instantiate while the game is running. Initially, these variables are empty (null) and we cannot use empty variables. These variables will be set in the Inspector view.

Next, we also want to specify how many bricks will be used to build our wall.

var numBricksX : int = 5;
var numBricksY : int = 5;

For this, we will use numBricksX to specify how many bricks to place in the X axis (to the right of our original brick) and numBricksY is used to specify how many bricks to place in the Y axis (above the original brick). The default value of 5 for each of these variables will produce a wall that is 5x5 = 25 bricks. 25 bricks is not a very big wall but we will tweak these values in the Inspector later.

We also want to specify how much force will be applied to our canon ball when we shoot it at the brick wall.

// How much force to put on the ball.
var forceMultiplier : float = 100;

This may not be enough force to shoot our canon ball, but again we will be able to tweak this value in the Inspector later.

We will be able to shoot canon balls into the scene by clicking on the game window with the mouse. Each time we click, a new canon ball will be instantiated. If the user keeps clicking with the mouse, we will have more and more balls in our scene. At some point the Physics engine will start to get very very slow trying to update 2000 spheres in our scene. To prevent the player from adding an infinite number of canon balls in the scene, we will keep track of each new canon ball in an array and if there are more than 10 canon balls in the scene, we will remove the oldest one.

private var balls = new Array();

The balls array will be used to store references to all of the cannon balls that have been shot into the scene. Once our array gets to a certain size, we will remove the oldest ball in the list.

Since we want to make sure that the mouse cursor is always visible on screen, we will set the showCursor property of the Screen class to true.

function Awake()
{
	Screen.showCursor = true;
}

We will use the Start() function to build up our wall.

The Start Function

The Start function is executed after all of the GameObjects in the scene have been created. This is where we will use the brick prefab to build our brick wall.

function Start () 
{
	if ( brickPrefab != null )
	{
		var brickSize = brickPrefab.renderer.bounds.size;
				
		var X = brickPrefab.transform.position.x + brickSize.x;
		var Y = brickPrefab.transform.position.y;
		var Z = brickPrefab.transform.position.z;
		
		var brickOrientation = brickPrefab.transform.rotation;
		
		for( var i = 0; i < numBricksY; ++i )
		{
			for ( var j = 0; j < numBricksX; ++j )
			{
				if ( i == 0 && j == ( numBricksX - 1 ) ) break;
				Instantiate( brickPrefab, Vector3( X, Y, Z ), brickOrientation );
				X += brickSize.x;
			}
			X = brickPrefab.transform.position.x;
			Y += brickSize.y;
		}
	}
}

The first thing we do in this function is check to make sure our brick prefab is not null. There must be a valid reference to a GameObject before we can do anything with it. We will set a reference to the brick GameObject that exists in our scene using the Inspector later.

If we have a valid reference to a GameObject, we will query the size (dimensions) of the GameObject using the GameObject's Renderer component. The GameObject's Renderer component can be accessed using the renderer property of the GameObject.

Every type that derives from the Component type (including the GameObject type and MonoBehaviour type) have several predefined properties to access the more common component types. I suggest you familiarize yourself with the Component class, the GameObject class and the MonoBehaviour class.

On lines 29-31, we use the brick prefab's position in the scene to determine the initial position of our brick wall. On line 29 We add the size of the brick in the X axis so that we don't create the first brick inside the brick that is already in our scene.

On line 33, we store the orientation of the original brick. We will use this orientation to rotate the new bricks in the scene to match the orientation of the original brick.

To build our brick wall we will create several rows of bricks. The width of each row of bricks is determined by the numBricksX variable. The number of rows, or the height of the brick wall is determined by the numBricksY variable. For example, if numBricksX is 5 and numBricksY is 5, we will create 5 rows of 5 bricks for a total of 25 bricks.

The outer for-loop (on line 35) will loop through the rows of bricks. The inner for-loop (on line 37) will create a brick for each column of the brick wall.

On line 39 we check to see if we are at the end of the first row of bricks. If we are, we want to place 1 less brick to compensate for the original brick that is in the scene. If we didn't account for this extra brick, we'd have one extra brick on the first row of bricks (which would just look silly).

The break keyword will break-out of the currently executing for-loop. In this case, we are in the inner for-loop so the break keyword will break-out of the inner for-loop and the script will continue executing the outer for-loop.

On line 40, we use the Instantiate function to create a copy of our brick prefab. The first argument must be a valid reference to the GameObject we want to duplicate. The second argument to the Instantiate function is the position in world-space where we want the cloned object to be placed. And the third and final argument to the Instantiate function is the rotation of the cloned object. The Instantiate function will return a reference to the cloned object. If we don't plan on doing anything with the cloned object, we can simply ignore the returned reference.

On line 41, we update the X variable to the position where the next brick will be cloned.

Once we've created a row of bricks, we move up the Y axis to create another row of bricks.

And that's all there is to creating a grid of bricks.

TRY THIS: Insert the following line of code inside the inner for-loop (just after line 41) and run your game:

yield WaitForSeconds( 0.1 );

If done correctly, you will be able to see the bricks "popping" into existence as they are being instantiated. This will allow you to visualize how the for-loops are working to create the brick wall.

Now let's handle the canon ball firing.

The Update Function

In the Update() function, we will handle the firing of the canon ball.

function Update () 
{
	if ( Input.anyKeyDown && ballPrefab != null )
	{
		var ray : Ray = Camera.main.ScreenPointToRay( Input.mousePosition );
		var ball = Instantiate( ballPrefab, ray.origin, Quaternion.identity );
		// Put a force on the ball in the direction of the ray generated by the position of the mouse.
		ball.rigidbody.AddForce( ray.direction * forceMultiplier );
		balls.Push( ball );
	}
	
	if ( balls.length > 10 )
	{
		var removeMe : Object = balls[0];
		balls.RemoveAt(0);
		Destroy(removeMe);
	}
}

Anytime the player presses a key on the keyboard or presses a button on the mouse, we will fire a ball into the scene. Of course, we also want to make sure that the ballPrefab has a valid reference to a prefab object.

If we have a valid reference to a prefab, we want to determine where the mouse cursor is in world-space. In order to determine the world-space position of the mouse cursor, we need to have a camera to project through. The Camera class has a reference to the main camera in the scene. Our simple scene only defines one camera and by default, this camera is the main camera.

The Camera class defines several functions to transform from screen-space (where our mouse cursor is) into world-space (where our bricks are) as well as transforming world-space positions back to screen-space (useful for adding 2D GUI elements to objects in 3D space). In this case, we use the Camera's ScreenPointToRay function to convert our mouse cursor position in screen-space into a 3D ray in world-space. The ray's origin will be the position of the camera (the eye position) and the direction of the ray will point from the camera's position through the screen at the position of the mouse cursor.

We can use the ray variable returned from the ScreenPointToRay() function for 2 things:

• Use the Ray.origin property to determine the position to instantiate our canon ball.
• Use the Ray.direction property to determine the direction to fire our canon ball.

On line 54 we use the Instantiate function again but this time to create a canon ball sphere object. In this case, we ray.origin to position the new sphere instance and the Quaternion.identity property to determine the rotation of the new sphere.

A Quaternion class is used to represent an orientation (rotation) in 3D space and the Quaternion.identity property represents a zero rotation (no rotation in any axis).

The next thing we need to do is to propel our canon ball forward in the direction we clicked on the screen. We do this by applying a force on the Rigidbody component of the new ball instance. Without a valid Rigidbody component on the ball prefab, we could not apply physical forces to the ball instance.

We use the ray.direction vector to determine the direction to fire the ball. The ray.direction property is a normalized (length of 1) vector that we can scale by multiplying by the forceMultiplier variable. The value of the forceMultiplier will determine how fast our ball is projected into the scene.

We also want to make sure the player cannot add an infinite number of balls in the scene. So we add the ball to the balls array using the Push() function on the array. This will add a reference of the ball instance to the last element of the array. If the ball array gets too long (more than 10 elements in this case), then we will remove instances starting from the first element. The RemoveAt() function will remove an element from the array at a particular index. All elements in the array that have an index greater than the index specified in this function will be shifted to fill the gap. By removing the element at index 0, we know we are always removing the oldest ball first.

GameObjects can be removed from the scene using the Destroy() method.

Adding the Logic to the Scene

If you run the game now nothing will happen. We haven't added the script we just created to the scene yet.

Create an empty GameObject in the scene. Rename the empty GameObject to "Logic Controller" or something similar.

Drag-and-drop the WallBreaker script asset from the Project view onto the Logic Controller GameObject in the Hierarchy view.



Unity - Wall Breaker (9)

Before we can play the game, we need to assign the Brick Prefab and the Ball Prefab references to our Wall Breaker script component.

Drag the Cube GameObject (the original brick) from the Hierarchy view onto the Brick Prefab variable in the Wall Breaker script component attached to the Logic Controller GameObject.

Drag the Sphere prefab from the Project view onto the Ball Prefab variable in the Wall Breaker script component attached to the Logic Controller GameObject.



Unity - Wall Breaker (10)

Save your scene!

If you play the game now, you probably won't see very much because we haven't added any lights to the scene yet.

Add a directional light to the Main Camera and zero the position and rotation so that the directional light is always pointing in the direction of the camera.

Tweaking and Polish

Now that we have the main functionality of our game working, we can tweak a few of the variables and add some polish.

• Make the wall 15 bricks wide and 15 bricks high.
• Adjust the force multiplier to fire the balls faster. I found that 1300 was a good force to shoot the ball.
• Add spotlight that is looking down on your wall. Make the spotlight cone large enough to brighten the wall.
• Add a texture to the original brick in the scene.
• Add a texture to the ball prefab in the project view.
• Position and orient the Main Camera so that your entire wall is in view when you play the game.
• Apply any other tweak values or polish to your game to make it more fun.

Playing your Game

When you are finished, your final game should look something similar to what is shown below.

Click with your mouse in the window to fire a ball at the wall.

Conclusion

This article covers a lot of details. I introduced some basic JavaScript principles such as functions, variables, class objects, and logical operations. I also introduced instantiating prefabs from both a scene object and a prefab asset in the Project view using the Instantiate() function. We also learned how to use Arrays to store lists of objects. And you also learned how to keep your game running smoothly by destroying the excessive GameObjects using the Destroy() function.

I hope that you have learned enough to get you started scripting in Unity and you also learned how easy it is to add functionality to your game.

From here, I recommend you try to create your own interesting prototypes that may someday become the next block-buster game title!

References

The Unity Scripting Reference: http://docs.unity3d.com/Documentation/ScriptReference/index.html

]]> http://3dgep.com/?feed=rss2&p=3474 1 http://3dgep.com/?p=3477 http://3dgep.com/?p=3477#comments Tue, 14 Aug 2012 10:57:46 +0000 Jeremiah van Oosten http://3dgep.com/?p=3477 Continue reading →]]>

Unity – Assets

In the previous article titled Introduction to Unity 3.5 I introduced the Unity interface and we created a simple project that shows a rotating cube. In this article, I want to introduce some basic Unity concepts such as the Asset pipeline and the GameObject-Component model and introduce a few of the Components that Unity provides. I will not go into too much detail about the different components in this article (I will dedicate a different article for each of the more complex components such as Terrain, Particle Effects, Physics, Audio, and Scripts).

Table of Contents

1. Importing Assets
   1. Models
      1. Autodesk 3ds Max
      2. Autodesk Maya
      3. Cinema 4D
      4. Cheetah3D
      5. Modo
      6. Blender
      7. Import Settings
         1. Scale Factor
         2. Mesh Compression
         3. Optimize Mesh
         4. Generate Colliders
         5. Swap UVs
         6. Generate Lightmap UVs
         7. Normals
         8. Tangents
         9. Smoothing Angle
         10. Split Tangents
         11. Import Materials
         12. Material Naming
         13. Material Search
         14. Animations - Generation
         15. Bake Animations
         16. Animation Wrap Mode
         17. Split Animations
         18. Animation Compression
         19. Animation Compression Errors
   2. Textures
      1. Import Settings
         1. Texture
         2. Normal Map
         3. GUI
         4. Reflection
         5. Cookie
         6. Lightmaps
         7. Advanced
   3. Audio
   4. Video
   5. Text
2. GameObject
   1. Searching for GameObjects
      1. Assign by Reference
      2. Find by Tag
      3. Find by Name
3. Prefabs
   1. Creating Prefabs
4. Components
   1. Animation Components
      1. Animation
      2. Animation Clip
   2. Audio Components
      1. Audio Listener
      2. Audio Source
   3. Effects Components
      1. Particle System (Shuriken)
      2. Halo
      3. Lens Flare
      4. Line Renderer
      5. Trail Renderer
      6. Projector
   4. Mesh Components
      1. Mesh Filter
      2. Mesh Renderer
      3. Skinned Mesh Renderer
      4. Text Mesh
   5. Rendering Components
      1. Camera
      2. Flare Layer
      3. GUI Layer
      4. GUI Text
      5. GUI Texture
      6. Light
      7. Light Probe Group
      8. Occlusion Area (Pro Only)
      9. Occlusion Portals
      10. Skybox
      11. Level of Detail (Pro Only)
   6. Physics Components
      1. Physics
         1. Rigidbody
         2. Character Controller
         3. Consant Force
      2. Colliders
         1. Sphere Collider
         2. Box Collider
         3. Capsule Collider
         4. Mesh Collider
         5. Wheel Collider
5. Conclusion
6. Exercise
7. References

 

Importing Assets

Unity has probably the most comprehensive support for different asset types that you would want to use in your game. Unity has native (built-in) support for many file formats for model files, texture files, audio files, video files, and text files as can be seen from the table below:

Type	External Package	Extension	Requirements
3D Model	Maya	.ma & .mb	Must have Maya 8.0 or newer installed.
	3D Studio Max	.max	Must have 3D Studio Max installed.
	Cheetah3D	.jas	Must have Cheetah3D 2.6 or newer installed.
	Cinema 4D	.c4d	Must have Cinema 4D 8.5 or newer installed.
	Modo	.lxo	Must have Modo 501 or newer installed.
	Lightwave	.fbx	Models must be exported to FBX format.
	Blender	.blend	Must have Blender 2.45-2.49 or 2.58 or newer (versions 2.50-2.57 broke the FBX exporter in Blender).
	COLLADA	.dae	Natively supported by Unity.
	Autodesk FBX	.fbx	Natively supported by Unity.
	Wavefront	.obj	Natively supported by Unity.
	3D Studio	.3ds	Natively supported by Unity.
	Drawing Interchange	.dfx	Natively supported by Unity.
Texture	Photoshop	.psd	Natively supported by Unity.
	Other Image Formats	.jpg, .png, gif, .bmp, .tga, .iff, .pict, .dds, and more…	Natively supported by Unity.
Audio	MP3	.mp3	Natively supported by Unity.
	Ogg Vorbis	.ogg	Natively supported by Unity.
	Other Audio Formats	.aiff, .wav, .mod, .it, .sm3, and more…	Natively supported by Unity.
Video	Video Formats	.mov, .avi, .asf, .mpg, .mpeg, .mp4	Video files are transcoded by Unity.
Text	Text File Formats	.txt, .htm, .html, .xml, .bytes	Text files are not converted.

[Source]

In most cases, you can simply drop the game asset in the Assets folder in your game project and Unity will automatically import it into the editor.

Models

Unity has native support for some model formats that do not require 3rd-party tools to be installed. The formats include Autodesk FBX (.FBX), Collada (.DAE), Autodesk 3D Studio (.3DS), AutoCAD Drawing Exchange Format (.DXF), and Wavefront Geometry Object File (.OBJ). Any modeling package that export export (or work directly with) one of these model formats can be natively supported by Unity’s built-in model importers.

Some file formats however require 3rd-party software to be installed before Unity will be able to import those files. These file formats include Autodesk 3ds Max and Maya (.max, .ma, .mb), Maxon Cinema4D (.c4d), Cheetah3D (.jas), Modo (.lxo), and Blender (.blend).

Autodesk 3ds Max



Autodesk 3ds Max Icon


Unity can import 3ds Max files (.max) as long as you have Autodesk’s 3ds Max software installed.

Unity will import the following information from the 3ds Max files [source]:

• All nodes with position, rotation, and scale. Pivot points and names are also imported.
• Meshes with vertex colors, normals and one or two UV sets.
• Materials with diffuse texture and color. Multiple materials per mesh.
• Animations
• Bone based animations

[Source]

Autodesk Maya



Autodesk Maya Icon

Unity will import Maya model files (.ma, .mb) as long as you have Autodesk’s Maya software installed.

Unity will import the following information from the Maya files [source]:

• All nodes with position, rotation and scale. Pivot points and Names are also imported.
• Meshes with vertex colors, normals and up to 2 UV sets.
• Materials with Texture and diffuse color. Multiple materials per mesh.
• Animations FK & IK.
• Bone-based animations.

Unity will not import blend shapes. Use bone-based animation instead.

[Source]

Cinema 4D



Cinema4D Icon


Unity will import Maxon Cinema 4D (.c4d) files as long as you have the Maxon Cinema 4D software installed.

Unity will import the following information from the Cinema 4D model files [source]:

• All objects with position, rotation and scale. Pivot points and Names are also imported.
• Meshes with UVs and normals.
• Materials with Texture and diffuse color. Multiple materials per mesh.
• Animations FK (IK needs to be manually baked).
• Bone-based animations.

Unity does not support Point Level Animations (PLA). Use bone-based animations instead.

[Source]

Cheetah3D



Cheetah3D Logo

Unity will import Cheetah3D (.jas) files as long as you have the Cheetah3D software installed.

Unity will import the following information from a Cheetah3D file [source]:

• All nodes with position, rotation and scale. Pivot points and Names are also imported.
• Meshes with vertices, polygons, triangles, UV’s and Normals.
• Animations.
• Materials with diffuse color and textures.

[Source]

Modo



Luxology Modo Icon

Unity will import Modo model files as long as you have the Modo 501 or newer software installed.

Unity will import the following information [source]:

• All nodes with position, rotation and scale. Pivot points and names are also imported.
• Meshes with vertices, normals and UVs.
• Materials with Texture and diffuse color. Multiple materials per mesh.
• Animations.

[Source]

Blender



Blender Icon

Unity will automatically import Blender (.blend) files as long as you have Blender 2.58 or later installed.

Unity will import the following information [source]:

• All nodes with position, rotation and scale. Pivot points and Names are also imported.
• Meshes with vertices, polygons, triangles, UVs, and normals.
• Bones.
• Skinned Meshes.
• Animations.

[Source]

Import Settings

The Import Settings will be displayed in the Inspector view when a Mesh asset is selected in the Project view.



Unity – Model Import Settings

[Source]

Scale Factor

Generally, Unity prefers the world scale of 1 unit per meter as this is the natural units to be used by the physics system. However, an artist may want to work in a different scale (say 1 cm per world unit, or 1 inch per world unit).

Use the Scale Factor import setting to control how Unity will scale the imported mesh.

Mesh Compression

If you are concerned about the files size of the imported meshes (for example, your models will be used on mobile platforms), you can enable mesh compression. There are 4 levels of mesh compression:

• Off: No mesh compression occurs, models are stored with all data intact.
• Low: Some compression occurs. No artifacts should occur.
• Medium: More compression occurs. Some artifacts may occur.
• High: High compression. May cause artifacts in the compressed mesh.

A general rule of thumb is to use the highest level of compression as long as no visible artifacts occur.

Optimize Mesh

With the Optimize Mesh option enabled, Unity will reorganize the vertices in the mesh for optimized rendering.

Generate Colliders

With the Generate Colliders option enabled, Unity will generate a Mesh Collider component during mesh import.

This option should only be specified on static objects (objects that will not be moved very often).

Swap UVs

This option will swap the primary and secondary UV channels. This is useful if the lightmap and the diffuse UV channels are not correct during import.

Generate Lightmap UVs

For static objects that will not be moving very often, it might be useful to disable dynamic lights on those objects and only apply a static (pre rendered) lightmap. Unity can generate a set of UVs that can be used to apply a static lightmap texture to the model.

This option should be disabled for objects that will be moving in the scene and will not have a lightmap applied to them.

Normals

Unity can generate surface normals for models if the original model does not define them.

Usually you will want to Import the normals that are already on the mesh.

Surface normals are only needed on models that will be dynamically lit at run-time. Static models that will only have lightmaps applied to them do not need to have surface normals and setting this option to None can reduce the size of the imported model.

Tangents

Tangent vectors are needed only on models that have normal maps applied to them. For models that will not use normal maps it is best to disable this setting to reduce the size of the imported model.

Smoothing Angle

The Smoothing Angle slider becomes active if you specify Calculate for the Normals setting.

This value will smooth vertex normals by averaging the vertex normals of neighboring vertices as long as edge between the vertices is less than the value of Smoothing Angle. Edges whose angle is greater than this value will appear sharp.

This parameter is measured in degrees.

Split Tangents

Enable the Split Tangents option if normal map lighting is broken by seams on your mesh.

Import Materials

Disable the Import Materials option if you don’t want Unity to generate materials for your models. Disabling this option after the model has been initially imported will not delete the material that were previously generated.

If this option is disabled, Unity will apply the default-diffuse material instead.

Material Naming

This option is only available if the Import Materials option is enabled.

This setting determines how generated materials are named.

• By Base Texture Name: The name of the texture that is applied to the primary (diffuse) texture stage is used to name the generated material in Unity.
• From Model’s Material: The material name that is applied to the imported mesh will be used to name the generated material in Unity.
• Model Name + Model’s Material: The model’s original file name and the mesh’s material name will be combined to produce the generated material’s file name. This option is useful to reduce name clashing if you have many models with the same material names applied to them.

Material Search

The Material Search option controls how Unity will search for a material in the project.

• Local: Unity will only look for a material that matches this model in the folder called Materials that exists in the same directory as the model itself.
• Recursive-Up: Unity will look for a material for this model first in the local folder and continually search parent directory’s Materials folders until it finds a matching material.
• Project-Wide: Unity will search every folder in the project for a matching material.

If Unity does not find a matching material file for the current model’s meshes, then it will generate a new material file in a folder called “Materials” at the same level as the model file itself using the naming convention specified.

Animations – Generation

Controls how animations are imported.

• Don’t Import: No animations or skinning information is imported.
• Store in Original Roots: Animations are stored in the root objects of your animation package. These may be different that the root node of the imported model if the original model file contains several animated meshes.
• Store in Nodes: Animations are stored together with the objects they animate. Use this setting if you have a complex animation setup and want full scripting control.
• Store in Root: The animations are stored in the model’s root node. This is used for animations with a hierarchy (such as a skeletal animated character).

Bake Animations

If your animation contains inverse-kinematics (IK) or simulation in your animation package, Unity will convert it to forward-kinematics (FK) on import. This option is only available for Maya, 3ds Max, and Cinema4D model files.

Animation Wrap Mode

The Animation Wrap Mode drop-down box allows you to select the default wrap mode for imported animations.

The different options are:

• Default: Uses the wrap-mode specified in the Animation split options (described below).
• Once: The animation is played through once and then stops.
• Loop: The animation will restart automatically after it has reached the last frame.
• PingPong: The animation will play in reverse after it has reached the last frame, then play forward after it has reached the first frame again, and then repeat. This is useful for pendulum or oscillating animations.
• Clamp Forever: The animation is played through once but the last frame is repeated indefinitely.

Split Animations

If you have multiple animations described in a single animation sequence, you can split the different animations into multiple animation clips.

Each animation clip defines the following properties:

• Name: The name that identifies the animation clip. This name is used to play the animation clip in scripts.
• Start: The first frame in the main sequence for this clip.
• End: The last frame in the main sequence for this clip.
• WrapMode: The wrap mode for this clip. Wrap modes were described above.
• Loop: Depending on how the animation was created, one extra frame of animation may be required for the split clip to loop properly. If your looping animation doesn’t look correct, try enabling this option

Animation Compression

The Animation Compression drop-down box allows Unity to reduce the number of keyframes needed to represent the animation.

The options are:

• Off: No compression or reduction of keyframes occurs.
• Keyframe Reduction: Unity will try to reduce the required number of keyframes during import. Unity will use the Animation Compression Errors options listed below to determine which keyframes are eliminated.
• Keyframe Reduction and Compression: This is the same as Keyframe Reduction but also compresses the animation data stored on disk. This option does not effect the run-time memory requirements.

Animation Compression Errors

These options determine how Unity performs the keyframe reduction.

• Rotation Error: Defines the maximum angle deviation allowed in degrees. Rotation keyframes with an angular deviation less than this are allowed to be removed.
• Position Error: Defines the maximum change in distance between keyframes that are allowed to be removed.
• Scale Error: Defines the maximum delta deviation allowed in a scale keyframe for that keyframe to be considered for reduction.

Textures

Unity has native support for almost all texture image formats.

• JPEG (.jpg, .jpeg)
• PNG (.png)
• GIF (.gif)
• BMP (.bmp)
• TGA (.tga, .tpic)
• PICT (.pict, .pct, .pic)
• PSD (.psd) Adobe PhotoShop Document Format. Visible layers will be compressed and merged.
• And more…

Textures will be imported automatically by Unity and converted to an optimized texture format based on the settings in the Texture Importer. Unity even supports multi-layered Phtoshop and TIFF files. Visible layers will be automatically flattened on import. You can make changes to these file in your favorite image editor and the modified files will be automatically re-imported and you will be able to see the modifications instantly in the Unity editor.

Import Settings

Selecting an image in the Project view will allow you to adjust the import settings for that image.

There are several different texture types and each type has a different set of input options.

• Texture: This is the most common texture type and it is generally used for textures that will be mapped to 3D models or animated characters.
• Normal Map: This is a special form of the Texture type. It is used to import a texture that will be used to define the surface normals across the faces of a 3D model.
• GUI: This texture type should be used on images that will be used for HUD or GUI elements (like menus or on-screen displays).
• Reflection: This texture type should be applied to images that represent a reflection map (also known as a cube map or environment map).
• Cookie: This texture type should be applied to images of cookies. Just kidding. A light cookie is applied to dynamic lights in the scene and can be used to modify the shape (or pattern) of the light.
• Advanced: This type allows you to have more precise control over how your texture is imported.

[Source]

Texture

The Texture type provides the most common set of import options.



Unity – Texture Import Settings (Texture)

• Alpha from Grayscale: Enabling this option will tell Unity to create an alpha channel for the imported texture based on the image’s grayscale value at each pixel.
• Wrap Mode: Specifies how to handle out-of-range texture coordinates with this texture.
  • Repeat: The texture will be tiled.
  • Clamp: The edges of the texture will be stretched infinently across the face of the polygon.
• Filter Mode: Specifies how the pixels of the texture are blended when the texture is stretched or shrunk.
  • Point: The closets pixel in the texture to the one being sampled is used. This results in blocky textures when viewed up-close but can improve performance.
  • Bilinear: Neighboring pixels in the texture relative to the pixel being sampled are blended together based on distance to the sampled point. This results in blurry pixels when viewed up-close.
  • Trilinear: Same as Bilinear but also blends the results from neighboring mip-map levels.
• Aniso Level: This setting determines the level of anisotropic filtering that is applied when sampling this texture. Higher levels of filtering will produce better results but will be more GPU intensive. This setting should only be applied to textures that will be used for floors, roads, or the ground where the player will be viewing the texture from a sharp angle.

[Source]

Normal Map

The Normal Map texture type should be applied to standard normal maps or bump maps that Unity can convert to normal maps during import.



Unity – Texture Import Settings (Normal Maps)

• Create from Grayscale: Select this option if you want to convert a grayscale image to a normal map. The grayscale images are also called bump maps. White areas of the image represent elevated parts of the texture and normals will be computed based on the differences of neighboring pixels in the image.
  • Bumpiness: This value controls how pronounced the changes in elevation will be. A value of 0 will produce a flat surface (no change in surface normal) and a value of 0.3 will generate very pronounced surface normals.
  • Filtering: Determines how the normals are generated.
    • Smooth: The normal map will appear smoothed.
    • Sharp: The edges of the normal map will appear quite sharp. This might be useful for non-organic surface normals.

The last three settings (Wrap Mode, Filter Mode, and Aniso Level) are the same as for Texture type.

[Source]

GUI

The GUI texture type should be applied to on-screen GUI or HUD elements. Unity will not scale non-power-of-two texture nor will it generate mip maps for GUI textures.



Unity – Texture Import Settings (GUI)

The only setting this texture type has is Filter Mode which is the same for the standard texture types.

[Source]

Reflection

The Reflection texture type is used to generate a reflection map (also known as an environment map or cube map).



Unity – Texture Import Settings (Reflection)

Unity can generate a reflection map texture from a simple 2D texture. Selecting the Reflection texture type will provide the Mapping option that specifies how the reflection map should be generated.

• Sphere mapped: Maps the texture onto a sphere shape. Useful for generating environmental reflection maps.
• Cylindrical: Maps the texture to a cylinder shape. Useful for generating reflection maps that will be used on cylindrical shaped objects.
• Simple Sphere: Maps the texture to a sphere and the texture is deformed when rotated. This is useful if the original texture does not tile.
• Nice Sphere: Maps the texture to a sphere but maintains the original texture’s wrap mode. Useful for textures that can be tiled.

[Source]

Cookie

A Cookie texture can be applied to a light component and will determine the shape of the light as it illuminates objects in the scene. This is similar to a “cookie cutout” that is placed in front of the light to change the shape of the projected light. This technique is typically used in films to achieve a desired lighting effect.



Unity – Texture Import Settings (Cookie)

The Light Type property can be Spotlight, Directional Light, and Point Light.

• Spotlight: For Spotlight light types the cookie texture will be clamped so it’s a good idea to use a texture with a black.
• Directoinal: For Directional light types, the cookie texture will be tiled. In this case, you want to use a texture that can be tiled without seams. This is useful for creating a rolling cloud effect in your outdoor scenes.
• Point: For Point lights Unity will create a texture similar to a Reflection texture that can be used to mask the lighting from an omni-directional light source. Selecting this option will make the Mapping option available. The Mapping option is the same as for the Reflection texture types.

The Alpha from Grayscale, Filter Mode, and Aniso Level settings are the same as for the standard Texture type.

[Source]

Lightmaps

Select the Lightmap texture type if the texture will be applied to objects for static lighting.



Unity – Texture Import Settings (Lightmap)

The Filter Mode and Aniso Level settings are the same for the standard Texture type.

[Source]

Advanced

The Advanced texture type allows you to configure all of the texture import settings manually.



Unity – Texture Import Settings (Advanced)

• Non Power of 2: If texture has non-power-of-two size, this will define a scaling behavior at import time.
  • None: Texture will be padded to the next larger power-of-two size for use with GUITexture component.
  • To nearest: Texture will be scaled to the nearest power-of-two size at import time. For instance 257×511 texture will become 256×512.
  • To larger: Texture will be scaled to the next larger power-of-two size at import time. For instance 257×511 texture will become 512×512.
  • To smaller: Texture will be scaled to the next smaller power-of-two size at import time. For instance 257×511 texture will become 256×256.
• Generate Cube Map: Generates a cubemap from the texture using different generation methods.
• Read/Write Enabled: Select this to enable access to the texture data from scripts (GetPixels, SetPixels and other Texture2D functions). Note however that a copy of the texture data will be made, doubling the amount of memory required for texture asset. Use only if absolutely necessary. This is only valid for uncompressed and DTX compressed textures, other types of compressed textures cannot be read from.
• Import Type: Specify the type of import to apply to this texture.
  • Default: Standard texture type. Use this for 2D textures and GUI texture types. Selecting this option will make two other options available.
    • Alpha from Grayscale: Enabling this option will tell Unity to create an alpha channel for the imported texture based on the image’s grayscale value at each pixel.
    • Bypass sRGB Sampling: Texture will not be converted from gamma space to linear space when sampled. Enable this option for GUI textures and look-up textures.
  • Normal Map:
    • Create from Grayscale: Enable this to turn the color channels into a format suitable for normal mapping.
    • Bumpiness: Control the amount of bumpiness.
    • Filtering: Determine how the bumpiness is calculated.
      • Sharp: Also known as a Sobel filter. this generates normal maps that are sharper than Standard.
      • Smooth: This generates normal maps that are quite smooth.
  • Lightmap: Select this if you want to use the texture as a lightmap.
• Generate Mip Maps: Select this to enable mip-map generation. Mip maps are smaller versions of the texture that get used when the texture is very small on screen.
• Correct Gamma: Select this to enable per-mip-level gamma correction.
• Border Mip Maps: Select this to avoid colors seeping out to the edge of the lower Mip levels. Used for light cookies.
• Mip Map Filtering: Two ways of mip map filtering are available to optimize image quality.
  • Box: The simplest way to fade out the mipmaps – the mip levels become smoother and smoother as they go down in size.
  • Kaiser: A sharpening Kaiser algorithm is run on the mip maps as they go down in size. If your textures are too blurry in the distance, try this option.
• Fade Out Mips: Enable this to make the mipmaps fade to gray as the mip levels progress. This is used for detail maps.
• Fade Range: The left most scroll is the first mip level to begin fading out at. The rightmost scroll defines the mip level where the texture is completely grayed out.
• Wrap Mode: Specifies how to handle out-of-range texture coordinates with this texture.
  • Repeat: The texture will be tiled.
  • Clamp: The edges of the texture will be stretched infinently across the face of the polygon.
• Filter Mode: Specifies how the pixels of the texture are blended when the texture is stretched or shrunk.
  • Point: The closets pixel in the texture to the one being sampled is used. This results in blocky textures when viewed up-close but can improve performance.
  • Bilinear: Neighboring pixels in the texture relative to the pixel being sampled are blended together based on distance to the sampled point. This results in blurry pixels when viewed up-close.
  • Trilinear: Same as Bilinear but also blends the results from neighboring mip-map levels.
• Aniso Level: This setting determines the level of anisotropic filtering that is applied when sampling this texture. Higher levels of filtering will produce better results but will be more GPU intensive. This setting should only be applied to textures that will be used for floors, roads, or the ground where the player will be viewing the texture from a sharp angle.

[Source]

Audio

Unity has native support for many different audio formats. Unity supports .aif, .wav, .mp3, and .ogg.

When you place an audio file somewhere in the Asset directory of your Unity game project, Unity will automatically import the audio file. Audio files can be imported in one of two formats.

• Native: Uses the file’s native file format. In this case, the file will not be compressed. Use this for pre-compressed ambient audio files (already in MP3 or OGG compressed format) or if it is a small 1-shot sound effect. Using this format, the file size on disk will be larger but the audio file will not need to be decoded at runtime before it can be played.
• Compressed: This will produce smaller audio files on disk but the file will need to be decompressed at runtime. Unity will choose the compression algorithm based on the platform the game is being built for. Audio files will be compressed using the Ogg Vorbis CODEC when targeting stand-alone PC or MAC or consoles (XBox360, PS3) or the MP3 CODEC will be used when targeting mobile platforms (Android, iOS, Web).

Audio files are stored as AudioClips in the Asset folder. AudioClips cannot be played directly but must be used in conjuction with an AudioSource component attached to a GameObject in the scene. Before the sound can be heard, there must also be one active AudioListener component which is usually attached to the main camera in the scene.

The AudioClip is simply the container for the audio data that is used by the AudioSource component. Selecting the audio file in the project view will show the import settings for that audio file in the Inspector view.



Unity – Audio Import Settings

• Audio Format: The specific format that will be used for the sound at runtime.
  • Native: This option offers higher quality at the expense of larger file size and is best for very short sound effects.
  • Compressed: The compression results in smaller files but with somewhat lower quality compared to native audio. This format is best for medium length sound effects and music.
• 3D Sound: If enabled, the sound will play back in 3D space. Both Mono and Stereo sounds can be played in 3D.
• Force to mono: If enabled, the audio clip will be down-mixed to a single channel sound.
• Load Type: The method Unity uses to load audio assets at runtime.
  • Decompress on load: Audio files will be decompressed as soon as they are loaded. Use this option for smaller compressed sounds to avoid the performance overhead of decompressing on the fly. Be aware that decompressing sounds on load will use about ten times more memory than keeping them compressed, so don’t use this option for large files.
  • Compressed in memory: Keep sounds compressed in memory and decompress while playing. This option has a slight performance overhead (especially for Ogg/Vorbis compressed files) so only use it for bigger files where decompression on load would use a prohibitive amount of memory.
  • Stream from disc: Stream audio data directly from disc. The memory used by this option is typically a small fraction of the file size, so it is very useful for music or other very long tracks. For performance reasons, it is usually advisable to stream only one or two files from disc at a time but the number of streams that can comfortably be handled depends on the hardware.
• Hardware Decoding: (iOS only) On iOS devices, Apple’s hardware decoder can be used resulting in lower CPU overhead during decompression.
• Gapless looping: (Android/iOS only) Use this when compressing a seamless looping audio source file (in a non-compressed PCM format) to ensure perfect continuity is preserved at the seam.
• Compression (kbps): Amount of Compression to be applied to a clip. Statistics about the compressed file size can be seen under the slider. A good approach to tuning this value is to drag the slider to a place that leaves the playback "good enough" while keeping the file small enough for your distribution requirements.

[Source]

Video

Using video files as textures requires a Pro license.

You can apply a video as a texture to a material using the MovieTexture asset component. Just drop a compatible video file in your project’s Asset folder and Unity will automatically create a MovieTexture asset component.

Unity supports any video format that can be played with Quicktime (.mov, .mpg, .mpeg, .mp4, .avi, .asf). Unity requires Quicktime to be pre-installed on your system. If you don’t have it installed, you can download Quicktime from the Apple website here: http://www.apple.com/quicktime/download/.

Unity does not support .wmv files. These files will need to be transcoded to a compatible format to be used in your game project. I suggest using Adobe Media Encoder and transcode the files to the Quicktime .mov format.



Unity – Video Import Settings

• Bypass sRGB Sampling: Texture will not be converted from gamma space to linear space when sampled. Enable this option for GUI textures and look-up textures.
• Quality: Compression of the Ogg Theora video file. A higher value means higher quality, but larger file size.

Movie textures will not be played automatically when the scene is opened. This must be done in script.

To play a movie file, attach the following script to a GameObject in your scene that has a MovieTexture applied to it’s material.

#pragma strict

private var movieTexture : MovieTexture;

function Start () 
{
	movieTexture = renderer.material.mainTexture as MovieTexture;
	if ( movieTexture != null )
	{
		movieTexture.loop = true;
	}
}

function Update () 
{
	if ( movieTexture != null )
	{
		if ( !movieTexture.isPlaying )
		{
			movieTexture.Play();			
		}
	}	
}

MovieTextures will also not loop by default and will not automatically stop when it has reached the last frame. If you want the movie texture to loop, you must set the loop property on the MovieTexture to true.

When a video file is imported, Unity will import the audio track as a separate AudioClip asset component.



Unity – Movie AudioClip

To play the AudioClip together with the video, drag and drop the AudioClip asset component from the Project view onto a GameObject in the Hierarchy view that you want to act as the source (this does not necessarily have to be the same GameObject as the MovieTexture is applied to but it would make the most sense). Unity will automatically create an AudioSource component on the GameObject and assign the AudioClip to the AudioSource. To play the AudioSource use the audio.Play() method on the GameObject that owns the AudioSource. Don’t forget to set the loop property on the AudioSource to the same value of the loop property on the MovieTexture.

Here is an example script that will automatically play the AudioSource on a GameObject together with it’s MovieTexture (if it has one).

#pragma strict

private var movieTexture : MovieTexture;

function Start () 
{
	movieTexture = renderer.material.mainTexture as MovieTexture;
	if ( movieTexture != null )
	{
		movieTexture.loop = true;
	}
	if ( audio != null )
	{
		audio.loop = true;
	}
}

function Update () 
{
    if ( movieTexture != null )
	{
		if ( !movieTexture.isPlaying )
		{
			movieTexture.Play();
			if ( audio != null )
			{
				audio.Play();
			}
		}
	}	
}

[Source]

Text

Unity also supports text file assets with extensions .txt, .html, .htm, .xml, and .bytes (binary text format).



Unity – Text Asset

Text files have no import options, they are used as-is. However, TextAssets are read-only. You cannot use a TextAsset to write data. You can access the contents of a TextAsset using the text (read-only) property.

Binary data can be imported as a TextAsset asset as long as the file has the .bytes extension, Unity will treat it as a binary file. The binary data can be accessed using the bytes (read-only) property of the TextAsset.

Unity will only publish referenced assets (An asset that is assigned to a public script variable or referenced by a component that is attached to a GameObject) however TextAssets may not be referenced by any script or component. To ensure the TextAsset is published with your build, place the TextAsset in a special folder called Resources. Any assets in a folder called Resources will be published with your build and accessible using the Resources class.

For example, the following script will load a TextAsset and assign the binary data to a texture. The name of the resource to load can be specified in the Inspector by modifying the Texture Name property.

#pragma strict

public var textureName : String;

function Start () 
{
	// Load a binary asset from "Assets/Resources/[textureName].bytes"
	var imageData : TextAsset = Resources.Load( textureName );
	if ( imageData != null )
	{
		var newTexture : Texture2D = new Texture2D( 1, 1 );
		newTexture.LoadImage( imageData.bytes );
		renderer.material.mainTexture = newTexture;
	}

}

When loading resources in this way, you only need to specify the base name. You do not need to specify the full path or the extension of the file.

[Source]

GameObject

Every object in your scene is a GameObject. A GameObject can either be a visual object (such as a Mesh, Terrain or a Light) or a GameObject can simply be a parent node or a root node that is used to group other GameObjects that share some kind of relationship.

This type of hierarchical structure is also known as a Composite. This is a very powerful way to organize your complex scenes.

GameObjects can also be used as logical entities which do not have any renderable component attached to them nor do they necessarily have any child GameObjects with renderable componenents. In this case, a GameObject may only have Script components attached to them which can be used to control the logic of abstract game elements such as Unity’s internal Network functionality.

The image below shows an empty GameObject that has no components attached to it.



Unity – GameObject

A GameObject by itself is not very interesting. You must add at least one Component to a GameObject in order for it to have purpose. For example, to make a GameObject act like a Light, you must attach a Light component to the GameObject.

Every GameObject has the following properties:

• Name: The name that is used to identify the GameObject. The Name property does not have to be unique in the scene unless you need to need to access the GameObject from a script.
• Tag: The Tag property can be used to identify the GameObject. Using the Tag property to search for GameObjects in the scene is more efficient than using it’s name. If you will be accessing a GameObject a lot, then it is better to assign the GameObject an identifiable Tag and use the Tag to find the GameObject instead of the Name property.
• Layer: The Layer property is used to selectively render certain objects (the Camera component’s Culling Mask property can be used to disable rendering of certain GameObjects according to their layer) or to ignore raycast (The Physics.Raycast function accepts a Layer Mask property which can be used to ignore GameObjects according to their Layer property).
• Transform: Every GameObject in the scene has one and only one Transform component. The Transform component determines the position, orientation, and scale of a GameObject relative to its parent (GameObjects at the top-level in the hierarchy view are relative to the scene’s world-origin).
• Static: If a GameObject will not move or it should be used for lightmapping, navigation, or occlusion culling (these topics will be discussed in a later article), then it’s Static property should be enabled. Usually you will only do this on GameObjects that have a Mesh component attached to them and will never move in the scene (such as buildings, level geometry, and static environment props like rocks and trees). Anything that can be moved (such as physics or kinematic controlled GameObjects, or animated character models) should not be marked as Static.

[Source]

Searching for GameObjects

It may be necessary to find a particular GameObject in your scene at run-time. This is done with the power of scripting. There are several ways to accomplish this task and it is important to know the correct way of doing this depending on the situation.

Suppose you have the following scene:



Unity – Test Scene

(Click on the image to show it full-size).

This simple test scene consists of 3 cubes:

• Cube 01 with tag “Right“
• Cube 02 with tag “Middle“
• Cube 03 with tag “Left“

There are 3 ways to access the cube GameObjects in this scene:

• By Reference
• By Name
• By Tag

Assign by Reference

If a GameObject is created in the editor (as opposed to creating the object dynamically at run-time) it is possible to assign the GameObject to a script variable using the Inspector view.

Create a script similar to what is shown below.

#pragma strict

public var otherGameObject : GameObject;

function Start () 
{
	if ( otherGameObject != null )
	{
		Debug.Log("I am \"" + name + "\" and I have a reference to the "
		  + "GameObject with name \"" + otherGameObject.name + "\"" );
	}
}

If you assign this script to the cube GameObjects in this scene (drag and drop the script from the Project view onto the GameObjects in the Hierarchy view) then you see the public property called “Other Game Object” exposed in the Inspector view (shown highlighted in the image below).



Unity – Assign by Reference

If you click the little circle icon next to the parameter in the Inspector view, you will be presented with a dialog box that lets you select a compatible GameObject from the scene (make sure you select the “Scene” tab at the top of this dialog box).



Unity – Select GameObject

If I assign Cube 01 a reference to Cube 02, Cube 02 a reference to Cube 03 and Cube 03 a reference to Cube 01 then I should get the following output in the console window (Shift + Ctrl + C):



Unity – Console Window

This is probably the most efficient way to assign a reference to a GameObject. However, you may not know until run-time which GameObject you need to refer to.

Find by Tag

You can also use a GameObject‘s Tag property to find it within the scene.

Modify the script using the following code:

#pragma strict

public var otherTag : String;
private var otherGameObject : GameObject;

function Start () 
{
	if ( otherTag.Length > 0 )
	{
		otherGameObject = GameObject.FindGameObjectWithTag(otherTag);
		if ( otherGameObject != null )
		{
		Debug.Log("I have tag \"" + tag + "\" and I found a GameObject with tag \""
		  + otherGameObject.tag + "\"" );		
		}
	}
}

In the Inspector, change the Other Tag script property to match the Tag property that was assigned to each corresponding GameObject (For example, Cube 01 has Tag “Right“).

If you run the game, you should see the following output in the Console window (Shift + Ctrl + C):



Unity – Console Window (2)

Using the Tag property to find a GameObject in the scene is more efficient than using the Name property because Unity is able to pre-sort GameObjects in the scene into lists according to the GameObject‘s Tag property.

The Tag property does not have to be unique. For example, many GameObjects can have the same Tag and you can retrieve all the GameObjects in the scene with a particular Tag value using the GameObject.FindGameObjectsWithTag(String) static method (notice the plural ending on GameObjects in the method name “FindGameObjectsWithTag“).

The GameObject.FindGameObjectWithTag(String tag) static method is used to retrieve a reference to a single GameObject and the GameObject.FindGameObjectsWithTag(String tag) static method is used to retrieve an array of all GameObjects with the matching tag.

[Source]

Find by Name

GameObjects can also be searched in the scene by their assigned name using the GameObject.Find(String name) static method. This is probably the most inefficient way to search for GameObject‘s because Unity must search every GameObject in the scene matching it’s name property to the search parameter. In some cases, it may be unavoidable. For example, a dynamically created object that does not have a tag can only be found by it’s name.

Generally, you do not want to call this method every frame (in the Update method) but instead you will want to cache a reference to the GameObject and only search for it by name if the reference is NULL.

I will not show an example of this as it is very similar to the example I already showed using the Tag property.

[Source]

Prefabs

A Prefab is a GameObject that you can save to your Asset folder so that you can easily create copies of that GameObject in your scene or in other scenes. Prefabs can also be instantiated dynamically at run-time using scripts.

A Prefab can also be considered a Template for a complex GameObject structure. You can modify the properties of the individual instances so that each instance of the Perfab can have different properties while maintaining the general structure of the original Perfab.

To create a Prefab, first construct your GameObject in the scene view then drag-and-drop the GameObject from the Hierarchy view to the Project view.

Creating Prefabs

Let’s create a Brick prefab that can be used to instantiate a lot of Brick instances in the scene at runtime.

Open Unity and create a new scene.

Create a Cube GameObject (select GameObject -> Create Other -> Cube from the main menu). Rename the Cube GameObject to “Brick“.



Unity – Brick Prefab

Add a Rigidbody component to the Brick GameObject (with the Brick selected, select Component -> Physics -> Rigidbody from the main menu). Now we have a physics controlled brick.

Now drag-and-drop the Brick game object from the Hierarchy view into the Project view. You have just created a Prefab!



Unity – Brick Prefab (2)

In the screen shot above, you see in the Project view that we have created a new Asset called Brick. The Asset is a copy of the original Brick GameObject in the Hierarchy view. You will also notice that the Brick GameObject in the Hierarchy view is colored blue. This indicates that the GameObject is created from a Prefab Asset.

Components

Components give GameObjects their functionality. A GameObject can be considered a container for many different Components.

When you create an empty GameObject, it will always have the Transform component by default. A GameObject cannot exist without a Transform component because this component determines the GameObject‘s position, orientation, and scale in the world. You cannot remove the Transform component from a GameObject.

Components can be added to a GameObject by selecting the GameObject in either the Hierarchy or the Scene view. With a GameObject selected, choose the Component you want to add to the GameObject using the Component menu item on the main menu.

For the remainder of this article, I will provide a brief introduction to the different types of components that the Unity editor provides. In later articles I will demonstrate how to use these components in more detail.

[Source]

Animation Components

The animation components allow you to import or create animation data that can be used to manipulate GameObjects at run-time.

[Source]

Animation

The Animation component allows you to assign a list of animations that can be played using the animation scripting interface.



Unity – Animation Component

[Source]

Animation Clip

The Animation Clip is an asset component that is added to the Animation component discussed above. The Animation Clip contains the animation data. Animation Clips that are imported from an animated mesh file (such as FBX file) cannot be manipulated directly. You must either create a new Animation Clip asset in the project or duplicate (Ctrl-D) an Animation Clip that has been imported.

Animation Clips can be edited using the Animation View shown below.



Unity – Animation View

[Source]

Audio Components

The Audio components implement both ambient (music) and one-shot sound effects in Unity.

[Source]

Audio Listener

The Audio Listener is usually attached to the Main Camera GameObject. This component will determine how the 3D sound effects are produced.

The Audio Listener component does not have any properties to manipulate.



Unity – Audio Listener

[Source]

Audio Source

An Audio Source component is used to produce sound effects in the game. Audio sources can be attached to any GameObject. The position of the GameObject in the world will determine the position and attenuation of the Audio Source.



Unity – Audio Source

[Source]

Effects Components

Effects Components all you to add visual effects to the game.

[Source]

Particle System (Shuriken)

Unity 3.5 introduced a new particle system called Shuriken. Shuriken is a powerful particle effects editor that allows you to easily create complex particle effects.

The Particle System component is manipulated with the Particle Effects view.



Unity – Particle System (Shuriken)

[Source]

Halo

The Halo Component can be used to render a circular particle at the position of the GameObject. The Halo component is used to simulate a glow and works best when used on point light sources.



Unity – Halo Component

[Source]

Lens Flare

The Lens Flare component is normally attached to light sources and simulates an effect that is typical on camera lenses when a very bright light source is in direct view of the camera.



Unity – Lens Flare Component

[Source]

Line Renderer

The Line Renderer component is used to render 3D textured path of polygons using an array of points to determine the path. The path is not smoothed or interpolated so to create smooth paths, you will need alot of points.

The Line Renderer component does not fade-out over time.



Unity – Line Renderer Component

The Line Renderer component uses the same algorithm to compute the geometry of the line as the Trail Renderer component discussed next.

[Source]

Trail Renderer

Like the Line Renderer component, the Trail Renderer component will draw a 3D line using the line drawing algorithm the Line Renderer uses. Unlike the Line Renderer component, the Trail Renderer component will use the last sampled position of the GameObject it is attached to determine the path of the line. This means that the GameObject must be moving for a trail to be formed. Stationary GameObjects will not produce a trail.



Unity – Trail Renderer

The Trail Renderer component will automatically fade-out over time determined by the Time parameter of the Trail Renderer component.

[Source]

Projector

A Projector component is similar to the Camera component in that it defines a view frustum. Any geometry that is within the view frustrum will have the the projector’s material projected onto it. Projectors are very useful for things like bullet holes in walls or shadow blobs below characters and vehicles which is a cheap way of producing dynamic shadows!

Do not use projects where a normal textured quad will produce the same result!



Unity – Projector Component

[Source]

Mesh Components

Meshes are the primary graphics primitive used to represent visual objects in Unity. Several components exist to produce static or animated characters, and 3D text.

[Source]

Mesh Filter

The Mesh Filter component is a container for mesh data. When you import a model into your project (an FBX file for example) it is possible that the model contains several sub-meshes. The Mesh Filter component is used to refer to a particular sub-mesh of the model.

A Mesh Filter component must be used together with a Mesh Renderer component on the same GameObject. A GameObject with a Mesh Filter component will store the referenced mesh geometry in garphics memory but nothing will be rendered without a Mesh Renderer component assigned to the GameObject.



Unity – Mesh Filter

[Source]

Mesh Renderer

A Mesh Renderer component will take the geometry data from the Mesh Filter component and render it to the screen at the GameObject’s current position and orientation.



Unity – Mesh Renderer

[Source]

Skinned Mesh Renderer

The Skinned Mesh Renderer component is used to render animated skinned meshes (like character models).



Unity – Skinned Mesh Renderer

[Source]

Text Mesh

The Text Mesh component is used in conjunction with the Mesh Renderer to produce 3D text in the scene. The text is not extruded but instead 2D quads are used to render each letter in 3D space. This means that the text will not be visible when viewed from the side. This component could be used to create dynamic billboard text (for example a scrolling marquee light board sign)



Unity – Text Mesh

[Source]

Rendering Components

Render components are components that have something to do with rendering in-game and user interface elements. This category includes the camera, gui elements, lights, occlusion, skybox and Level of Detail components.

[Source]

Camera

The Camera component is the most ubiquitous component in your scene. Without at least one GameObject with a Camera component in your scene, you will not see anything in your game. Playing the game without a camera in the scene will produce a black screen.



Unity – Camera Component

When you select the Camera, the Camera Preview dialog appears in your scene view.

[Source]

Flare Layer

A Flare Layer component must be added to the Camera in order for the Lens Flare component to render.



Unity – Flare Layer

If you remove the Flare Layer component from the Camera or disable the component, the Lens Flare effect will still render in the Scene view but it will not appear in the Game view.

[Source]

GUI Layer

Like the Flare Layer, the GUI Layer is required to render all 2D GUI Text and GUI Texture elements.

[Source]

GUI Text

The GUI Text component is used to display text on the screen. The position the text appears on screen is determined by the GameObject‘s X and Y position values. The X and Y values are in normalized (in the range [0,1]) screen space where (0,0) is the bottom-left and (1,1) is the top-right point on the screen.



Unity – GUI Text

[Source]

GUI Texture

The GUI Texture component is used to display a 2D screen texture elements. The GUI Texture component use’s the GameObject‘s X and Y position to determine the normalized (in the range [0,1]) screen space of where the texture will appear.



Unity – GUI Texture

As you can see from the image above, the position of the GameObject with the GUI Texture component is (0.5, 0.5, 0) which causes the GUI Texture to appear in the center of the screen.

[Source]

Light

Lights are used to illuminate the scene.



Unity – Light Component

[Source]

Light Probe Group

The Light Probe Group component allows you to add light probes to the scene. A Light Probe works in conjunction with Light Mapping (I will discuss Light Mapping in another article) in order to properly illuminate dynamic objects according to the light contributions of baked-only lights.



Unity – Light Probes

[Source]

Occlusion Area (Pro Only)

The Occlusion Area component is used to define a region in the game where occlusion culling will occur.

By default, Unity will generate occlusion data based on the bounds of the objects in the scene but you may want to specify certain areas that will generate data structures for occluding static objects (view volume) and dynamic objects (target volume). The Occlusion Area component allows you to do that.



Unity – Occlusion Area

[Source]

Occlusion Portals

The Occlusion Portal component is similar to Occlusion Area component in that it allows you to define a 3 dimensional area that is used for occlusion culling.

An Occlusion Portal is used in doorways where the door can be opened and closed. The portal can be “Opened” or “Closed” in script when the door that is occluding the geometry is opened or closed.



Unity – Occlusion Portal

[Source]

Skybox

A Skybox component is used to simulate an environment that wraps around your entire game world. You can either add the Skybox component to the main camera, or if you have many camera’s in the scene and you want all of them to use the same Skybox, you can configure the Skybox material in the Render Settings (Choose Edit -> Render Settings from the main menu).



Unity – Skybox

[Source]

Level of Detail (Pro Only)

The LOD Group component allows you to specify different representations of an object based on it’s distance away from the camera.



Unity – LOD Group

[Source]

Physics Components

Unity uses the NVIDIA PhysX physics engine to perform the physics simulations. The physics components are required for GameObjects to participate in physics simulations and to perform collision detection with other physics controlled GameObjects.

[Source]

Physics

Rigidbody

The Rigidbody component allows the GameObjects to be influenced by physical forces such as gravity or wind forces.

Static objects that will not be physics simulated do not need to have rigid bodies assigned to them.



Unity – Rigidbody

In the image above, you see three cubes hovering over a plane. When simulating, the cubes will fall onto the plane. The cubes will act under the force of gravity and therefor must have a Rigidbody component assigned to them. The plane however is stationary and won’t move. In this case, the plane does not need to have a Rigidbody component assigned to it.

[Source]

Character Controller

The Character Controller component is usually attached to the player character and any game character that needs to move around the scene. This component will create a Capsule Collider around the character that is used to perform the physics collision with the environment.



Unity – Character Controller

[Source]

Consant Force

The Constant Force component can be used to apply a physical force to a GameObject. This will allow the GameObject to appear to be pushed through space by an external force (such as a rocket).



Unity – Constant Force

[Source]

Colliders

Collider components allow for collision detection to occur. Without a collider component on the GameObject, then it will simply pass through all other objects as if they were not there.

Sphere Collider

As the name suggests, a Sphere Collider component simulates the shape of a sphere. This collider is commonly used on sphere shaped objects.



Unity – Sphere Collider

[Source]

Box Collider

The Box Collider component should be placed on objects that resemble the shape of a box.



Unity – Box Collider

[Source]

Capsule Collider

The Capsule Collider component is used on cylinder shaped objects that are rounded on each end. A Capsule Collider is automatically created on GameObjects that have a Character Controller component attached to them.



Unity – Capsule Collider

[Source]

Mesh Collider

The Mesh Collider can be used if none of the other colliders fit the shape of your object.

The Mesh Collider component will not collide with other Mesh Collider components unless the “Convex” option is enabled.



Unity – Mesh Collider

[Source]

Wheel Collider

The Wheel Collider components are special collision components that are used for grounded vehicles.



Unity – Wheel Collider

[Source]

Conclusion

In this article I talked about the three basic building blocks that Unity uses to help you make games:

• Assets
• GameObjects
• Components

In this article, I did not describe every component available to you in Unity but I only wanted to give a brief introduction to some of the more commonly used components that you will very likely use in your own projects.

In later articles, I would like to describe some of the more interesting features of the Unity editor such as terrains, physics, GUI interfaces, and special effects.

Exercise

The intention of this exercise is to introduce you to the Asset pipeline in Unity.

1. Create a new Unity Project (do not add any standard assets). By default, Unity will create an empty scene with only a Main Camera.
2. Download a 3D model file or use a 3D model that you have previously created. The model file must be in a format that is supported by Unity (any of the model formats listed in this article will work as long as you have the relevant software installed. FBX and OBJ model formats will work without any additional software installed). You can find free models on TurboSquid (http://www.turbosquid.com/Search/3D-Models?max_price=0&&min_price=0 – Requires you to login using a user account).
3. Save the 3D model in the Asset folder or use the Assets -> Import New Asset… command from the main menu to import your model asset into Unity.
4. Create an instance of the model you just imported in an empty scene by drag-and-droping the 3D model Asset into the scene view.
5. Create a Plane GameObject in your scene (select GameObject -> Create Other -> Plane from the main menu).
6. Zero the Position and Rotation of the Plane GameObject so that it is centered at the origin of the world.
7. Create a Cube GameObject in your scene (select GameObject -> Create Other -> Cube from the main menu).
8. Create a Sphere GameObject in your scene (select GameObject -> Create Other -> Sphere from the main menu).
9. Create a Cylinder GameObject in your scene (select GameObject -> Create Other -> Cylinder from the main menu).
10. Position the Cube, Sphere, and Cylinder above the Plane so that no GameObjects are intersecting.
11. Import 4 different image files into your project.
12. Place a different texture on each of the 4 GameObjects you just created (Plane, Cube, Sphere, and Cylinder)
13. Create a directional light to illuminate your scene.
14. Orient your Main Camera so that all of the objects are in view.
15. Save your scene.

If you play your game, you should see something similar to what is shown below.



Unity – Asset Pipeline Exercise

Of course your scene will look better than mine. My scene is victim to “programmer art”.

References

The Unity User Manual:
http://docs.unity3d.com/Documentation/Manual/index.html

The Unity Component Reference documentation:
http://docs.unity3d.com/Documentation/Components/index.html

The Unity Scripting Reference:
http://docs.unity3d.com/Documentation/ScriptReference/index.html

]]> http://3dgep.com/?feed=rss2&p=3477 2 http://3dgep.com/?p=3246 http://3dgep.com/?p=3246#comments Mon, 16 Jul 2012 20:24:40 +0000 Jeremiah van Oosten http://3dgep.com/?p=3246 Continue reading →]]>



Unity


In this article, I will introduce you to the Unity game editor. Unity is a tool for creating and deploying games to PC, consoles, web and mobile devices. In this post, I will go through the steps to get Unity installed on your computer and I will introduce you to the basic features of Unity. Unity makes it easy for anyone to get started making games. You will not need any previous game development experience to follow these articles but by the end, you will be prepared to start making your own games like a professional!

Table of Contents

1. Installing Unity
2. Learning the Interface
   1. The Main Menu
      1. The File Menu
      2. The Edit Menu
      3. The Assets Menu
      4. GameObject Menu
      5. The Component Menu
      6. The Terrain Menu
      7. The Window Menu
      8. The Help Menu
   2. The Toolbar
      1. Transform Tools
         1. View Manipulation
         2. GameObject Manipulation
      2. Gizmo Tools
         1. Pivot
         2. Center
         3. Global
         4. Local
      3. Game Player Controls
      4. The Layers Tool
      5. The Layout Tool
   3. The Editor Windows
      1. The Scene View
         1. Navigating the Scene View
         2. Draw Mode
         3. Render Mode
         4. Scene Mode Controls
         5. Search Filter
   4. The Game View
   5. The Inspector View
   6. The Hierarchy View
   7. The Project View
   8. The Animation View
   9. The Profiler View (Pro Only)
   10. The Particle Effect View
   11. The Asset Store View
   12. The Asset Server View (Team License)
   13. Other Windows
       1. Lightmapping
       2. Occlusion Culling (Pro Only)
       3. Navigation (Pro Only)
3. Creating Your First Project
   1. Adding Some Content
   2. Adding a Light
   3. Parenting GameObjects
   4. Make it Spin
4. Adding Your Projects to Version Control
   1. Enable Meta File Mode
   2. Adding to Version Control
5. More Information

 

Installing Unity

The first thing you have to do before you can start using Unity is install it. Navigate to http://unity3d.com/ and click the “Download” link on the top-right of the page.

On the download page, click the “Download Unity” button. Once the file has been downloaded, execute the installer on your PC.



Installing Unity (1)

The Unity setup screen should appear. Click the “Next” button.

Agree to the licensing terms to continue.



Installing Unity (2)

Select all of the available components options and click the “Next” button to continue.



Installing Unity (3)

Select the folder where you want Unity to be installed and click the “Install” button.

If everything went okay, you should see the following screen.



Installing Unity (4)

Click the “Finish” button to close the installer and run Unity.

Unity comes with an example project called “AngryBots” that you can open if you don’t yet have a Unity project to run. I will use this example project in this article to demonstrate the different parts of the Unity editor. By default, the AngryBots example project is installed in “C:\Users\Public\Documents\Unity Projects” on Windows 7.

If you didn’t install the example project, or you would like to install a different example project, you can download additional example projects from the Unity Asset store which is accessible directly in the editor.

Learning the Interface

The first time you open the Unity editor, you will see a few of the default tabbed windows called Views open.



Unity Interface

The image above shows the Unity editor with the “Tall” layout applied.

The Main Menu

The Main Menu is the menu at the top of the application window. It is organized into a logical set of “tasks” that you would need to access while you work on the project.

The File Menu

The File menu contains menu items that are used to create and open Scenes and Projects. A Scene can be a single level of your game, or a scene can be used to define the main menu for your game. A Project is the collection of things that is needed to create a game such as art assets, audio assets, scripts, and also the different game scenes.



Unity – File Menu

The Edit Menu

The Edit menu contains the typical items you would expect in an edit menu such as Cut, Copy, Paste, Undo, Redo and it also contains items to modify the Editor Preferences as well as Project specific options and Render options.



Unity – Edit Menu

The Assets Menu

The Asset menu is used for creating new assets or Importing assets from external files. You can also Import standard asset packages (standard asset packages are provided by Unity Technologies) as well as Import and Export custom asset packages for use in other projects (custom asset packages are user created).



Unity – Asset Menu

Generally speaking Assets are the files that are created outside of Unity. Unity has fantastic support for a lot of different Asset types including 3D models, image formats, audio & video formats, and XML file formats.

Type	External Package	Extension	Requirements
3D Model	Maya	.ma & .mb	Must have Maya 8.0 or newer installed.
	3D Studio Max	.max	Must have 3D Studio Max installed.
	Cheetah3D	.jas	Must have Cheetah3D 2.6 or newer installed.
	Cinema 4D	.c4d	Must have Cinema 4D 8.5 or newer installed.
	Modo	.lxo	Must have Modo 501 or newer installed.
	Lightwave	.fbx	Models must be exported to FBX format.
	Blender	.blend	Must have Blender 2.45-2.49 or 2.58 or newer (versions 2.50-2.57 broke the FBX exporter in Blender).
	COLLADA	.dae	Natively supported by Unity.
	Autodesk FBX	.fbx	Natively supported by Unity.
	Wavefront	.obj	Natively supported by Unity.
	3D Studio	.3ds	Natively supported by Unity.
	Drawing Interchange	.dfx	Natively supported by Unity.
Image	Photoshop	.psd	Natively supported by Unity.
	Other Image Formats	.jpg, .png, gif, .bmp, .tga, .iff, .pict, .dds, and more…	Natively supported by Unity.
Audio	MP3	.mp3	Natively supported by Unity.
	Ogg Vorbis	.ogg	Natively supported by Unity.
	Other Audio Formats	.aiff, .wav, .mod, .it, .sm3, and more…	Natively supported by Unity.
Video	Video Formats	.mov, .avi, .asf, .mpg, .mpeg, .mp4	Video files are transcoded by Unity.
Other	Other File Formats	.xml, .txt	Text files are not converted.

Unity supports almost every file type that you would want to use in your own games.

GameObject Menu

The GameObject menu contains items that allow you to Create and Manipulate GameObjects.



Unity – GameObject Menu

A GameObject is something that exists in a Scene. At its most basic level, a GameObject consists of a 3D position and an orientation in the Scene. The GameObject‘s position and orientation in the Scene is also called its Transform.

On its own, a GameObject does not do much. You must attach some Asset (as a Component) to a GameObject for it to be useful. You can also link GameObjects together in a hierarchical fashion with a “parent-child” relationship and the “child” GameObjects will then be defined relative to its “parent” GameObject. A GameObject can only have one parent so it is not possible to have the same GameObject linked to multiple parents but something similar can be achieved using Prefabs (which I will discuss later).

The Component Menu

The Component menu lets you add Components to the currently selected GameObject.



Unity – Component Menu

A Component must be added to a GameObject because a Component cannot exists on its own. The Components that are added to a GameObject define its behavior.

Unity has many types of Components that serve different purposes.

• Mesh Component: used to render a 3D model at the location of the GameObject in the scene.
• Effect Component: allows you to create a particle effects, or special lens effects in your game.
• Physics Component: add physics to GameObjects so they can be physics controlled and able to interact with the player and other physics enabled GameObjects.
• Navigation Component (Pro Only): Components that utilize the pathfinding functionality in Unity. The NavMesh funcitonality is only available for Pro licenses.
• Audio Components: add sound effects to your game.
• Rendering Components: components that control graphics related functionality such as cameras and lights.
• Miscellaneous Components: Components that don’t fit in their own category.

You may see additional menu items in the Component menu if your project has any scripts which will be added to the menu when they are added to the project.

The Terrain Menu

The Terrain menu has commands for creating and manipulating terrains.



Unity – Terrain Menu

The Window Menu

The Window menu allows you to show and hide the different windows in the Unity editor. You can also change the current window layout or save a custom layout.



Unity – Window Menu

I will discuss the different windows in the following sections.

The Help Menu

The Help menu provides commands for accessing the documentation and also for registering your Unity version with a Pro license.



Unity – Help Menu

The Toolbar

The Toolbar contains a minimal set of tools that are required to interact with the Scene and to manipulate the GameObjects in the Scene.



Unity – Toolbar

Transform Tools

The Transform tools are probably the most common tool you’ll be using to interact with the Scene view and to manipulate the positions and orientations of the GameObjects. However, once you learn the shortcut keys, you probably won’t use this tool directly very much.

View Manipulation

The first (left-most) button on this tool is the scene view manipulator and its functionality is dependent on whether you are pressing the Alt key (Command key on Mac) on the keyboard. Pressing Q on the keyboard will switch to the view manipulation mode in the scene.

• – (LMB) The Pan View button allows you to pan the scene view using the Left Mouse Button (LMB). This option can also be accessed with the Middle Mouse Button (MMB)
• – (Alt+LMB) The Rotate View allows you to rotate the scene view around the view pivot. This option can can be accessed by holding the Alt key on the keyboard and dragging in the Scene view with the Left Mouse Button (Alt+LMB).
• – (Alt+RMB) The Zoom View allows you to zoom in or out. This option is accessed by holding the Alt key on the keyboard while dragging with the Right Mouse Button (Alt+RMB).

GameObject Manipulation

You can transform GameObjects using the Move, Rotate, and Scale tools.

• – (W) The Move button allows you to manipulate the translation of the currently selected GameObject. The shortcut key for this tool is the W key.
• – (E) The Rotate button allows you to manipulate the orientation of the currently selected game object. The shortcut key for the rotate tool is the E key.
• – (R) The Scale button allows you to manipulate the scale of the currently selected GameObject. The shortcut key for scaling an object is the R key.



Unity – Transform Gizmo

The Transform Gizmo shown in the image above allows you to constrain the translation, rotation, and scale to a particular axis or axes.

Clicking on the Red gizmo handle allows you to constrain the manipulation in the X-axis.
Clicking on the Green gizmo handle allows you to constrain the manipulation in the Y-axis.
Clicking on the Blue gizmo handle allows you to constrain the manipulation in the Z-axis.

When using the Translate Gizmo, you can press the Shift key on the keyboard to constrain the movement to the View plane (motion is constrained to the virtual plane represented by the screen).

Gizmo Tools

The Transform Gizmo manipulation tools allow you to specify how the gizmo behaves.



Unity – Gizmo Tool

Pivot

You can specify that the Transform Gizmo should be relative to the GameObject’s pivot point. In this case, any transforms that you apply to the GameObject (or selected GameObjects) will be relative to that object’s pivot point.



Unity – Gizmo (Pivot, Global)

The image above shows that the Transform Gizmo is anchored to the currently selected GameObject’s pivot point. When selecting multiple GameObjects, the pivot point will be anchored to the GameObject that was selected first.

Center

You can also specify that the Transform Gizmo should be relative to the GameObject’s center point. This may be different than the pivot point of the GameObject if the GameObject is parented to another GameObject in the scene Hierarchy or if it contains a model (or mesh) that does not have it’s pivot centered in the model.



Unity – Gizmo (Center, Global)

The image above shows that the Transform Gizmo is centered relative to all the currently selected game objects. Any rotations applied to the selected GameObjects will be relative to the center point of all of the currently selected GameObjects.

Global

With Global selected in the Gizmo tool, translations and rotations will be applied in the global reference frame (that is, the global X-, Y-, and Z-axes). In this case the GameObject’s orientation will be ignored when using the Transform Gizmo to translate or rotate the GameObject.

Scaling a GameObject will always be applied in the GameObject’s Local space. Otherwise the GameObject might become skewed which is usually undesirable.



Unity – Gizmo (Global)

You can see from the image above that the Transform Gizmo is still aligned to the Global Axis even after the GameObject has been rotated.

Local

With Local selected in the Gizmo tool, translations and rotations will be applied in the GameObject’s local reference frame. In this case, the GameObject’s current orientation will be taken into consideration when transforming the GameObject using the Transform Gizmo.



Unity – Gizmo (Local)

Game Player Controls

The Game Player controls allow you to play the game directly in the editor.



Unity – Game Player Controls (Play, Pause, Step)

The Game Player controls will turn blue when the game is currently running.

• Play: Start/Stop the game play in the Game Window.
• Pause: Pauses the currently playing game. If the game is not playing, it will be started in the “Pause” state when you press the “Play” button.
• Step: Step and Pause the game play. Successively hitting this button will run the game in a single-step iterations of the game loop.

The Layers Tool

Each GameObject can be assigned to a particular layer. By default, newly created GameObjects are created in the “Default” layer. The visibility of GameObjects in the Scene can be toggled on and off by selecting the layers in the layers visibility drop-down list.



Unity – Layer Visibility

The Layout Tool

The Layout drop-down list can be used to quickly set your workspace to a predefined layout.



Unity – Layout Tool

The Layout drop-down list also lets you save your current layout if you have made any changes to one of the default layouts. Saving your current layout allows you to create a set of layouts that you commonly like to use.

The Editor Windows

The Unity Editor currently has ten different windows that can be used to view different aspects of your game project. By default, the Scene, Game, Hierachy, Project, and Inspector views are visible. In this section, I will discuss each view and it’s uses.

The Scene View

The Scene View (Ctrl+1) is used to position and orientate the GameObjects in the scene. Some components provide additional handles you can manipulate in the scene view when holding the Shift key on the keyboard.



Unity – Scene View

Navigating the Scene View

There are multiple ways to navigate the scene view.

Arrow Keys

If the Scene views have focus, you can use the arrow keys on the keyboard to fly through the level. The Up/Down arrow keys will move the camera forward and backward relative to the direction the view. The Left/Right keys will pan the view left and right respectively.

You can use the Shift key to double the movement speed.

Flythrough Mode

Holding down the Right Mouse Button (RMB) in the Scene view will allow you to Flythrough the scene using familiar FPS controls. In this mode, you can use the WASD keys on the keyboard to move forward, left, back, and right (respectively). Using the Q and E keys you can fly down and up (respectively).

You can use the Shift in this mode as well to double the movement speed.

Zoom to Selected

Selecting a GameObject in either the Scene view or the Hierarchy will allow you to quickly zoom to that GameObject in the Scene view by pressing the F key on the keyboard while the mouse is over the Scene view. The Scene view will zoom to the GameObject (and all of it’s children) centered in the view. This will also center the camera orbit on the GameObject.

The Scene Gizmo

You can use the Scene Gizmo to orient the current scene view.



Unity – Scene Gizmo

Clicking on any of the axis on the gizmo will snap the view to that orientation. Clicking in the center of the gizmo will go back to Perspective view.



Unity – Scene View

Shift-Click on the middle of the Scene Gizmo to toggle between Perspective view and Isometric view.



Unity – Perspective vs Iso

Draw Mode

You can change the way the scene is viewed using the Draw Mode drop-down box.



Unity – Draw Mode

Textured Draw Mode

The Textured draw mode allows you to see the scene with all of the models textured.



Unity – Scene View (Textured)

Wireframe Draw Mode

In Wireframe draw mode, all of the meshes are drawn using their wireframe representation.



Unity – Wireframe View

Tex – Wire Draw Mode

In Tex – Wire draw mode, you see the textured models with their wireframe representation drawn on top of them.



Unity – Tex – Wire

Render Paths Draw Mode

In Render Paths draw mode, each object is shaded based on the rendering path used to render the object.

• Green – Deferred Rendering.
• Yellow – Forward Rendering.
• Red – Vertex-Lit Rendering.



Unity – Render Paths

Lightmap Resolution Draw Mode

The Lightmap Resolution draw mode shows the textured objects with an overlay of a checkered grid which represents the resolution of the lightmaps for each object.



Unity – Lightmap Resolution

Light Probes Draw Mode

With the Light Probes draw mode selected, you can visualize which light probes will effect the currently selected object.

Note: The AngryBots sample project does not use light probes so selecting this view mode with the AngryBots scene does not look any different than the Textured view mode.

Render Mode

The Render Mode drop-down box allows you to select the current render mode for the scene.



Unity – Render Mode

RGB Render Mode

The default mode is RGB render mode. In this render mode, object are rendered normally.



Unity – RGB Render Mode

Alpha Render Mode

The Alpha render mode displays the alpha value of the objects texture or material. This does not mean that objects that are drawn black in this render mode will be transparent. They must have a transparent material applied on them in order to be rendered in the transparency pass.



Unity – Alpha Render Mode

Overdraw Render Mode

In Overdraw render mode you can see where objects are drawn over top of other objects. Darker areas have less overdraw where brighter areas indicate overdraw.

Excessive overdraw could result in poor rendering performance but is sometimes unavoidable.



Unity – Overdraw Render Mode

Mipmaps Render Mode

In Mipmaps render mode you can visualize ideal texture sizes using a color code.

• Red: The texture is larger than necessary.
• Blue: The texture could be larger.

Keep in mind that the resulting colors is dependent on the current resolution of the screen and the distance the camera is away from the objects. Generally, you should see objects turning blue when you move the camera close to them and objects that are far away will generally be red. Unity will automatically generate mipmaps for your textures when they are imported.



Unity – Mipmaps Render Mode

Scene Mode Controls

The Scene Mode controls allow you to enable or disable different aspects of the scene view.



Unity – Scene Mode Controls

• Scene Lighting: Toggle the game lighting or the scene default lighting.
• Game Overlay: Toggle the display of Skyboxes and GUI Elements in the Scene view.
• Audition Mode: Toggles playing of audio sources in the scene view.

Search Filter

You can use the object search filter on the top-right side of the Scene view to quickly isolate specific game objects.



Unity – Search Filter

In this case, I filter on objects with the name “Player”. The search filter is capable of filtering using partial names so both the “Player” GameObjects are isolated and the “PlayerSlideDoor” GameObjects are also isolated in the scene view.

The Game View

The Game View (Ctrl+2) allows you to see how the game will look during production.



Unity – Game View

On the top of the window, you will see the Aspect drop-down menu, the Maximize on Play toggle button, the Stats toggle button, and the Gizmos toggle.

• Aspect: The Aspect drop-down menu allows you to force the aspect ratio of the Game View so that you can see how your game will play at different aspect ratios.
• Maximize on Play: This toggle button will cause the Game View to maximize to 100% of the editor window.
• Stats: The Stats toggle button will toggle the display of the performance statistics.
• Gizoms: Pressing this button will allow you to visualize the Gizmos that are usually only drawn in the Scene view.



Unity – Game View (Stats On)

The Inspector View

The Inspector View (Ctrl+3) shows you the properties of the currently selected GameObject and all of it’s Components.



Unity – Inspector View

One component that is common to all GameObjects is the Transform component. You will never see a GameObject without this component and it is impossible to remove the Transform component from a GameObject.

We will use the Inspector view more when I discuss Components and game scripting.

The Hierarchy View

The Hierarchy View (Ctrl+4) shows all of the GameObjects in your scene. You can either select a GameObject directly from the Scene View or you can use the Hierarchy view to select a GameObject that exists in your scene.



Unity – Hierarchy View

Using the (create new GameObject) you can quickly add a new GameObject to the scene based on one of the GameObject templates provided.

The Project View

The Project View (Ctrl+5) is a direct reflection of the Asset folder in your game’s root folder on your file system.



Unity – Project View

In the Project View, you can use the to add a new asset type to your game assets.

I will discuss the project view in more detail when we create a new project from scratch.

The Animation View

The Animation View (Ctrl+6) allows you to create and modify Animation clips on the currently selected GameObject.



Unity – Animation View

I will discuss how to use the Animation view in a future article.

The Profiler View (Pro Only)

The Profiler View (Ctrl+7) allows you to profile and optimize certain aspects of your game.



Unity – Profiler View

The Profiler View is only available in the pro version of Unity.

The Particle Effect View

The Particle Effect View (Ctrl+8) is used to manipulate particle effects.



Unity – Particle Effects View

I will discuss creating particle effects in another article.

The Asset Store View

You can use the Asset Store View to download plug-ins and content that can be used in your Unity project.



Unity – Asset Store

The Asset Store has a lot of free and paid plug-ins and game content.

The Asset Server View (Team License)

The Asset Server View requires the Asset server license or a Team License to access it. The Asset Server (Ctrl-0) is a content versioning system that makes it easier to share code when working in large teams.

Other Windows

There are several other windows that you can also access from the Window menu.

Lightmapping

The Lightmapping view allows you to access the lightmapping settings and controls for the current scene. Lightmapping is used to apply a pre-rendered version of the lighting contributions to static objects in the scene.

Both the free version and the pro version of Unity allow you to access the Lightmapping view, the pro version has a lot of extra settings that cannot be accessed in the free version.



Unity – Lightmappig View

I will discuss Lightmapping in more detail in another article.

Occlusion Culling (Pro Only)

The Occlusion Culling View allows you to specify parameters to generate the occlusion data. You can bake the occlusion data as a pre-process step. This allows Unity to optimize the visibility determination of GameObjects and reduce the chance that occluded objects are rendered.



Unity – Occlusion Culling

Navigation (Pro Only)

The Navigation View allows you to generate navigation information for use by the game AI.



Unity – Navigation View

Creating Your First Project

Now that we have a good understanding of all of the different parts of the Unity Editor, let’s put that knowledge to good use by creating our first project.

Open the Unity Editor if it is not open already. By default, Unity will open the last opened project project automatically. If this is the first time using Unity, the Unity – Project Wizard dialog will appear.

If you are working with multiple Unity projects, you may want to show the Project Wizard every time you open the Unity Editor. To change this behavior, choose Edit -> Preferences… from the main menu.



Unity – Editor Preferences

Check the “Always Show Project Wizard” option to show the Project Wizard when you open the Unity Editor instead of automatically opening the previously opened project.

If the Project Wizard dialog did not appear, select File -> New Project… from the main menu.

Select the “Create New Project” tab.



Unity – Project Wizard

Choose a location for your project. This will become the root directory for your project.

Select any standard packages that you want to include in your project. If you have a pro license, you may see more packages marked (Pro Only). You can include these packages in your project but some of the features used in those packages will be unavailable to people using the free version of Unity.

Don’t worry if you don’t select any of the standard packages when you create your new project. You will be able to add any of the standard packages to your project at any time by selecting Assets -> Import Package from the main menu.

Click the Create button to create a new project.

Your new project should appear in the Unity editor with an untitled scene. There should be only the Main Camera GameObject in your scene.



Unity – New Project

Adding Some Content

For this tutorial, we’ll just add a rotating cube to the scene. I will introduce more complicated topics in later articles.

Select GameObject -> Create Other -> Cube from the main menu.



Unity – Create Cube

A new GameObject with the name “Cube” will be created in the center of the view.



Unity – New Cube

We also want to make sure the Main Camera GameObject is aiming at the Cube. To do this, select the “Main Camera” GameObject and position and rotate it so that it is pointing at the Cube.

This can be done quickly by selecting the Cube GameObject in either the Scene or the Hierarchy views and pressing the “F” (focus view) key on the keyboard while the mouse cursor is in the Scene view. With the Scene view now focused on the cube, select the Main Camera in the Hierarchy view and select “GameObject -> Align With View (Ctrl+Shift+F)” from the main menu.

You should see something similar to what is shown below.



Unity – Focus Cube

If you play the game now by pressing the “Play” button, you will see a pretty boring silhouette of a cube. Maybe it will look better with a little bit of lighting?

Adding a Light

Let’s add a light to the scene so we can see that our cube has some depth.

Select either “GameObject -> Create Other -> Directional Light” from the main menu or use the “Create -> Directional Light” drop-down box in the Hierarchy view to create a new GameObject with a directional Light component.



Unity – Scene with Directional Light

Parenting GameObjects

The position of a directional light doesn’t have any influence on how a object is lit but its direction is important. I want to have the light always pointing in the same direction as the Main Camera so that whatever it is I’m looking at will be lit consistently across it’s faces and I’ll never look at the dark side of the object.

In the Hierarchy view, use the mouse button to (left-)click and drag the Directional Light GameObject and drop it on top of the Main Camera GameObject.



Unity – Parenting Game Objects

Doing this will cause the Directional Light GameObject to inherit its position and orientation to be relative to the Main Camera GameObject.

You may notice, that parenting a GameObject to another does not change its position or orientation in the scene view. Unity will modify the parented GameObject’s local position and orientation so that it remains in it’s initial position. However, if we move the Main Camera GameObject, the Directional Light will be moved along with it.

Parenting one GameObject to another is good way to group many GameObjects together that have a commonality. It is not uncommon to create an empty GameObject (a GameObject with no Components) where its only purpose is to act as a parent to all the GameObjects in a group.

Since we want the Directional Light to always point in the same direction as the Main Camera and we’ve parented the light to the camera, we can simply set the Directional Light‘s local position and orientation to 0.

Select the Directional Light in the Hierarchy view and set its X, Y, and Z Position properties to 0 and its X, Y, Z Rotation properties to 0. Leave the X, Y, and Z Scale properties at 1.



Unity – Directional Light (Zero Transforms)

To confirm that the light is pointing in the same direction as the Main Camera, select the Main Camera GameObject from the Hierarchy view and press the “F” (focus view) key while the mouse cursor is over the Scene view. The Scene view should zoom out so that both the Main Camera and the Directional Light are in view. Use the Alt+LMB combination to rotate the Scene view.



Unity – Directional Light Aligned to Main Camera

As you can see from the image, the light rays coming from the Directional Light GameObject are pointing in the same direction as the Main Camera.

Pressing “Play” now should show a cube that is lit by the directional light.

Make it Spin

Now let’s add some action! We’re going to make the cube spin slowly.

In the Project view, create a new folder called Scripts (Either right-click in the Project view and select Create -> Folder from the pop-up menu that appears, or select “Folder” from the Create drop-down menu at the top of the Project view). Rename the new folder to “Scripts” by (single) left-clicking on the new folder in the Project view or press “F2” on the keyboard while the new folder is selected in the Project view.

Right-click on the Scripts folder and select “Create -> JavaScript” from the pop-up menu that appears.

Rename the new JavaScript file to “Rotation“.

If you now open Windows Explorer and navigate to the folder where your project exists, you will notice that the Assets folder mirrors the file structure of the Project view. The Project view is the same as the files contained in the Asset folder in your project’s root folder. Any changes made to files in the Project view will be directly reflected on your computers file system.

Open the JavaScript asset in the script editor by double-clicking on the Script asset in the Project view. (Unity comes with the MonoDevelop editor for editing script assets).



Unity – MonoDevelop

Copy-Paste the following code into the Rotation.js file.

#pragma strict

function Update () {
	transform.Rotate( Vector3.up * ( 90 * Time.deltaTime ) ); 
}

Save the file and return to the Unity Editor.

Now drag and drop the Rotation script asset from the Project view onto the Cube GameObject in the Hierarchy view. Unity will automatically create a Script component on the Cube GameObject and assign the Rotation script asset as the script source for the component.

You should see something similar to what is shown in the image below.



Unity – My Cube

Notice in the Inspector view that the Cube GameObject now has the Rotation script component assigned to it.

If you play the game now, you should see something similar to what is shown below.

Adding Your Projects to Version Control

In this section I will discuss how to add your Unity project to a version control system (VCS). This is an optional step and is only required if you will be working together on the same project with other people or if you just want to save your project files in a version control repository for safe keeping.

I will not explain how to use the VCS. Whether you use Subversion, Git, Perforce, SourceSafe is not really important but knowing how to convert your project to use a Version Control System and what files need to be added to the VCS is important.

Enable Meta File Mode

The Unity Editor keeps track of the Assets (files) and the Asset import settings in the Asset database file. The asset database file is stored in the Library folder of the project Root. It is generally not a good idea to distribute this file together with your project because the format of the file is platform specific (it may not be able to be opened properly on other OS’s other than the one it was created on).

To solve this problem, you can specify that you want to generate Meta Files for every single file, and directory in your project’s Asset folder.

To turn on Meta File Mode for your project, select “Edit -> Project Settings -> Editor” from the main menu.



Unity – Edit Project Settings

The Editor Settings will open in the Inspector view.



Unity – Enable Meta Files

Select “Meta Files” in the Version Control Mode drop-down menu.

This will create a “.meta” file for every file and folder in your project’s Asset folder.

It is extremely important that if you copy/rename/move or delete a file or directory anywhere in the Assets folder that you also copy/rename/move or delete the .meta file with the same name. Failing to do this will break your project and all of your team members will become very angry with you!

Adding to Version Control

Once you have enabled Meta File Mode on your project then you need to add the following folders to your version control system:

• Assets: Add the Assets folder and every single file and corresponding .meta file in the Assets folder into your version control system.
• ProjectSettings: Add the ProjectSettings folder and all of its contents to your version control system.

With the .meta files in place, Unity can rebuild the asset database and automatically re-import all of the raw assets in the Assets folder without losing references to files.

You do not need to commit the .sln (Visual Studio Solution files) or the .unityproj (MonoDevelop project files) as Unity is capable of regenerating these files based on the content of your Assets folder.

More Information

As a beginner, it may be difficult to get started with Unity because there is just so much to learn and there is so much information to absorb, you may not know where to begin. The Unity website http://unity3d.com contains several links on the header but you will most likely want to see the documentation.

The main resource for Unity documentation is http://unity3d.com/support/documentation/.

For a beginner, I recommend you first read the Basics: http://docs.unity3d.com/Documentation/Manual/UnityBasics.html.

With a good understanding of the basics, I recommend you watch a few video tutorials here: http://unity3d.com/support/documentation/video/ and then work through a few of the larger tutorials here: http://unity3d.com/support/resources/tutorials/

While you are working on your projects, you will very often refer to the Unity Manual http://docs.unity3d.com/Documentation/Manual/index.html, the Reference Manual http://docs.unity3d.com/Documentation/Components/index.html and the Scripting Reference http://docs.unity3d.com/Documentation/ScriptReference/index.html.

These three resources (User Manual, Component Reference, and Scripting Reference) are also installed on your computer locally when you install Unity and are accessible from within the editor using the Help menu.

Additionally, you can click the (Component Reference) button on any component in the Inspector view to go to that component’s reference documentation.

I wish you the best of luck creating that next block-buster title!

]]> http://3dgep.com/?feed=rss2&p=3246 3