Cameras! Such an important part of almost any game. However, making the perfect camera system
from scratch can get complicated… so let’s not and instead use Unity’s feature-rich
package Cinemachine to make setting up our game’s camera systems so much easier. Today’s video is an introduction for how
to use Cinemachine brought to you by the iHeartGameDev Patrons! Now, let’s get started! The Cinemachine package is designed to minimize
the amount of work needed to make complex camera systems in practically all genres of
games. If you’re here, you probably knew this and
want to learn how to use this package. So to begin today’s project, we have set
up a test environment and added the Jammo character prefab from the hit youtube channel
mix and jam. Let’s begin to explore Cinemachine by adding
a single camera to the hierarchy by right clicking and selecting “Camera”. We’ll retitle it to “MainCamera”. This is Unity’s built-in camera and it’s
necessary when working with the many features that Cinemachine has to offer. Next we’ll go ahead and install the Cinemachine
package. All we need to do is open the package manager,
filter by Unity Registry, and then find and install Cinemachine. Ok! With Cinemachine installed and imported into
the project, let’s talk about how it works. Cinemachine has many features, but there are
two core pieces to the Cinemachine puzzle that we should know and understand from the
start: the cinemachine brain and virtual cameras. For today, we’ll get a quick overview of
both but fully explore the Cinemachine Brain. The cinemachine brain is a component that
we attach to the camera in our scene. Selecting our “MainCamera” in the hierarchy
and pressing on “component” in the inspector, we’ll search for “brain” to find and
select the cinemachine brain component. This brain component essentially takes control
of the camera it is attached to and overrides its properties with new values. But we might ask: what values does the brain
use to override the camera’s properties? Where are these values coming from? The answer is Virtual cameras. A virtual camera is another component that
we attach to a game object in our hierarchy and in the scene. So, if we right click in our hierarchy and
add an empty game object named “VirtualCameraOne” and then search components for “virtual
camera”, we’ll see and select the cinemachine virtual camera component. Notice that after adding this component, the
“Game” window will snap to a new position and view. This is how the cinemachine brain and virtual
camera tie together: the brain will automatically keep track of virtual cameras in the scene. And it will use a single active virtual camera’s
values, to replace the values of the Unity Camera that the brain is attached to. In this case, “MainCamera’s” values
are now automatically being overridden by “VirtualCameraOne’s”. And if we look at the brain, we can see that
the first property “Live Camera” is now automatically set to “VirtualCameraOne”. What we may find interesting, is that certain
properties of the Unity camera component are now unchangeable from the “MainCamera”
and instead need to be modified on the virtual camera instead. The brain has taken over! Let’s take a look through the rest of the
brain’s properties as it will help us get a better grasp of what Cinemachine is all
about and more comfortable with both of these core components. Looking at the brain’s list of properties:
below the “Live Camera” property, we will see the “Live Blend”. Blending is one of the key features of Cinemachine
and part of what makes this package so versatile and useful. Most games have multiple camera angles, and
this is the case even in genres we may not expect. A first person shooter like Halo has a separate
camera when jumping into a warthog, a 3d sidescroller like Metroid Dread has event based cameras
when fighting off the EMMI, and even a simulator like animal crossing has separate cameras
when opening menus and talking to other villagers. Now, there are occasions where the cameras
will hard cut between one another. For another halo example: respawning. But often times we want a quick and smooth
transition from one camera angle to another. If we were to use two of Unity’s built-in
cameras, we could activate and deactivate the proper cameras to reproduce hardcutting. But in many instances we would actually want
that smooth transition. And while practically anything is possible
with the right code and effort, there is no clean way to smoothly transition between Unity’s
built in cameras. Queue Cinemachine! One of this packages main features is the
ability to smoothly transition, or blend, from one virtual camera to another! What this “live blend” property is for,
is to track which cameras are currently in the middle of a transition. Now the absolute simplest way to perform a
transition is to activate a new virtual camera from our hierarchy while the game is running. Worth noting for debugging purposes, blends
only work when in play mode. Let’s create a second virtual camera called
“VirtualCameraTwo”. We’ll quickly modify this camera to look
a little more interesting. And now, if we enter play mode and deactivate
VirtualCameraOne, we’ll watch as cinemachine blends to the next active camera: VirtualCameraTwo! We may notice that Virtual Camera One is still
the default camera. This has to do with the “Priority” property
on Virtual Cameras, but more on that in a future episode. Watching this property is a little difficult. Fortunately, the next property: “ShowDebugText”,
solves this issue. Checking this box we can now see the active
camera in the scene and when we activate a different virtual camera, the debug text even
shows the two cameras that are being blended and the percentage through the blend! The “Show Frustum” property is visible
in our editor window. In Unity, the camera’s frustum displays
a polygonal box from our camera’s point of view. Gizmos need to be activated, and opening and
closing the “Camera” component on our main camera will soft display the frustum
regardless of the checkbox. Gameobjects within this box will be rendered
and gameobjects outside of the box will not. The frustum’s size is controlled by the
clipping planes, field of view and dutch properties of the active virtual camera. Anything closer than the near clipping plane
or further than the far clipping plane will not be rendered by default. By modifying the field of view, the wider
or more narrow the frustum will become. And the Dutch full-on rotates the camera’s
perspective. The “Ignore Time Scale” checkbox does
exactly what it says. “Timescale” being the rate at which time
passes when the game is running, allows us to create slow, accelerated and stop motion
effects. However, because Cinemachine camera blending
is impacted by time by default, that means that if we were to create an awesome slow
motion effect, the camera would also move and blend in slow motion! But what if we don’t want that? Part of what makes slow motion more impactful
can be the camera moving at a normal speed, especially if we’re talking about an in-game
cinematic. Using the “Ignore Time Scale” property
will fix this problem and keep the camera movement independent of the current timescale. The “World Up Override” takes the transform
of the gameobject assigned to that property and uses its rotation to determine the Y Axis
for our cinemachine virtual cameras. The most frequently seen example of “World
Up Override” is when developing top-down games. Cinemachine virtual cameras are designed to
avoid inducing a nauseating “camera roll” as best as possible, however as we can see
here, camera roll quickly becomes an issue when our camera is positioned to look straight
up or down. So what we can do is create a new empty gameobject,
rotate the X axis by 90 degrees so that now the Y axis is parallel to the ground, and
set this gameobject to the “World Up Override” property. Now, according to Cinemachine, the camera
is no longer facing down when looking at Jammo, but forward! And the camera roll is now removed! The Update Method decides when the logic for
rotating and changing the position of virtual cameras should take place. The four options are Fixed, Late, Smart and
Manual Update. Fixed Update performs this logic during the
Physics system lifecycle, or the Fixed Update monobehavior method. We would want to use this if our player is
using physics based movement. Late Update performs the logic after all logic
of the monobehaviour Update method is called. Smart Update is pretty cool as it will attempt
to automatically detect which to use based on the movement of the gameobject it’s following. And Manual Update says “ok, perform the
logic through your own code”. This gives us the most control, but also no
assistance. The camera will no longer change even when
we deactivate the active camera. And to be clear, it’s important to use the
correct Update Method because the wrong one can cause Jitter camera movement. The “Blend Update Method” property is
similar to Update Method except we only have two options: Late Update or Fixed Update. The Cinemachine documentation recommends that
we use Late and we can switch to Fixed again only if there is jittery camera movement. Default Blend is where things start to get
a little more interesting. Each option for this property represents what’s
known as a Motion Curve or Bezier Curve. In the context of Cinemachine’s camera blending,
these curves are graphed normalized acceleration patterns where 0 is the first camera and 1
is the new camera on the Y axis and x is Time. essentially it determines how fast the cameras
will transition between one another at different points of the blend. Better understood through the examples, if
we set the default to cut, this is graph looks like a flat line at 1 on the Y axis, and therefore
switches directly to the new camera. Ease In Out will smoothly accelerate out of
the current camera and into the new one. Ease In is smooth into the new camera. Ease Out is smooth out of the current camera
and linear to the new. Hard In is smooth out of the current camera
and hard into the new one. Hard Out is hard out of the current and smooth
into the new one. Linear is the same speed the whole time! And then there is custom! With custom we have a selection of presets
that are actually represented by the other options we just mentioned, but we can also
create our own. And of course, the duration input is how long
in seconds the default camera blend should take. Now that was for the “Default” blend property,
but if we want different blends between specific cameras, we can use the “Custom Blends”
property. This requires a Custom Blend Asset, so we
can just press that button, create the asset, and once created place it into the reference
box. We can then press the plus button to create
a new custom blend, which allows us to select two different cameras as well as the same
“Style” and “duration” settings that were mentioned with the default property. Now when the first camera transitions to the
second, it will use these settings. The final two properties of the brain are
the Camera Cut Event and Camera Activated Event. What both of these properties can do is trigger
specific functions from our code that are found on the gameobject passed into the reference
boxes. The Camera Cut Event is fired when a camera
CUT transition takes place and exposes the Cinemachine Brain to all of the selected functions. And the Camera Activated Event exposes the
starting and ending cameras to the selected functions at the beginning of a blend. As always with code, sky is the limit for
what we can use these events for, but as a practical example, we may want to turn on
some game objects during a cinematic depending on what cameras are active. Now, that covers the Cinemachine brain: one
of the core components to the Cinemachine package. But as we know, we still need to learn all
of the properties of the Virtual Camera. And there are still so many amazing features
to Cinemachine that we haven’t even mentioned like the Track And Dolly, State Driven Cameras
and more! Awesome job today! I hope that cinemachine makes a little more
sense now than it did before. To vote on the next tutorial while supporting
this channel, please consider joining the iHeartGameDev patreon. And, of course, we need to thank all of the
current Patrons for believing in and helping make this channel happen. If you’re interested in joining a community
of awesome developers just like yourself, we’d love to have you in the iheartgamedev
channel discord. For updates on the next video, feel free to
follow me on twitter. But that’s all for today, thank you so much
for watching and I’ll see you in the next video.
