3D Model to follow camera tilt/rotation

[colelli]

Godot Version

v4.4.1

Question

Hi everyone, I am wondering how I can achieve a set-up where both my first-person view and third-person view are done through the same model, whilst still reproducing player’s input in a reliable way.

At the moment I am using one model to display both “views” (it’s a multiplayer game so when I talk about third-person I refer to the view from a peer’s stand point).
It works fine, however I would want to replicate camera tilt on the character model to make some movements clearer/more usable. For instance, when the player holds a weapon I would assume that (even in real life) if they were to look up they would tilt their torso back to bring the arms along with the movement (i hope that makes sense. If not, I tried to depict it using my advanced art skills and the most advanced graphics software known to humankind… paint).

So instead of being like on image 2 (current implementation) I’d love to have something similar to image 3.
I’ve thought of using BoneAttachment3D to override the bone’s rotation, but I wad wondering if you know of a better approach, or better, if you know any tutorial I can watch/follow to take a look at a possible solution.

[Brawlawnzo]

You’ll probably want to make a custom SkeletonModifier that calculates the ‘gun vector’ and its rotation to the target, afterwards that rotation can drive the transform of the spine bone for example. But the approach largely depends on your setup. Is the aiming pose animation baked or procedural? Are hands “IK’ed” to the gun? Does that gun have its own bone? etc.

[colelli]

@Brawlawnzo

Is the aiming pose animation baked or procedural?

The aiming animation (at least for now) it’s a static pose where the character has its arms in an aiming position. Guns are then added to a child node of the GeneralSkeleton3D node, under a specific Node3D, named MainHandContainer in the image below. So the gun does not have its own bone.

@Brawlawnzo

Are hands “IK’ed” to the gun

The hands are not IK’ed, and as far as I know the Skeleton IK node is deprecated in the latest stable version, right?

[Brawlawnzo]

@colelli

Skeleton IK node is deprecated in the latest stable version

It still works (as far as I know), it just isn’t considered stable. And you could be using your own or third party IK as well.

@colelli

The aiming animation (at least for now) it’s a static pose where the character has its arms in an aiming position.

Then my suggestion still stands: custom SkeletonModifier^[1] is probably your best bet. I would refrain from using bone attachments for calculating transforms though, since they update the next frame, so you modifiers could potentially be ‘bouncy’.

There’s also the LookAtModifier, but it affects only one bone, and I recently found it lacking for any tasks other than driving the orientation of the head of a character (which is in fairness a very common task).

---

1. I’ll leave a link to the guide from the developer blog in case you’re not familiar with the term ↩︎

[colelli]

@Brawlawnzo

custom SkeletonModifier is probably your best bet

Thanks a lot, I will take a look at this for sure as it sounds very interesting to play with.

@Brawlawnzo

There’s also the LookAtModifier

I was also taking a look at this, even though - as you mentioned - it just affects one bone, nothing’s stopping from using more than one together. I’ve seen that you can also limit rotation and influence. I tried a very quick setup using it and it seems to be a possible solid solution, as I quite literally have a target to follow in front of the player’s camera

[Brawlawnzo]

@colelli

nothing’s stopping from using more than one together

Technically yes, but it could lead to some unexpected behaviours - you’re welcome to try though, don’t forget to share your findings, if possible.

@colelli

I quite literally have a target to follow

The problem is that if the bone that you want modified, for example the torso, is significantly rotated (yawed?) in the animation pose, you’d have to either rotate the target around the body accordingly or calculate a different ‘origin offset’ in the LookAtModifier settings. As far as I could tell you cannot chose a custom ‘forward axis’.

[colelli]

@Brawlawnzo

don’t forget to share your findings

Sure will once I will have a solution I find worth sharing.

I have taken a look at SkeletonModifier s. Flexibility is incredible, however I think I will try to avoid that path for now, as I don’t want to spend more time than necessary for the character controller. I’ll keep it in mind for the future, maybe I will start an “ultimate character controller” project
Fair Fight has a very insightful video about them. Be aware, it’s far from beginner friendly and I had a very, very hard time following along. I’d probably need to invest weeks solely on understanding the basics of it.

@Brawlawnzo

it could lead to some unexpected behaviours

That is very true, as also shown in a video by Lukky. However he also shows a work-around to this issue. I haven’t tried this yet, but perhaps - in my specific case - it won’t be affected by the animation too much, as most walking/running cycles modify the yaw of the model (Y-Axis) and I need to operate on the pitch (X-Axis), since my goal is to “bend” the spine.

[colelli]

@Brawlawnzo

don’t forget to share your findings

Here’s what I could manage to do without over-engineering it. Mind you, the result might be a bit wonky since I am mostly working with Mixamo animations, maybe creating your own animations helps in achieving a better result.

Bone Attachment Approach:

It definitely works. But does it work well? NO!
At least in my case, since I have to affect 3 (or more) bones and all of them must follow on a “priority” basis, meaning that a child bone should rotate only once the parent has reached peek rotation. It also introduces a rather unexpected behaviour: modifying the bone attachment, correctly impacts the skeleton but somehow does not impact other bone attachments IF they are placed outside of the hierarchy you are using to bend the spine.

Like so, for instance.

Weird? Perhaps. I have no idea, as I am not extremely knowledgeable on how the Skeleton3D works behind the scenes, so it might also be this is intended behaviour.

I’d give 2/10 to this solution as it is quite difficult to manage through code, there’s a big margin for error, and likelihood of spaghettifying your code is exremely high.

LookAtModifier Approach:

Definitely the most straight-forward approach. Simply add a LookAtModifier for each bone you want to impact, set your target, constraints, and whatnot, and… done.
In my case I used a Marker3D under the camera RayCast3D as target (since that’s what I use to detect what the player is looking at). I applied the modifier only two 3 bones: Head, UpperChest, and Chest.

Using only these 3 bones gave me the best result for the kind of animations I am running. Applying a modifier to the Spine and Hips might result in unwanted behaviour, since in my case those bones are responsible for the “wobbly-ness” of the character during animations. Since the modifier effectively locks the axis around a target, animations are going to look corrupted.

Again, this might also be part of the intended behaviour, but I find it confusing that the modifier is impacting some Axis other than the one I specified. Even when the Use Secondary Rotation option is set to false, it still cancels out all the rotations applied by the animation.

I also had to apply a small offset to compensate some “ugliness” caused by modified rotations not matching 100% the animation rotations, but the result is extremely satisfying.

I’d give 8.5/10 for this solution. Easy to setup. Easy to use and does not need any code other than the one you need to set a target (if you even need that in your case).

Custom SkeletonModifier Approach:

By far the best. From what I could see online you can pretty much apply any sort of custom behaviour through this low-ish level approach. Being low level it also implies a lot of (precise) engineering to achieve the wanted result, but it’s undeniable that this will yield the best looking output.
I have not tried this in my project. Definitely will keep it in mind for future tries/side-projects. But again, the barrier to start using this is very high (at least for me) so I don’t see this ever becoming extremely popular amongst hobbyist.

I’d give 10/10 for looks and 4/10 for accessibility. Definitely far from beginner friendly.

[Brawlawnzo]

@colelli

modifying the bone attachment, correctly impacts the skeleton but somehow does not impact other bone attachments IF they are placed outside of the hierarchy you are using to bend the spine

Sounds like intended behaviour - bone attachments are not really supposed to be used for such tasks by design (because of their aggressive overriding), especially now with the introduction of SkeletonModifiers, I imagine they will be fully deprecated in the future.

@colelli

it still cancels out all the rotations applied by the animation

This is what I was talking about: according to the docs this is not an oversight, but intentional. Although, I’m not sure what you meant by

the modifier is impacting some Axis other than the one I specified

[colelli]

@Brawlawnzo

Sounds like intended behaviour

I am not entirely sure about that. Here I quote the docs page:

bool override_pose = false
[…] When set to false, the BoneAttachment3D will always be set to the bone’s transform. […]

This was not the case. It only happened to follow the movement if it was a child of a BoneAttachment3D for which you are overriding the position. For instance, if you attach a BoneAttachment3D to the Neck and one to the Spine, rotating the Spine moves the Neck accordingly, but the Neck’s attachment does not follow along unless it’s a child of the Spine’s attachment

@Brawlawnzo

I’m not sure what you meant by

I believe my doubt comes from the use_secondary_rotation field. By design you can choose a primary_rotation_axis, so for instance if I was to choose the X-Axis and disable use_secondary_rotation, I would assume/expect that the rotation I will impact is only the one I selected, hence the X-Axis. But that does not seem to be the case, as even when disabling the option, the other Axis are simply zero-ed out (it seems). Else I don’t understand how the modifier is affecting the Z-Axis if I’m only using the X-Axis and no secondary rotation.

[Brawlawnzo]

@colelli

rotating the Spine moves the Neck accordingly, but the Neck’s attachment does not follow along unless it’s a child of the Spine’s attachment

I think, that happens because technically when the bone attachment checks the transform of their bone the next frame it’s back to anim pose transform. If it’s a child of another node (any node) it will obviously inherit its transform - but I’m not sure actually why it follows along in this case, since there’s a race here to change its transform which the bone attachment is supposed to win, but it doesn’t.
I mean that’s one of the reasons for switching to SkeletonModifiers workflow, their structure is more robust, and execution more predictable.

@colelli

I don’t understand how the modifier is affecting the Z-Axis if I’m only using the X-Axis and no secondary rotation

Hm, I think I have to have something in front of me to get the issue here, but since you’re overall happy with the results we should probably stop cluttering the topic :).