True First Person Shooter Camera with 2D Aim Offset: Body Rotation & Weapon Position Issues

Sort of hard to read or actually see what that problem is.

suggestion 1.
Place a reticle with UMG at center screen, so you know that’s the center visually (also when filming). just for debug purposes really.

Suggestion 2.
the gun is coming in from weird angles (over shoulder?)… are you sure the initial position is being taken into consideration in the correct coordinate space?
again, the X and Y dont matter to the initial position as much as you Z. The gun should be going Up from hip to line of sight.

Suggestion 3.
Order of operation.
Maybe your blend is not occurring at the correct time to get everything to work correctly.
you should have in sequence:
base locomotion base, blend aim offset on pelvis.
the additive aimspace should probably not incorporate your arms if you are manually adjusting them via bone positions.
so you have another blend on top of the aimspace on the shoulder (or upperarm). This should stop having to fight between the animation position and the adjusted values.

Also, I could do with a recap to be totally honest.
Did you go with adding sway via animation, or is it controlled via code and movement of the root gun hand bone?
Oh and I would love somewhat bigger pictures, I cant make out what those nodes even say…

Sorry about that, I’d been using a feature of my monitor that draws a crosshair at center screen to adjust the position. I’ve added a UMG widget for it now.

Here is the current result without the camera updating to the socket position. This is purely driven through the right hand’s position.This is what it looks like when the camera moves to the socket position. It solves the issue just barely; note how at the very end of the vertical offsets the gun becomes off centered to the right.

I managed to get the sights lined up pretty much dead on after adjusting the sockets for the sight and the socket that the gun is held in on the right hand. The only problem is the same as before; as I rotate up and down, the gun is moving around because its moved within the aim offset assets themselves. Your suggestion #3 will most likely resolve the issue. I’m looking into it now but I’m unsure of which pose to actually blend the aimspace on the shoulders. If I can figure that out, the problem should theoretically be fixed.

Here’s an album with bigger and higher quality images of my anim graph and the event graph running it so you can see what’s going on in there. I’ve highlighted the aim space blending order, the IK bone modifications, and the event graph controls for the sight socket conversion and the code that’s moving the bone positions depending on the state (shouldered or aiming down sights)

As far as a recap, the sway is fully controlled through a C++ function that is ultimately stored in a variable called “Current Aim Hand Rotation”. This is fed into a Transform Modify Bone on the right hand in Bone Space with Add to Existing selected.

I hope this all can shed some light on the issue. Like I said, if I can figure out which pose to blend the aimspace on the shoulder with, that should be able to fix the problem!

It looks like you’re calculating sight in hand_r space, instead of hand_r in sight space. And you’re not using the resulting rotation from the calculation, in the next picture, where you interpolate… Also, regarding the interpolation, I assume the alpha value that’s being feed will reach 1 by the time you want to have the sight aligned, because even if your location/rotation were right, nothing would align until alpha is 1.

I can’t tell if you’re retrieving the current position of the hand bone every frame to use it to feed the event graph (or C++ code) calculations. If you are, and you use those calculations to feed the anim graph that will move the hand bone, it would cause the bone to lag behind the spot where you want it, because the event graph gets the bone position in one frame and the anim graph sets its position for the next, so I would avoid it…

Those are the first things that come to my head when I look at the link you showed us.

I see the distinction between the sight vs hand_r space now, I’ll correct that. What nodes would be best to do such a calculation? The alpha value for the interpolation is fed through a simple timeline in the character blueprint when the button is pressed. I haven’t had much of an issue with the bone lagging behind but if it becomes a problem I can easily move it to the anim graph.

I only mentioned that because of how I do it in my own project, using the sight space as the camera space, like I mentioned earlier. It might not be what you’re going for, so the way you’re doing it might be better fitted for your project, I don’t know… Regarding the nodes, I retrieve sight and hand transforms with GetSocketTransform and I get one relative to the other with “MakeRelativeTransform”.

Thanks! I’ll give it a try and see if it looks better than what I have now!

Also, about the rotations not being plugged in (forgot to touch on that in my last post), I didn’t plug them in because my right hand FABRIK node was set to not copy the target rotation. When I do have it set to copy the target rotation it throws the positioning and rotation totally off for everything (just because the offsets currently aren’t setup for it) but it did seem to stop the problem I was describing, although the gun doesn’t go all the way to 90 or -90 degrees on the pitch axis.

I’ll keep experimenting with it, thanks again for all your help!

EDIT: Just tried using those nodes for the conversion and its working much better, I just have to get the offsets setup again!

One thing I forgot to mention… I use TwoBoneIK instead of FABRIK. I once used FABRIK and I noticed that the sight wouldn’t align correclty until I increased the Precision in the node… or the Max Interactions, I don’t remember exactly… I also don’t remember the value I used, but it was higher then what you’re using on your pictures… just increase them and see if you see a difference.

Regarding the rotation of the hand bone, I see you’re setting it through the CurrentHandAimRotation variable, what I wanted to really tell you is that somewhere in the calculation of this variable you must take into account the relative rotation between hand and sight. Maybe you are, I only say this to be on the safe side, because I can’t see it in the pics. Another thing (just to be on the safe side) is that, for the purpose of checking alignment only, it would be ideal to turn off the swaying effect you mentioned you put in this variable through C++ (maybe you already are).

I’m actually not including the relative rotation between hand and sight in the CurrentHandRotatation variable, I hadn’t even thought of that! Perhaps that’s whats been causing the issue and would probably be a better solution than screwing with the Copy Target Rotation of the FABRIK anyway since that isn’t aligning the gun correctly regardless. Do you happen to know a node that’s good for combining rotators?

I’ll try adjusing the FABRIK values some more as well and also try TwoBone IK and see if that works better. Thanks for the suggestions, these are great leads to follow!

In my experience, FABRIK works as good as TwoBoneIK, but you have to increase the precision value. For combining rotators, see if the CombineRotators node works well for you and try inverting the two inputs on this node if it doesn’t work at first, because order of inputs matter in this node.

I managed to get combine rotators working and while its a bit better now, the issue where the sight gets rotated too far with the rotation is still persisting.

Here’s the changes I’ve made to my anim blueprint since my last code sample upload. I’ve added a new blend node after the aim offset pitch rotation like MostHost suggested in order to prevent the arms from moving with the aim offset. So now only the spine area is bending down, preventing the arms from moving in the weird directions they were. The code for the CurrentHandAimRotation calculation is also shown. The deadzone variable is from the C++ function that calculates the deadzone and the sway which is lerped to from the current rotation. I’m then converting the shotgun sight rotation to a quaternion since the C++ deadzone variable ends up as a quaternion and then combining the two rotators as the variable’s set value.

This is the current result.What I need to find is some sort of way to prevent the gun from rotating up and down like that and keeping its Y axis stable. This might be a really obvious thing that’ll I figure out as I proceed but it doesn’t hurt to have another pair of eyes take a look. Thanks again!

EDIT: I ended up removing the combined rotators because it was causing too many issues. However,I managed to get the sight perfectly centered using a combination of the camera position math from a few posts ago AND the movement of the hand bones in sight socket space. The only problem is, you guessed it, the Yaw of the sight gets ever so slightly offset when looking up and down.

I’m starting to believe its another factor entirely, possibly the variable controlling my aim offset yaw and pitch. When I enable “Use Pawn Control Rotation Pitch”(which I DON’T want to use since I want the full body mesh) to test the pitch at raw value, the sight is perfectly aligned no matter where I look. This has me thinking that perhaps I could blend some of the stock first person arm mesh poses over the aim offset on the arms to keep the arms aligned like they are when Pawn Control Rotation Pitch is enabled while simultaneously keeping the full body visible.

Hey sorry for the lack of response, I’m kinda busy these days, but will take a look at that later… I hope things are working out for you…

No worries at all. I forgot to make an update the other day but I managed to solve the problem by way of game design and some play testing feedback.

The several testers did not even notice that the gun was being slightly offset until I showed them where the center of the screen was, meaning in the long run it’s not as much of an issue as I had forseen it to be in the hands of players. Additionally, I had the testers try the aim down sights with the aiming deadzone feature which not only resolves the issue completely but was also positively received by the testers. They liked it so much that I figured I’d just leave the deadzone on for both solutions and keep it as a toggle in a future options menu if a user doesn’t like it.

I’m gonna call this thread solved at this point. Thanks again (both of you) for all your help, it really helped get me to where I am now with it! I’ll be writing blog posts for everything soon for anyone in the future who wants to try something similar and I’ll post them here.