Search Unity

  1. Unity Asset Manager is now available in public beta. Try it out now and join the conversation here in the forums.
    Dismiss Notice
  2. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  3. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Control over FixedUpdate invocation

Discussion in 'Physics Previews' started by Prodigga, Feb 19, 2019.

  1. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,123
    Hi there

    I undeeunder that the FixedUpdate and the Physics Simulation steps don't "truly" have anything to do with one another, so calling Physics.Simulate manually doesn't trigger fixed updates. However in reality a lot of code is placed into the fixed update that has a direct affect on the physics Simulation, to the point where simulating the physics manually without invoking FixedUpdate makes no sense. I do not know of many games that work purely based on physics, with no adjustments required before simulation steps. Scenarios like predicting where a billiard ball will end up happens to be one of the few situations where it works, but even this falls apart when you start considering "gamey" mechanics that might alter the simulation every fixed update.

    Feels like Physics.Simulate is half the solution. Will we be given control over when our fixed updates are invoked? Preferably some way to simulate the fixed update of all entities in a specific physics scene. (Default physics scene, or scene specific physics scene.) Preferably with some way to pass in our own delta time.
     
  2. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    If you trigger physics simulation always manually, you don't really need FixedUpdate as you can implement similar functionality yourself. In past when we couldn't run simulate ourselves, FixedUpdate made way more sense as it was literally ran for each Physics simulation run.

    If you need to control this yourself, just put your physics script to run first on script execution order and implement something like in the last example here: https://gafferongames.com/post/fix_your_timestep/. Note however that due to things being executed from main thread, you'll be very likely just running bunch of simulation steps in series, just like Unity does by default on FixedUpdates...
     
  3. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,123
    That is fine if I have control over all the code, but won't be the case when using some middleware. (Which is the issue I am facing now).

    Right now, I can download character controllers and such that 'just work' with unity physics because they do all their work in FixedUpdate, and Unity invokes FixedUpdate on all scripts for each physics update. None of these products work in projects that manually tick the physics, for no reason other than the fact that we dont have the ability to invoke fixed update ourselves. Middleware developers can replace all of their Physics.* queries with
    gameObject.scene.GetPhysicsScene().* queries, so that their scripts work with different physics scene, but there is no way for middleware developers to ensure their products work with manually simulated scenes, since we can't invoke FixedUpdate.

    Allowing us to invoke FixedUpdate would mean all this middleware could work with little work from the middleware developers (just need to change to using PhysicsScene physics querys instead of the ones of the Physics class). They can still use FixedUpdate in their scripts to run custom behaviour.

    An ugly work around is to invoke FixedUpdate via reflection, which works, but FixedUpdate is still automatically executed whether autosimulate is enabled or not.. So it means that any middleware I download that uses the FixedUpdate will be performing work on every FixedUpdate even if the physics simulation is paused. If I could just be given total control over the FixedUpdate loop (Something like myPhysicsScene.autoFixedUpdate = false) then none of this would really be a problem. :)
     
    Last edited: Feb 20, 2019
  4. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,123
  5. yant

    yant

    Unity Technologies

    Joined:
    Jul 24, 2013
    Posts:
    595
    I believe there is lot of various code running in devs' FixedUpdates these days for right or wrong reasons. Physics, sounds, animations, more. I'm afraid it's not that safe to make assumptions about its structure and actual requirements. Any frequency tweak would potentially cause unexpected performance or behavioural consequences.

    My take on that would be that all the popular physics packages should provide explicit update interfaces instead of pretending extra nice by listening to events that aren't possible to control without affecting other users. I understand it might not be the case as we speak, but I encourage you to talk to the package authors directly and let them know about the problem.

    anthony
     
    Edy likes this.
  6. M_R

    M_R

    Joined:
    Apr 15, 2015
    Posts:
    559
    @Prodigga you could take the Player Loop, strip the FixedUpdate step, and overwrite it back.

    though it's a hack and conflicts with ECS (it does the same trick to inject the systems update)

    (idk if you can also directly invoke the updateFunction of the system)
     
  7. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,123
    @yant thanks for the reply, but it is a shame that there is no way for developers to write code that will "universally" work with a manually simulated physics system. There is no physics update callback for people to hook into. The standard mono behaviour lifestyle events allow developers to write generic assets that work in other people's projects. Now, there is no similar "common ground" for physics dependant functionality, so it is going to be a bit of a mess with different developers creating different ways to handle this issue. Maybe we need a new callback that is PrePhysicsSimulate or PostPhysicsSimulate for plugin developers to move their code into. This way, we have a common ground and we can all develop assets for a system that is consistent on everyone's end. Developers will be aware that these new methods might get invoked at any time and at any rate (IE autoSimulate physics, manual simulate physics, etc) so they can write code that works correctly in those environments (which, for a lot of Simulation code, isn't hard and requires no changes.).

    @M_R thanks for the suggestion, I am in talks with the developer for the plugin I am using, so I do have a way forward. For now I am inheriting the plugin developers behaviour, suppressing FixedUpdate by implementing an empty copy in my class, and invoking the bases fixed update via reflection.
     
  8. Prodigga

    Prodigga

    Joined:
    Apr 13, 2011
    Posts:
    1,123
    Using it for multiplayer, where the client applies their input locally and if the server responds with a correction, the user winds back the simulation the the point in time where the error was, and resimulates back to current time with the correction applied.