Forum rules - please read before posting.

UCC Jitter caused by root motion and AC camera

Hello, about 3 months ago I posted this thread in which I mentioned a UCC character jitter when followed by an AC cam that could be fixed by updating the AC camera in StateHandler's Fixed Update : https://adventurecreator.org/forum/discussion/13659/ucc3-integration-needs-an-update-and-perhaps-a-camera-following-fix#latest

But now I'm having this issue again, and it seems related to UCC's root motion which AC's camera cannot follow correctly, regardless of which Update is used in State Handler, here is a video showing the issue :

Here is also the thread I had made about it on the Opsive forum : https://opsive.com/forum/index.php?threads/jitter-when-using-an-ac-game-camera-to-follow-a-ucc-character.9483/#post-49521

Justing suggested making a new view type that interfaces with AC's cam and returns its position and rotation, which I tried, but it gives the same results as we are copying a camera that has incorrect results itself.

So for the moment my only option is to deactivate root motion and use Update. If anyone has any idea about this, please let me know, it would be much, much appreciated !

«1

Comments

  • Off the top of my head, there are two things worth trying:

    1. Use LateUpdate instead of either Update or FixedUpdate
    2. Set the StateHandler script's Script Execution Order to be greater than that of anything in UCC, so that the Update/LateUpdate etc calls are forced to be called after UCC in the frame-update loop
  • Hello, I had tried Late Update as I say in the video but it didn't work either.

    I added the State Handler script at the bottom of the Script Execution Order list, but unfortunately it changed nothing for either of the 3 update modes.

    Thanks for trying to help, but I'm still stuck and have to ask if you have any other ideas ?

  • Don't place anything in FixedUpdate - that's intended for physics calls, and AC's camera system doesn't rely on it.

    It's important to bear in mind, though that AC's GameCameras are merely references for the MainCamera. It's the MainCamera that ultimately renders the final image.

    Therefore, you'll need to ensure the GameCameras are always updated before the MainCamera. If you move the Camera update code to LateUpdate, you'll need to place it before the MainCamera.LateUpdate call - otherwise the cameras will be updated a frame later than they should be.

  • edited September 2023

    I had missed the mainCamera._LateUpdate call in StateHandler's LateUpdate, but unfortunately my experiments with it led to nothing - I tried calling the game camera update just before it and moving it to Update and Fixed Update, but I still end up getting some jitter regardless of the combination. I also tried with and without the Script Execution Order tweaks.

    I have to ask : can you get this working without jitter and with root motion enabled on your end ?

  • I had this issue for literally years using the "Advanced Third Person Camera" (back when it was a separate download) - a few things seemed to trigger the jittering, most notably IK and Root Motion. It was fixed by assigning the camera script a negative value in the Script Execution Order.

    However, I was using the regular Character Controller and not UCC.

  • can you get this working without jitter and with root motion enabled on your end ?

    I'm afraid I'm not currently in a position to be able to test this.

    Justin mentions AC's cameras not being compatible with UCC "due to the how the character controller updates". Do you know what he means by this?

    How exactly are your AC / UCC camera systems linked? The other thread mentions a custom view type - how is that integrating with AC's MainCamera? If you're still using this, try having it reference the AC GameCamera, rather than the MainCamera.

    Separately, try unassigning your GameCamera as the MainCamera's attached camera, and then parent the MainCamera to the GameCamera. This'll be just a test, but it may help shed light on where the issue lies (or doesn't).

  • Thanks to you two for your suggestions ! Here's what I have to report for now :

    -When using the custom AC view type (which you can see on the other thread) and returning the Game Camera's position and rotation, the character can move smoothly with root motion enabled, but not when he's jumping or if root motion is disabled, it somehow inverted the issue !

    -Parenting AC's Main Camera to the Game Camera doesn't solve the issue.

    -I tried giving Game Camera and State Handler a negative Parent Execution Order, but it didn't help. Would you have more precision on that Deckard ?

    Lastly, just to answer your question I mostly tried with a third person combat view and movement types for the ucc character and camera, but dragged the following AC camera into the default camera slot. This results in what you see in the video, it's the method I've been using for my current project for a long time, but as you can see at the moment it needs root motion to be disabled.

    So this problem is still not fixed, but I hope this few pieces of info may help nonetheless. I can wait for a few days for you to test this Chris if you're out of office or something.

  • When using the custom AC view type (which you can see on the other thread) and returning the Game Camera's position and rotation, the character can move smoothly with root motion enabled, but not when he's jumping or if root motion is disabled, it somehow inverted the issue !

    I expect root motion is being disabled temporarily while jumping. There should be a property you can read on the UCC side of things to tell if you root motion is currently inactive - either by unchecking the option manually, or automatically when jumping - and account for it in the script. That is, behave one way when root motion is active, and another when not.

    I mostly tried with a third person combat view and movement types for the ucc character and camera, but dragged the following AC camera into the default camera slot.

    Is the camera moving as a result of a GameCamera's settings, or is the GameCamera "locked" and is moving by being attached/associated with the UCC camera?

    If you're using UCC for the camera behaviour/motion, you could try attaching the MainCamera component to the UCC camera directly, instead of the GameCamera. If you need to switch to another GameCamera later, you could involve a simple custom script to detach it temporarily.

  • Yes, Use Root Motion Position is overriden to false on the Jump ability.

    In the case that I describe the side scrolling camera movement is entirely due to the Game Camera, which is dragged in the Default Camera.

    I fail to see why we would want to attach the Main Camera component to UCC's camera ? If I need AC to use UCC's camera then I just need to do exactly in the demo scene and add a Basic Camera to it.

  • It's an attempt to remove a layer of the update loop. If you're using a custom camera view in UCC that references a GameCamera, and then viewing that with AC's MainCamera, then you've got an update chain of three systems.

    I'm not 100% clear on how your custom camera view is involved, however. If you can share screenshots or a video to show how UCC's Camera system is involved, that'll help clarify things.

    To remove the update chain completely: at runtime, disable the AC MainCamera's Camera and enable the GameCamera's Camera, so that the actual camera that's following the Player is also the one that's rendering. Is that smooth at all times, or only when using root motion, and where is the camera._Update call now?

  • Hello, sorry for not answering sooner, here is a new video that should help clarify things :

    Here are two things I forgot to say in the video :

    -I tried adding Main Camera to the UCC cam, setting the view type to Third Person Combat and dragging the side scrolling game camera into the default slot, but that just recreated the original issue with root motion causing jitter.

    -Everything you see here is using the default Update calls for AC's cameras, nothing was changed or added to Fixed Update or Late Update.

    I hope this clarifies everything, but I can check anything else you want, I'm really open to any suggestion here, my project is seriously affected by this issue at the moment !

  • edited October 2023

    Thank you, I understand the setup now.

    UCC's character and camera systems will update in such a way that they work together correctly - I expect this is why you're getting improved behaviour when using the custom view type to reference the GameCamera.

    AC's MainCamera and your custom view type are essentially doing the same thing - they're copying the position/rotation of the GameCamera each frame, for their own Camera to then render the final image. The difference is in the relative ordering in the Update loop.

    A suggestion: rely on the custom view type and disable the MainCamera - as you do in the video - so that the issue only occurs while jumping. Once again, change the position of the StateHander's camera.Update calls. Ignoring the behaviour while in root motion for the moment, is there a position that causes it to work when the player is jumping?

    Justin's commented on the linked thread:

    I don't think that you'll be able to directly use the Adventure Creator camera with the character controller due to how the character controller updates.

    I think we need an elaboration on this. It's a bit of a black box at the moment, but if you show him the portion of your video that features the custom view type working with root motion / not with jumping, he may be able to offer insight as to the difference at play.

  • I tried putting the camera.Update in Late Update and Fixed Update, but that changed nothing. I made a new post on the Opsive thread about this as you suggested : opsive.com/forum/index.php?threads/jitter-when-using-an-ac-game-camera-to-follow-a-ucc-character.9483/post-49612

  • Hello, here are two more videos I made about similar issues with Cinemachine :

    https://youtube.com/watch?v=YD03nIBcdGQ

    https://youtube.com/watch?v=GUAW_IGTOPY

    The Free Look camera works okay with UCC, but it looks like the other options weren't even tested or this issue would have been spotted before. As you can see in these videos the Dolly Track creates the same issue as AC's Game Camera, even when using the Third Person Cinemachine view type. I thought this piece of information might prove useful.

    Justin is not providing much feedback at the moment. I really feel the need to emphasize the seriousness of the issue here - any dev relying on the combination of UCC and AC for a cinematic game like I am is fucked at the moment, if you don't mind me using this language. Naturally I understand that this is a complex issue mixing two big assets that might take some time to fix, but I can only implore you to take a good look at this when you can. In any case, the integration demo scene will need a side scrolling cam somewhere like the one I showed in the video - this whole issue might have been spotted way earlier with that.

  • Thank you for the investigations, and my apologies for your frustration.

    As promised, I will recreate the issue on my end as soon as I am able - it is to my regret that I am not able help more directly sooner. Please do not take the unavoidable delay - brought on by a medical matter - as evidence that I am not here to see this issue resolved ASAP for you.

    That said, as the behaviour is the same with Cinemachine, I suspect it will still be a case of the solution lying within UCC.

    The Cinemachine Brain's Update Method field may be useful here when testing, as it can be used to control when its position is updated. Your testing does suggest that a reliance on UCC's own camera view system is necessary to get pair smooth camera movement with UCC's root motion. Again, if Justin can elaborate on what he means by "how the character controller updates" being a factor, it may help shed light on this.

  • Sorry to hear about your health issues, wish you a good recovery whatever they are ! Don't worry, I can wait if you're unable to work on this at the moment.

    I tried the different update modes for the Cinemachine Brain as you suggested, while using TP Combat view and the display of a cinemachine cam and while using the Third Person Cinemachine view and display of UCC's camera, but the character was jittering in all cases. The only option I didn't test so far was the Manual Update.

    I also left a new post on the Opsive thread quoting you for more info from Justin.

    opsive.com/forum/index.php?threads/jitter-when-using-an-ac-game-camera-to-follow-a-ucc-character.9483/post-49631

  • I've been taking a look inside UCC's code, and it looks like characters and cameras are updated in FixedUpdate, in that order.

    This might be a bit of a shot in the dark, but I'd hazard a guess that - if you use a custom view type - it'd be best to update the AC GameCamera's position at the time UCC requests it.

    As a test, temporarily comment out AC's camera._Update call in StateHandler, disable the AC MainCamera's Camera, and rely on this custom view type for UCC:

    using UnityEngine;
    using Opsive.Shared.Camera;
    using Opsive.UltimateCharacterController.Camera;
    using Opsive.UltimateCharacterController.Camera.ViewTypes;
    using AC;
    public class ACViewTest : ViewType
    {
        private float m_Pitch;
        private float m_Yaw;
        private Quaternion m_BaseCharacterRotation;
    
        public override bool FirstPersonPerspective { get { return false; } }
        public override float Pitch { get { return m_Pitch; } }
        public override float Yaw { get { return m_Yaw; } }
        public override Quaternion BaseCharacterRotation { get { return m_BaseCharacterRotation; } }
        public override float LookDirectionDistance { get { return 100; } }
    
        public _Camera ACCam;
    
        public override void ChangeViewType(bool activate, float pitch, float yaw, Quaternion baseCharacterRotation)
        {
            if (activate)
            {
                m_Pitch = pitch;
                m_Yaw = yaw;
                m_BaseCharacterRotation = baseCharacterRotation;
            }
        }
    
        public override Quaternion Rotate(float horizontalMovement, float verticalMovement, bool immediateUpdate)
        {
            return ACCam.transform.rotation;
        }
    
        public override Vector3 Move(bool immediateUpdate)
        {
            ACCam._Update ();
            return ACCam.transform.position;
        }
    
        public override Vector3 LookDirection(Vector3 lookPosition, bool characterLookDirection, int layerMask, bool useRecoil, bool includeMovementSpread)
        {
            return m_BaseCharacterRotation * Vector3.forward;
        }
    }
    

    This will update the AC GameCamera as the view type requests its position - does that offer any improvement?

  • Hello, thank you very much for trying, but I'm sorry to report that commenting the camera update in State Handler and using this view type does remove the jitter. However, in comparison when using the AC Main Camera's Camera component in this situation the jitter seems heavier and occurs with and without root motion, I hope this piece of information may be useful. Here is a new video showing all this :

    https://youtube.com/watch?v=9vx9A2I_ASw

    Thanks again for your help, I'll post this on the Opsive forum as well.

  • You're getting more jitter with AC MainCamera because it's being updated in LateUpdate, which will be out of sync when transferring GameCamera values from FixedUpdate.

    Is there any difference if you set the GameCamera's "Follow speed" to zero and/or enable Interpolation on the character's Rigidbody?

  • A third test, if the above makes no difference:

    Switch back to AC's StateHandler updating the camera, and then replace GameCamera's line 212:

    ? Vector3.Lerp (Transform.position, desiredPosition, Time.deltaTime * dampSpeed)
    

    with:

    ? Vector3.Lerp (Transform.position, desiredPosition, 1 - Mathf.Pow(1f - Mathf.Clamp01 (dampSpeed), Time.deltaTime))
    

    Does that have any effect?

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.