First Person Character Setup

Choosing the right setup

Deciding how to setup your character is not trivial. It can greatly affect where the production workload of animations lie, and how much dependency is tied to the games animation controller. If you're just starting a new project you should answer a couple of questions before you decide on your First Person Character setup:

How will we interact with the world?

Who is viewing the character?

Do we want to see our legs when looking down?

Here are some pointers on how I would approach first person setup. Based on my research of popular FPS titles, and my experience working on Outpost: Glacier and other Personal projects.

Things to consider before you start

How will we interact with the world?

There are a lot of tricks used to make first person models look good behave consistently. If we stick a model in front of the camera it can easily start looking distorted and elongated. These is not a visual error, it's just how cameras work in game. 

When doing first person games. A lot of the work is bridging our first person character with the surrounding world. While maintaining a good and consistent look during gameplay. In first person games many different techniques are involved to deliver a better looking experience, things you might not think of seeing it with a naked eye.

These methods often introduce another challenge. Having the first person models interact with the models of the static game world. Like pulling levers and picking up items. This is one of the reasons we rarely see first person interact animations.

If you are going for a purely first person approach, consider simplifying world interactions to have minimal contact points. Instead of a lever, use a button. That way, a fast animation that looks like it's almost pressing a button can be a lot less simpler than bridging the view model with our world models. 

Another approach could be to switch our view mode. Instead of handling the interaction in first person. We could instead use our world person to handle any interaction animations. In a multiplayer game that already needs world person animations, as this could effectively halve your work.

Who is viewing the character?

First person animations need to look good from one perspective. The player camera view. This means you can make poses and animations that would look unnatural from an onlooker perspective. If a weapon or character type is only visible from first person view. The total amount of character rigs and animations can be greatly reduced.

In multiplayer games other players usually have a full body visual representation of your character. This means that you need both first person animations and full body animations that also need to approximately match our available players actions.

If you know there will be both. You can decide early in your pipeline whether to make the world or first person animations first.
Doing world person animations and using them as reference or simply modifying them. 

Do we want to see our legs when looking down?

Legs are a mostly just visual aesthetic. They do however require their own animation controller adding another layer of maintenance for a technical animator.

Following my recommended setup this feature can be added later in production fairly easy. If you decide to go with a true first person approach this needs to be accounted for during the development of the animation controller. I do strongly advise against doing a "True first person" approach.

What is True First Person?

True First Person is a concept that comes up ever so often. While there is currently no universally accepted definition. True first person is often described as when the character camera lines up with the eyes of the visible character model, giving a "truer" sense of body awareness. Often done by attaching the camera to the head bone of the characters skeleton. In doing so makes the camera follow the natural motions of a characters animations and walk cycle. But what is gained in "realism" is usually lost in control. 

Attaching the camera to the animation rig can introduce many problems that cause visual glitches or worse sluggish input.

True first person puts heavy demand on the animation system and controller. Design issues can arise and start spreading between disciplines when Gameplay and controls becomes heavily dependent on the animation controller.

Common issues:

These are just a few of the issues you may encounter trying a True FP approach.

I think the "true" part of True first person is oftentimes misinterpreted as "The one true way" to make first person and not just an alternative to a classic FPS setup which can be made to look just as good if not better in most cases.

Recommended First Person  actor structure


Character Collision

The root collision component of your character that handles movement physics and locomotion.

World Model - Body Mesh | RED
"Mesh"

Full body representation, visible to other players in the game. Not rendered or processed by the local player.

View Model - First Person Body | Green
"ViewModelBody"

The visible Lower body from a first person perspective. Often without a head and/or arms depending on project requirements.

In a "true first person" setup this would be the only first person view model.

View Model - First Person Arms | Grey
"ViewmodelArms"

The primary view model is a set of floating arms. Parented to the camera. They are parented to the camera so they inherit rotations and stay in frame at all times. 

Camera

The camera is attached to the root of the character collision. This means the camera inherits the character transforms. Looking side to side usually means rotating the whole player collision.

Note:

Each skeletal mesh has its own animation controller!

Basic mannequin bone layout
Sockets and virtual bones can be easily added through the skeletal mesh editor

First Person Rig

Humanoid

I suggest starting from a standard humanoid skeleton.

While most engines, modeling suits, and animation packs come with a standard humanoid setup, some of them lack bones that are important when creating an easy to work with character rig.

Most important are the item bones and IK target bones. These will make both animation and implementation a lot easier in engine.

In case you want to author your own character rig, I  recommend looking at the Unreal Mannequin bone structure for reference. 

Item Bone and IK targets

The Unreal Mannequin comes with a standard humanoid bone setup.

On top of the basic humanoid skeleton, the Mannequin also comes with both hand and foot IK targets. The IK targets are extremely useful when dealing with item or world interactions. 

The Mannequin features an Item bone named "ik_hand_gun". Parented to the character root bone. Below the Item bone in the skeleton hierarchy are two IK targets bones one for each hand.

The item bone is very important when we want to animate objects that can move separately from the hands. This is where we attach weapons or other hand held items we want the character to wield. 

The IK target bones are used to keep hands attached to the weapon at runtime. These IK targets can also be animated when doing weapon animations, having them as children to our item bone means that they will automatically inherit any transforms made to the weapon bone.

Making sure you have a proper IK bones set up will help improve the quality of your hand IK. When calculating IK targets at runtime you risk introducing visual artifacts like jitter,hand sliding or animation popping, due to differences in the animation update rate and IK transform calculations. In Unreal, having proper IK hand targets is the way to go.

Note:

The Item bone is a child of the "ik_hand_root" the benefit of this as opposed to attaching it immediately to the character root is that the ik_hand_root can be made to inherit transforms from the upper body, it can be very useful when dealing with aim space animations.

Dealing with multiple items

The default mannequin skeleton only has one item bone. If you want to implement dual wielding you might need to modify the skeleton to add additional item bones. 

In theory the amount of item bones should match the amount of independent items you expect your character to wield in their hands at one time.

A single item bone with left and right IK targets works great when dealing with two handed weapons. But less so when dealing with offhand equipment or dual wielding.

Like holding a sword or pistol in one hand and a shield or a torch in the other.

If you suspect you will ever need offhand equipment. I would strongly suggest making that change as early in production as possible preferably when you build your pre-production character rig.

In some cases you can get away using temporary setups using sockets or virtual bones.

Sockets

Sometimes you might be missing a bone, or maybe you want to designate a point on the character where you can attach items. For example, Weapon holsters, grenades or maybe potions hanging from a belt.

In the unreal skeleton editor you can easily create sockets that attach to a bone and inherit any transforms made to it. The great part about sockets is that they can have their own transform, allowing you to easily reposition items even after defining your skeleton while keeping all changes completely in engine. 

The drawback with sockets is that they are very rigid. As they only inherit the parent bones transform with an offset. Not very well suited for animation, in that case you can instead use virtual bones. Virtual bones are very effective when you need a quick dynamic bone setup that can be manipulated at runtime. Like having your holstered weapons and grenades slightly jiggle while in motion.

As of Unreal 5 and the introduction of Control Rig, more advanced solutions can be authored in engine.

Animating the Item Bone

The item bone (ik_hand_gun) is where we attach weapons. 

The item bone can be animated when dealing with motions that manipulate the weapon location, like recoil, melee attacks or procedural weapon offsets.

When authoring weapon specific detail animations like arm and hand poses or more complex movement like weapon reloads, the IK hand targets are animated together with the the characters body. Animating the IK targets makes sure the characters hands always keep their relative offset.

Camera & View models:

Camera Setup

My recommended setup is very simple. Attach the camera to the character. collision, and align it at eye level with your world person mesh.

Remember, the world person mesh is a proxy. You should try keeping them aligned best as possible. Slight deviations location wont be an issue unless it severely impacts gameplay.

Having your camera attached to your character mesh can introduce a severe dependency on your animation controller taking control away from the design and code team.

For easier maintenance

I Recommend: 

I Advise Against:

Arms

The character arms are the main representation of the character to the player. These are the most important models as they are used to convey what weapons and tools are currently at the ready and how they work. 

The 

These rendering modifications usually amount to:

Attaching items or weapons

This topic is very dependent on your project. While there is no right or wrong way. Issues can arise if we don't think ahead.

In some cases. Attaching an item to your characters hand bone might be enough, especially for bystanders or NPCs.

This can make items look glued to a characters hands, and make it really hard to allow separate hand and item movement.

As mentioned in the section First Person Rig:

I would strongly advise attaching items to a separate item bone, parented under the root of your character with it's own hand ik_targets.

The default unreal mannequin has a bone named ik_hand_gun for this very use. A good reference if you decide to create your own character rig.

Field of view:

One trick commonly applied to keep weapons and items looking consistently good, and hiding the seams of the character mesh. Both the arms and objects held in the characters hands are often rendered at a forced field of view(FOV) different from the player camera.

You can find this in most modern FPS game. By using a separate FOV when rendering the first person model, we can assure weapons and animations stay in frame while also looking more consistent across multiple aspect ratios.

This is especially useful when implementing Aim Down Sight(ADS).

When doing Aim Down Sights you want the weapons sight to align with the center of screen, while also moving the view close enough to clearly see through the sights. On a long weapon, if you move the camera closer to the weapon sight you might start experiencing clipping, where other protruding parts of the weapon mesh start intersecting with the cameras render plane.

By rendering the weapon at a lower FOV flatten the look of the weapon making it look like it's closer to the camera than it actually is. Allowing you to see the entire weapon model and at the same time getting a close enough perspective to properly see through the weapons physical sight model.

For anyone working in unreal I recommend looking at: Weapon FOV - By Krystian Komisarek as a starting point. It has many useful functions for moving between native camera fov and a selected target FOV on the fly.

Top: no fov shifting applied. Bottom: viewmodels rendered at 60 fov.using the Weapon FOV material functions by Krystian Komisarek

Further Reading: Setting up a FPS animation environment in blender

At the bottom of this article is a step by step how to set up your blender environment to author your own FPS animations.

View model Body

The view model body represents the rest of the characters visual body.

To avoid seeing inside of the head, or seeing a double set of arms. These are commonly removed from the body view model. 

Toggling Visibility

Sometimes you may want to keep the ability to toggle the arms and head on and off. For this Unreal comes with these two nifty functions, to quickly hide and reveal bones. Very useful when moving between first and third person.

These nodes scale the size of the selected bone(and all bones below) making them appear invisible. This causes pinching on affected vertices which can help cover up the inside of the character mesh.

Note - avoiding zero scale issues

 in some cases when setting a bones scale to 0.0 they start behaving unpredictable sometimes inverting animations and attached sockets or never being able to re-size to full scale. To work around this: instead of setting a zero value try going for a really small value like 0.01. that appears invisible.

Camera attached arms rotates independently of the body

Looking down

A common problem when doing this type of setup is, what happens when we look down down. You might see inside of the body or have important gameplay elements be occluded. This can be solved in many different ways. Depending on your technical skill, some solutions might be better than others. Here are some suggestions:

These are all viable options, combining multiple of them might produce a better result than relying on a single solution.

I talk more about this in my article on Procedural First Person Animations.

World Model

In the mesh detail panel you can find a flag labeled owner no see. This will stop the character from rendering for the contolling player.

The purpose of the world model

The world person represents the player inside the game world, giving other players a target to shoot, while also relaying important gameplay information about the current state of the player.

Why keep the view model and world model separate?

How gameplay is seen by a player and viewed by other players can differ quite a bit.

Playing a hit reaction when shot, or raising your arm when affected by a flash bang can be important information to outside observers. These same features can be obstructive when seen from a first person perspective, which instead relies on screen space effects or UI elements. Separating the animation controllers allow you to reduce dependencies between the world person and local player.

There can also be significant performance gains. In competitive online games where animations are vital for hit detection, keeping animations in sync can be very taxing when processed by the servers game thread. The world person can often get away with less complex animation setup that just relays the most important gameplay elements.

The world model can often get away with the following:


Thread safe animation can still be used for simulating physical details and post processing locally.

All done!

This is what i consider to be the most versatile setup for a First Person character. It minimizes dependencies on the animation controllers giving the design team full control over gameplay. This is the approach I use when doing first person gameplay.

If you're interested in creating your own first person animations in blender, below is a quick step by step to set up an easy to use animation environment.

Setting up a first person animation environment in Blender

Step by step

This covers the basics of how to set up a camera that aligns your animation environment with your game view. 

Add a camera to the scene

Shift + A: Add a new camera object to the scene

Matching the FOV

Align the 3D cursor to the head bone

Position your camera at the 3D cursor

Use the transform tab to adjust orientation if necessary

Set the first person camera as preview in the animation tab

Done!

Now you have a simple blender setup primed for posing your first person animations.

Continue Reading


Weapon Recoil, Spread & Spray Patterns ->

Modern FPS games rely on dynamic weapon recoil to make different firearms feel unique and interesting. The recoil system greatly impacts the cadence of any shooter game.