Hi All,
I’m using a character controller which uses physics so all movement and momentum is handled in FixedUpdate. My animator is set to Animate Physics too. I’m using a state machine so have scripts (behaviors) on my animation states and to my understanding OnStateUpdate will run in FixedUpdate as I’m using Animate Physics on the animator.
Right now, in terms of controlling the character only my inputs (button presses etc.) are handled in Update.
So, logic that feeds the animator i.e. should the character jump, turn, roll etc. is also handled in FixedUpdate. I figure this makes sense as the animator is running on FixedUpdate. But I’ve read only forces should be handed in FixedUpdate. I’ve tried putting the logic in Update, and tbh I can’t see a difference, but I’d like to do it correctly as I’m sure I’ll otherwise run into issues. Should I even consider LateUpdate for this logic??
Based on the info above, which update loop (normal?, fixed?, late?) should I be using for character behavior logic that isn’t directly controlling the forces of the character?
Really appreciate the guidance!! I read a lot online about this topic and see a lot of contradictory advice and couldn’t find anything specifically for my use case.
Thanks!
This graph could answer some of your questions:
The most important thing is to only do checking of edge-trigger inputs such as Input.GetKeyDown()
in Update();
, otherwise you will miss inputs.
Thanks. Yes, I have my inputs handled in Update(). I’m still a little confused as to which update to have my logic in that feeds the animator. As my Animator is using Animate Physics so gets updated on fixed update, should I keep my logic in Fixed Update? Or am I missing something?
It’s an interesting question, because now you have these state change callbacks coming to you on Fixed, whereas some logic has got to be in Update()… hmm.
Intuition makes me speculate that if you only gather edge-trigger input in Update(), saving such events to a queue, then process everything in FixedUpdate(), you’ll have the least chance of event-stagger issues.
But just to be sure, you might want to create some degenerate setups and test out critical multi-event interactions, such as making your Update() vs FixedUpdate() ratios unusually large (both directions) to increase your chance of problems and see if anything misbehaves.
Thank you! I also found this and while old, it explains update vs fixed update really well (Timesteps and Achieving Smooth Motion in Unity — KinematicSoup Technologies Inc.). This article tends to agree with your instinct of putting everything in FixedUpdate except user inputs and graphical stuff like VFX. Also, it looks like I can use interpolate on my RBs to help with any jittering. I’ll continue to test but will try this.
Thanks again for the thoughts! Much appreciated!