Up to version 4.13 this was working fine, as of 4.14 the Camera spazes around.
This may be related to Unreal Engine Issues and Bug Tracker (UE-38811)
I’m not sure to where the Issue actually happens, so I reproduced a striped down version in a fresh project.
Open up the level of the attached project and hit play. The jitter is random and can appear at any angle, sometimes theres no jitter, sometimes very little, and sometime it spazes extremely. The angle doesn’t seem to be relevant. If you are “lucky” you will see it spaz out right after hitting play, if not, move the camera/mouse around a little, stop, wait a bit and repeat.
So I think you have duplicated some functionality, causing it to conflict. You have the camera attached to the head bone, but the camera will rotate with your mouse controls independently of the head. So essentially you have the mouse controlling the camera, but also trying to have the head bone move the camera based on aim rotation. Not sure why you’re doing this, but it doesn’t seem like the best setup.
Well, the setup in the example scene are just some parts of a larg system I use since around 4.8.
Yes, the Camera location is controlled by the head bone. My reason todo that is that the Viewport is always located where your head is (makes sense for a true FPS camera I suppose)
Yes, the Camera rotation (yaw only!) is controlled by the mouse, so the player actually can look up to the sky and down to his feet (makes sense too i suppose)
I can’t tell for sure, but I think some example/tutorial stuff by epic actually works the same way.
Now the Headbone transform is applied so that other players can see wherever somebody is looking at. It’s also aligned with a 3rd person camera, aimoffsets and various other stuff. I can tell you that it has been a pain in the ■■■ to setup for multiplayer as several properties such as base aim/control rotation are not replicated correctly and it requires tons of workaround to compensate for it, adding more workarounds wouldn’t be joyful.
If your assumption is true, that the camera actually tries to pickup the head bone rotation, then I think that’s probably the/a bug, because the expected behavior (as it was working till 4.14) is that the camera would only listen to the control rotation. Hence the option “Use Pawn Control Rotation” on the camera component. Having that option check, the head bone rotation should not have any influence on the camera.
Hmm I had written a reply but for some reason it doesn’t show up anymore. The core point was, that if your assumption is right, and the head bone transform interfers with the camera rotation, than that’s a bug.
The expected behavior ( if “Use Pawn Control Rotation” is checked on the Camera Component), the head bone rotation shouldn’t interfer with the camera rotation, regardless to what the bone rotation is set to. I mean, that’s the point of that setting, isn’t it? And this setup was working just like expected from 4.8 till 4.14.
Don’t want to be a nag, but the intitial response took 2 Weeks, and now I’m waiting again over 2 Weeks, so this is up for longer then a Month already…
Yes, UsePawnControlRotation is meant to control the Camera rotation. But when you’ve got the Camera attached to the Mesh with “Parent Socket” set to “head”, it causes a conflict. If you want it to inherit only the location of the head bone for the camera, you’ll want to use set location or another setup. UsePawnControlRotation doesn’t override attachment.
If I simply disconnect all of the logic that modifies the head rotation and use nothing but “Use Pawn Control Rotation”, then it has the same behavior without the jitter.
If you need the head bone to continue to rotate for MP purposes so other players see the head rotate, I’d suggest either A) Creating a separate head bone that controls the camera or B) Attach the camera to the head bone differently (Set location…something like that). Try unchecking “Use Pawn Control Rotation” and see what’s happening. The head bone is trying to do that on top of the Pawn Control Rotation.
If you want to send a 4.13 version of the project, we can take a look and see if there really is something wrong, but so far it seems like it was working by accident in older versions or a bug was fixed that actually shows the error in this setup. I.E. “Use Pawn Control Rotation” may have been overriding attachment rotations when it wasn’t supposed to.
PS - Concerning the delay in response, we just had a huge change in our process over the last couple weeks and it has created a bit of a backlog. We are working on catching up and will hopefully be more responsive going forward.
During a quick test parenting it to another Bone seems relatively good so far, but If CR (Use Pawn Control Rotation) is not supposed to override the attachment Rotations then Animations that affect the new bones rotation would still be prone to jitter?
I went ahead and did a quick research on FPS camera Tutorials, and while I didn’t found the one from Epic, every single Tutorial and related Question I found used the Camera Attachment to the head (mostly) with CR. Maybe it’s me, but honestly I also can’t think of any Situation where somebody would want CR to NOT override the Attachment rotation.
So whether CR beeing intended to override the Attachment rotation or not, I feel like 99% of Users would prefer that it does it, as it used to be until 4.14.
I also tested your suggestion to set the Camera location. I set it to a Camerasocket on Tick(also tried on Update Animation), but it’s too slow. When the Headlocation makes abrupt movements, you will see the inside of the head for a frame. Yea, I can hide the head… until you look at your shadow or in a mirror etc. - pretty cool if you are making a headless horseman game otherwise…
You are creating redundancy with everything you’re doing on Tick in your CharacterBP and in-turn your AnimBP. There’s no problem attaching to the head bone, but you don’t need to rotate the head bone with everything you’re doing on Tick. Use Pawn Control Rotation does all of that. You appear to have the same functionality after detaching everything from the Tick Event. Maybe I’m misunderstanding after the long delay in response, but this does not seem like an engine bug to me.
I am marking this as resolved for tracking purposes. I will see responses if you have any further issues.