Why use gimbals Why not use AddRelativeRotation instead of AddLocalRotation

[shisha101]

Hey everyone, so I just wanted to point out that I think manually adding gimbals is more of a work around to what we really want to achieve in this case rather than a solution.
There is no doubt that gimbals are useful in many cases, but here what we really want to achieve is a relative rotation of the camera via the spring arm with respect to the tank body. So why not use a relative rotation with respect to the tank body ? e.g. AddRelativeRotation (spring_arm).

Using this method simplifies the BP and logic. It also got rid of the snapping effect. I am still in lecture 119, so maybe I am missing something.

I have tried this method and it works well. There is only one exception though if you try to pitch more than 180, or -180, I think there are limits on the pitch compared to the yaw which is not clamped. Can anyone shed some light on this ? when hitting this boundary I think the rotations have troubles.

Cheers !

[appS]

Hey, glad to see someone else did the same thing. Using relative rotation (relative to the root) for the spring arm for azimuth seems to make more sense so the pitch and yaw rotations don’t get combined and start twisting.

However, I’ve found the gimbal component is still useful in keeping the attached spring arm / camera relative to the world and not the tank for inclines or flipping the tank over. (Although you could just skip the gimbal component for this purpose and set the spring arm to not inherit these rotations, which achieves the same goal, but I’ve found this to be a bit wonky in comparison).

I haven’t encountered any limits/clamping for pitch as you’ve said with this method, I can pitch infinitely either way so not sure on that. Although some sort of clamping is definitely needed.

[Nati-onBear]

I think the true purpose of Spring Arm is to control barrel up and down and the Gimbal is for the barrel to move left right.