x


FixedUpdate after Animation - Physics Loop

It seems that the built in animations play after other scripted FixedUpdate loops when 'Animate Physics' is selected - resulting in funny looking behaviour when moving a character in relation to these objects.

Is there a way to enforce the order animations will play in relation to another FixedUpdate loop? And if not, does it always execute after other FixedUpdate loops?

Since there isn't a function being explicity called, I'm not sure if I can control the call order in the normal way (calling a custom update function via some manager script).

I suppose I could 'fake' it by having the animated graphics lag a frame, but that's a bit funky --- this would be the code for that:

public class AnimatedPhysicsThing : MonoBehaviour {

    public Transform physics;
    private Transform graphics;
    private Vector3 lastPosition;

    private void Awake(){
        graphics = transform;   
    }


    private void FixedUpdate(){
        graphics.position = lastPosition;
        lastPosition = theTransform.position;   
    }
}
more ▼

asked Dec 10 '09 at 10:06 PM

Brian Kehrer gravatar image

Brian Kehrer
2.8k 9 11 50

(comments are locked)
10|3000 characters needed characters left

4 answers: sort voted first

Well, in case anyone was wondering here is how you might implement LateFixedUpdate(), if you need it.

private void FixedUpdate(){
    lateFixedUpdate = true; 
}
private void LateUpdate(){
    if(lateFixedUpdate){
        lateFixedUpdate = false;
        // LateFixedUpdate code here
    }
}

Fundamentally, however, I had the animations lag a frame to solve the aforementioned issues - using similar code to that posted in the question.

I'm not sure I understand why one would want Animated physics objects to move after FixedUpdate, it seems like they should move first, and then run FixedUpdate() on everything else, otherwise the graphics appear to be a frame behind.

more ▼

answered Mar 04 '10 at 01:53 PM

Brian Kehrer gravatar image

Brian Kehrer
2.8k 9 11 50

If you want to do things after each FixedUpdate(), this is not the way to do it. Due to the fact that Update() and FixedUpdate() run at different update rates, you'll miss some FixedUpdate() calls. I worked around the problem by centralizing my scheduling stuff in one script's FixedUpdate() and using the observer pattern to let other scripts perform the needed actions.

Nov 17 '10 at 02:16 PM PatHightree

Yeah, I eventually noticed this too, if your frame rate bogs and you end up with multiple fixed update calls / frame. We've also implemented a global update ordering class.

However since this code (O.P) deals with graphics updating, it is still correct, since no matter how many times fixed update runs, we only care that it has run, not catching each iteration. Great point though.

Nov 18 '10 at 01:14 AM Brian Kehrer
(comments are locked)
10|3000 characters needed characters left
more ▼

answered Dec 20 '09 at 10:46 PM

Lucas Meijer 1 gravatar image

Lucas Meijer 1 ♦♦
8k 19 43 85

LateUpdate() refers to post-Update. Now that animations can be synchronized with physics (but only after FixedUpdate()), I need LateFixedUpdate(). Surely I could create LateFixedUpdate() from LateUpdate(), but that seems silly.

Dec 21 '09 at 04:35 PM Brian Kehrer
(comments are locked)
10|3000 characters needed characters left

take a look at Update Order and as Lucas said use LateUpdate or LateFixedUpdate for what you want.

more ▼

answered Mar 04 '10 at 09:35 PM

Ashkan_gc gravatar image

Ashkan_gc
9.1k 33 56 117

The problem is Animated physics objects (moving platforms) seem to move after FixedUpdate, which means the physics is a frame behind the graphics, effectively.

Mar 05 '10 at 02:33 PM Brian Kehrer
(comments are locked)
10|3000 characters needed characters left

I have a similar situation.

I have a sensitive bit of gameplay code that needs to: run logic tick anims update physics

Since animation seems to tick between update and lateUpdate, everything is golden under good conditions. I would like to move the logic to fixedUpdate (and eat the cost of updating animation) but I have no way to apply pre and post- anim logic in the fixed case.

I've tried a few work arounds, but it gets really messy if these things are decoupled. Since LateFixedUpdate does not exist, has anyone really implemented a decent animation-dependent physics tick solution?

more ▼

answered Feb 08 '11 at 06:43 AM

Burke gravatar image

Burke
1 2

My current work around goes like this:

Late Update (post anim) Set target bones based on terrain following Update IK //now it will look right

Fixed Update: state logic, physics, blah SAMPLE (reset the animation back to before I messed with it) //now it will physics right Terrain Following

I forgot that Sample was an immediate mode access into the animation. All sorted

Feb 08 '11 at 06:11 PM Burke

that looked better with my formatting

Feb 08 '11 at 06:11 PM Burke
(comments are locked)
10|3000 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Topics:

x5086
x3793
x1879

asked: Dec 10 '09 at 10:06 PM

Seen: 3122 times

Last Updated: Dec 10 '09 at 10:11 PM