ubiqvisuals

Login Form




3D Action Adventure Kit Camera Documentation

Overview

While you may not realize it, the camera is one of the most important elements of any video game. It’s literally the only way you can see anything in the game. Big game companies put large amounts of resources into designing, coding, and polishing the camera to provide the player the best experience possible. Cameras allow designers the ability to show players what they want them to see, or how they want them to feel using camera movement and placement. This document will cover all the topics needed to understand how to control and design the camera system used in the 3D Action Adventure Kit.

Note: This documentation is specific to TGEA, not the newest T3D build. Most of the workflow is still relevant but specific lines of code called out or editor shortcut keys may no longer be relevant.

Camera Features Overview

The basic features of the cameras included in this kit are:

  • Camera Relative Controls
  • Simple trigger system for switching between camera modes
  • Smooth Transitions between camera modes
  • Animator controlled focal point
  • Free-Orbit Camera allows the user to look around using the mouse while controlling the character with the keyboard

3 Different Camera Modes Overview

Dynamic Player Camera
The Dynamic Player Camera is the standard camera best suited for open world exploration. Some of its main features include:

  • Intelligent occlusion solving, so the player is always in view
  • Collision avoidance, keeping the camera out of walls
  • Automatic pitch control for looking over edges and up hills
  • Free-Orbit Camera functionality

This camera acts as though it is on a leash following your player model. As you run forward the camera will follow behind. If you make a turn the camera will continue to follow you. If you turn around to run back to where you were coming from, the camera will stop and turn with you. This camera takes the least amount of effort to implement because it works very well in most situations automatically.

Constrained Axis Camera
The Constrained Axis Camera is the camera mode best suited for platforming. This camera will follow the player but keep itself locked to a specified position relative to the player. This will allow you to achieve a “2D” platforming camera. The designer has control to change the cameras angle and pitch any time they wish.

  • Exact control over camera’s orbit, pitch, or yaw
  • Exact control over the camera’s distance to player
  • Free-Orbit Camera functionality

Path Camera
The Path Camera is the camera best suited for tight corridors and can also provide a strong cinematic feel. This camera is implemented using Torques path system. The designer starts by laying out a path for which the player will travel, the designer then creates a corresponding path that the camera will follow. As the player moves along the player path, the camera will move along the camera path. This camera has the ability to look at the player the entire time, or the camera rotation can be designer controlled.

  • Camera follows player on a designer specified path
  • Designer controlled rotation, or automatic player tracking
  • Flexible system allows for many different cinematic effects

Free-Orbit Mode

While the Free-Orbit Camera is not a separate camera mode, it is a powerful feature of the Dynamic Player Camera and Constrained Axis Camera. This camera functionality allows the user to hold down the Right Mouse Button and have free-control over the camera’s orbit around the player. The Free Orbit Camera is not available if you are using the Path Camera Mode.

Camera Control using Triggers and Dynamic Fields

This next section discusses how to implement and control the three main camera modes. Let’s get started!

Cameras controlled by Triggers

The first thing we will discuss is how triggers control the different camera modes. When the player enters a trigger, the trigger will tell the code to enter into the specified camera mode. The camera mode is specified using information that is stored in the Trigger object’s attributes. The Trigger attributes can include information such as what camera mode to switch to, the pitch or yaw of the camera, or how long the transition between camera modes should take. Be sure to remember that the camera mode is switched when the player enters the trigger, not while they are inside the trigger.

For example, I may have my player jumping along the side of a cliff using a Constrained Axis Camera. Once the cliff jumping section is over, the player must run through a field. I would want the camera to switch to the Dynamic Player camera so that the camera follows behind the player instead of remaining Constrained to a particular axis. I would do this by placing a Dynamic Player Camera Trigger on the route between the cliff and the field. When the player runs through this trigger, the camera will smoothly transition between the Constrained Axis Camera to the Dynamic Player Camera and if designed correctly, the player should not even notice there was a shift in camera modes.

How do I create a Camera Trigger?

This is done the same way as creating any other trigger. To create a trigger in torque open the editor, enter World Creator mode (F4), then navigate to Mission Objects>Mission>Trigger (step 1 below)

Once you click to create the Trigger you will be prompted to create a trigger (step 2 below). Give your trigger an appropriate name, select the type of Camera you wish to use from the datablock drop down menu, and then click okay (Don’t worry, we will go into the different camera datablocks in the next section). You do not need to worry about the Polyhedron field. It’s best to just leave that as the default value.

Tip: The editor, by default, when it creates a new object will place the object on the nearest piece of ground or geometry that the center of the camera is looking at. Therefore, make sure you are looking at the ground whenever you create a new object. Otherwise the new object you create might spawn on the other side of the map! If you want to change this setting it can be found in the editor menu bar under World>Drop Location.

Once you click okay you should now see a small yellow box sitting on the ground. This yellow box is your new trigger! That’s all you need to do to get started with camera triggers. There are a few more camera mode specific trigger attributes to learn and we will be covering those in their respective sections.

sound_flow

Dynamic Fields

Before we go into the camera specifics we’ll need to quickly discuss Dynamic Fields. Dynamic Fields are properties that the level designer adds to each trigger to give it unique properties.

For example: a property I could add to the Path Camera would be to always look directly at the player. This would be done by creating a Ddynamic Field with the label lookAtPlayer and the value set to 1. (1 means on, and 0 means off).

To create a Dynamic Ffield, select your trigger and go to the inspector to view its attributes (F3). Scroll down to the very bottom and you will see the Dynamic Fields section. Click on the green plus symbol (step 1 below). This will create a new Dynamic Field with some default values (step 2). The text box on the left is the Dynamic Field label (or property that you are modifying), the text box on the right is what the value of that property you wish to set. What you will want to do is erase these default values and put in your own values. For the example above, you would put lookAtPlayer in the left text box, and 1 in the right text box (step 3). Make sure after you input these that you press Apply (step 4).

Tip: If you want to remove a Dynamic Field, just click on the red minus symbol that is located beside your Dynamic Field and this will delete it.

Dynamic Player Camera Trigger Implementation

Now that we’ve covered how to create Camera Triggers and Dynamic Fields, let’s get more specific about how to implement the different types of cameras.

The type of Trigger datablock to use if you want to switch to the Dynamic Player Camera is the CameraTrigger_Player datablock. When creating the trigger (step 2 above) you would select CameraTrigger_Player from the dropdown menu. Anytime the player enters this Trigger the camera will switch into the Dynamic Player Camera. The only Dynamic Field you will need to adjust for the Dynamic Player Camera is the time Attribute. The time attribute controls the length of time the camera will transition from its previous camera position into the new camera position. Time is measured in milliseconds so if you want the camera transition to last for 2 seconds, you’d need to put “2000” into the dynamic field properties.

add_trigger

Constrained Axis Camera Trigger Implementation

The Constrained Axis Camera is essentially a modified Dynamic Player Camera, and therefore we will use the same datablock as the Dynamic Player Camera: CameraTrigger_Player.

The big changes that make this camera so powerful are the abilities to control the pitch, yaw, and camera distance. These attributes will really allow the designer full control of what the player sees and how they move through your level. It can also be used to help give players hints by "steering" them to look at certain areas.

Once again, these attributes are controlled by the following Dynamic Fields:

forcedYaw controls the left to right rotation of the camera. If this attribute is set, it will always look at your player from the specified angle. The forcedYaw attribute uses radians and ranges from 0 to 2p (0 – 6.28) and is relative to world coordinates. You may need to try a few values to find the correct angle.

forcedPitch controls the up/down rotation of the camera. If this attribute is set, it will rotate the camera up above or down below the player to look at them. The forcedPitch attribute ranges from -1.5 to 1.5. If the forcedPitch is set to -1.5 the camera will be directly below the player looking up. If it is set to 0.0, the camera will be exactly horizontal with the player. If it is set to 1.5 the camera will be looking straight down above the players head.

forcedRadius controls the distance the camera is away from the player. Think of this as if the camera is on a stick. One end of the stick is touching the player, the other end has the camera on it. The forcedRadius is the length of that stick. The forcedRadius attribute ranges from 0 to infinite, though anything more than 20 and you’re going to be pretty far away from the player.

time, as explained previously, controls the amount of time this camera transitions from the previous camera position, to the current one.

Example: Let’s say the current Constrained Axis Camera settings for our player are forcedPitch .4 and forcedRadius 7 (see image below). If the player is moving along a ledge and I want to give them a better view of what is below, I could simply create a camera trigger along the ledge that has a forcedPitch value of 0.8, a time value of 4000, and a forcedRadius value of 10. What this does, is that as the player is moving along the ledge, when they enter this new camera trigger, the camera will perform a nice and slow 4 second transition from previous camera to a view that is looking down on the character and zoomed out slightly to give more room to see below.

Path Camera Path Setup

The Path Camera works very differently from the two previous camera modes mentioned. The Path Camera works as if the camera is on a fixed track and it dolly’s along the track depending on where the player is. Before we talk about the trigger properties for this, we need to learn how to create paths.

How to Create a Path

In Torque, creating paths is very simple. The steps outlined below should have you creating your very own paths in no time.

  1. To start, hit F4 to go into Creator mode (while you are in the editor). Navigate to Mission Objects>Mission>Path. Click on Path.
  2. This will bring up a new window. Give your path a useful name and click okay.
  3. Before you do anything else, select the Path from your Mission Inspector and hit F3 to modify its properties.
    1. For creating paths specifically for the Path Camera, make sure you uncheck isLooping.
    2. You will also notice a new color property. To make things easier we allow the users to color code their paths. The four numbers in this field represent Red Green Blue Alpha. Therefore if you leave the path values of 0 0 0 1, the path will be displayed as black. If you change the values to 0 0 1 1, the path will be blue.
    3. It is important that you change these path settings before you move forward because once you start adding path markers into this path, the editor will no longer allow you to modify these path properties and you will have to do so manually by opening up the mission file in a text editor.
  4. Great! Now that we have created the Path group, we need to add path markers. The path markers are the points the make up the path. To create a path marker navigate to Mission Objects>Mission>Path Marker. Click on Path Marker.
  5. This will bring up a new window. Give your first Path Marker a useful name and click okay.
  6. You will now see in the editor that you have your Path (which has a black infinity icon beside it) and you have your first marker, represented by a green arrow icon. If you look at the properties of the Path Marker you will want to understand:
    1. seqNum: this defines what order the nodes will connect in. If seqNum is set to 1, that means it is the first node in the path. seqNum 2 would be the second node in your path, etc. If you add new nodes into the middle of your path you may have to adjust this attribute to correct the order that your path markers connect, otherwise you may get some funny jittering behavior of the path trying to resolve itself.
    2. SmoothingType: This one is very straight forward. If you choose Spline you will get nice smooth curves between your path markers. If you choose Linear you will have no smoothing and the path will be all straight lines.
  7. Now that we understand both Paths and Path markers, we need to associate them together to complete our Path. To do this, click and drag the Path Marker from the Mission Inspector list and drop it onto the Path that you just created. You will see that the Path icon turns into a folder icon and inside this folder is your Path Marker.
  8. Repeat steps 4-7 to create a second Path Marker. When you drag it into the Path folder along with the first Path Marker, you will see in the editor that you now have your two Path Markers connected by a line with arrows on it. Congratulations! You’ve made your first path. Continue this process to make the path as long as you wish.
    1. You will notice the arrows on your Path don’t necessarily point in the direction your Path is moving. This is because the direction each Path Marker is facing is independent and can be rotated manually.

Path Camera - Trigger Implementation

The Path Camera Trigger is implemented the same way as the previous cameras but with a few modifications. The trigger datablock that must be used is CameraTrigger_Path. The Dynamic Fields that can be used for the Path Camera are:

  • playerPath - specifies which path will be used as the player position reference path. This path will be the one on the ground the player runs along. The value it accepts is the name that you’ve given the path.
  • cameraPath - specifies which path will be used as the camera path. This path will be the one in the air that follows along with the player path. The value it accepts is the name that you’ve given the path.
  • lookAtPlayer - specifies if the camera should keep the player in the center of the screen at all times or not. If this field is set to 1, the camera will always look at the player. If this field is set to 0, the camera will look in the direction that the camera Path Markers are facing.
  • time - as explained above, controls the amount of time this camera transitions from the previous camera position, to the current one.

Path Camera - Path Implementation

Now that we understand how to create paths and how to hook them up using the Path Camera Trigger, we can start creating paths for the Path Camera. The Path Camera is implemented using 2 separate paths. The first path is used to mark the path that the player is running along. The second path is the corresponding path used as a track that the camera moves along.

For example, let’s create a path with 3 nodes along the ground. We’ll call this path player_path (shown in black below). Let’s now create another path with 3 nodes but we’ll create this path in the air above the player_path. We’ll call this new path camera_path (shown in blue). When the player is standing at the first Path Marker of the player_path, the camera will be located on the first Path Marker of the camera_path. As the player runs along the player_path towards the second Path Marker, the camera will follow along on the camera_path. When the player reaches the second node on the player_path, the camera will also be at the second node on the camera_path. The camera is always in the relative positiong on the camera path, to where the player is on the player path.

path_cam_diagram

Closest Point Warning
The Path Camera works by drawing an invisible line between the player, and the player path. Whatever the shortest distance from the player to the player path is where on the path the player will be, and respectfully the camera will also be. If you have sharp 90° or 180° turn in your player path and your player cuts across the path, you will observe that the camera will perform a quick move to “catch up” to where the player is on the path. This is something that the designer will have to be aware of and make sure to safe guard against. Some strategies to design around this is to only implement path cameras in tight corridors (such as a hallway or cave system) where the player cannot explore off of the path too far or cut across to other parts of the path. If you wish to have sharp turns, make sure that you have a piece of geometry that blocks the character from cutting across the path corners. This could be something such as a pillar, or table. Another method is to hide the player path inside the walls themselves.

No Orbit-Camera for Path Camera
One design limitation for the Path Camera is that the Orbit Camera Functionality is not available.

CameraTrigger_Reset

The last camera trigger that we will discuss is the CameraTrigger_Reset. When the player leaves this trigger, the camera will automatically switch back to the default Dynamic Player Camera. This allows you to surround your whole play area with this camera, and if somehow the player ends up somewhere they aren’t supposed to be, at least their camera switches back to the default camera so they are still able to run around and not have the camera stuck in a certain mode.

This trigger is implemented by selecting the CameraTrigger_Reset datablock when you create the trigger.

Ignore Camera

One final item to be covered before we wrap things up, is the new ignoreCamera attribute that you will now find inside every object’s attribute list. What this setting allows you to do is turn off the geometry detection on any object you would like. For example, you may have your character running along on a path and the player passes behind a tree. Instead of having the camera jarringly zoom in so that the tree does not block the player from the camera, you can turn on the IgnoreCamera attribute for the tree. This will allow the character to pass behind the tree and the camera will follow along as if the tree wasn’t even there.

All Done!

After reading this document you should have a strong understanding of how to design and control the various camera modes. Be sure to look adn see how we have implemented the different camera modes in our demo level, which is included with the kit. One of the biggest reasons we created this demo level was as an example for others to learn from. If you have any further questions, please direct them to the ubiqvisuals.com support forums. For additional camera tips please refer to our Level Design Documentation.