First person camera tech.

Development Programming & Scripting
, ,
1

Over the past few years, our project has evolved a particularly complicated solution to a set of problems that arise of AAA first person games that desire a lot of camera animation, including synced interactions with other actors in the world(glory kills, etc) I hope that I can get some insight on some alternatives for some of these solutions, because they are unwieldy and complicated, though not without purpose. I am hoping I am overlooking some simpler options.

Starting from a common reference, the first person template sets up the pawn like so.

[Image Removed]

The FirstPersonCamera importantly uses UsePawnControlRotation=true so that the control rotation is applied top the camera itself as an override

Because we are a game that utilizes a lot of sync melee, and even the desire to have camera animation reflected in the first person camera, quick time events, etc, we went an entirely different direction. This would also have been several years ago, where this first person camera setup was even simpler IIRC the camera rig(SKM) was attached at an offset on the capsule, and the control rotation pivoted it in place. There was no body awareness like there is now. At least now the camera is attached to the head of the mesh, so positionally, it will reflect the animation, however, rotationally, the control rotation fully overrides the camera rotation.

So the question is. What options are available to allow some of the animated camera rotation to be felt on the camera, rather than the control rotation completely overriding the animated camera rotation? Ideally with an element of controllability, like a scalar for how much to apply.

Also, the first person template now doesn’t appear to implement a weapon, so it now doesn’t show the added complexity of accounting for procedural control rotation while maintaining a camera space arm rig. It’s like it deliberately avoids the entire meat of the issue of mixing a body aware, first person camera perspective, with an on screen arm rig.

This is why our solution has become the beast it has, because I use a control rig to distribute the control rotation across a set of bones(spine3, neck, head, camera), and some post fixup to put the spine3 bone back in the right spot relative to the camera as it was when we started. I suppose that same piece of the logic could be applied to the first person template arm rig, but still I ask, why is the first person template missing the most important element of first person gameplay? (a camera space weapon)

Hopefully that’s clear enough for some pointers.

TLDR: How do you preserve camera animation(rotation specifically) in a first person setup, while still being able to include procedural control rotation. And why is there no first person weapon in the first person template?

2

Hello there,

In terms of first person setups, the way I’ve seen this done is to drive the camera from a bone in the skeleton, and have the control rotation drive the animation.

This way, the animation is capable of running things like root motion animations that drive the camera for certain actions.

One way to do this is to author the animations for the player character in first person to keep the head bone flat in Z and to keep rotations in check. A lot of animations will result in head movement, which can be motion sickness inducing.

Another tangential or additional technique is to apply some corrections to the camera position and rotation after the animation instance has updated the bone positions for the player. This can help zero out rotations like roll from the camera if the animations aren’t completely clean. Sampling from curve tracks can also be used to optionally disable or reduce the impact of these effects for when the animation should cause camera rolls or the like.

It sounds like your control rig is procedurally creating something very similar to this.

There is a blog post by Lena Piquet called True First Person Camera in Unreal 4 that goes into quite some detail about ways to accomplish this, and I can link this if you are interested. Admittedly, this is prior to Control Rig, so they wouldn’t have had that option.

In terms of the First Person template not including weapons, the option extra arena shooter should contain an example of first-person weapons. These extras are included by default in C++ template projects, but they are opt-in for BP templates. The level is called Lvl_Shooter.

I hope that helps.

Best regards,

Chris

3

Thanks. That helps in the sense of knowing where the new “full” arm rig example went to. It uses AO for pitch aiming. Unfortunately, I don’t think this is a viable approach for melee centric games. I mean, you could use an AO for pitching a melee idle, but as soon as you play melee attack animation montages on top of them, it becomes a mess to try and preserve the authored first person view of the attack in the same ways(additives, etc), Melee attacks are far more dynamic than typical shooting animations.

I’ve found the article you mentioned

https://www.froyok.fr/blog/2018\-06\-true\-first\-person\-camera\-in\-unreal\-engine\-4/

It’s a good resource for this sort of thing for sure.

I think melee centric games are at the further end of the complexity gradient from shooters, so we may just need to roll with the solution we have.

Just to provide more about what we are doing, I am using a control rig to apply the control pitch to the full body first person mesh, via a distribute rotation around. It’s seems to be the most sensible mechanism to emulate a [proper body distortion of a real look pitch, with the rotation distributed across spine3->neck->head. Naturally, this approach distorts the mesh in the first person view(with respect to the camera), so the control rig first snapshots our camera relative to spine3 transform, applies the distribute rotation around, and then snaps spine3 back into the exact location relative to the modified camera location. This ensures that we maintain consistent and precise on screen “arm rig” for all attack animations and such as well, while still providing us the capability of a full body aware first person setup. It works but it is unwieldy and complicated. That may just be a reality of solving these issues. I am just hoping there are some simpler tools that may allow us to simplify this process.

4

Unfortunately, I don’t believe there is any tooling that would make this easier. The requirements can differ a fair amount between use cases.

The approach seems solid, especially if it’s giving the results you want and performance is good.

What part, if any, are you finding unwieldy?

Best regards,

Chris

5

The complexity of our control rig has built up to a degree that I couldn’t help but think there must be a better way. But after taking a fresh look and seeing that even Epics new first person stuff went in the same direction, I’m a little more comfortable in thinking we didn’t really go so far off the rails as I thought. Epics new first person templates go in the same direction of significant use of control rig usage, so I think the unwieldy element is to be expected, and will just be the growing pains of learning a new tool(control rig). We can close this.

6

Agreed, it doesn’t sound like you went off the rails at all. Procedural systems can get complex as a trade off for their flexibility and expressiveness.

I’ll close this out for now.

Best regards,

Chris