22-06-2020, 08:03 AM
(This post was last modified: 22-06-2020, 08:07 AM by josemendez.)
Hi there,
Nope, as you pass in the amount of time simulated by the call. Calling Physics.Simulate(0.2) advances the simulation the same amount of time as calling Physics.Simulate(0.1) twice.
No, this is automatically done by the FixedUpdater. Whenever substep Unity physics is enabled, auto simulation is disabled, as Physics.Simulate() is called explicitly. Also, Keep in mind this quote from Unity's docs: https://docs.unity3d.com/ScriptReference...ulate.html
There's two reasons why we have an explicit "substep" parameter instead of just relying on using a smaller 'global' fixed timestep:
- We can decouple Obi's update from Unity's own physics update. This is important when you have actors (ropes, cloth, etc) that need to be updated using a smaller timestep than the rest of the physics.
- Collision detection (finding potential contacts) is performed only once per step, and amortized over all substeps in the frame. This means that we can perform many substeps, without paying the cost of collision detection for each one. This makes substeps much more efficient than using a smaller global timestep, and more efficient than iterations, as they improve convergence a lot more while being only slightly more expensive. This idea is based on the "small steps for physics simulations" academic research article: http://mmacklin.com/smallsteps.pdf
So, reducing Unity's physics timestep and disabling substepping would result in the same behavior, at much lower performance (as collision detection would be fully performed every timestep).
Quote:Doesn't calling Physics.Simulate in addition to the normal unity physics update loop essentially cause Unity's physics simulation to proceed faster than realtime?
Nope, as you pass in the amount of time simulated by the call. Calling Physics.Simulate(0.2) advances the simulation the same amount of time as calling Physics.Simulate(0.1) twice.
Quote:Am I supposed to disable Physics.autoSimulation to use substepping with a FixedUpdater?
No, this is automatically done by the FixedUpdater. Whenever substep Unity physics is enabled, auto simulation is disabled, as Physics.Simulate() is called explicitly. Also, Keep in mind this quote from Unity's docs: https://docs.unity3d.com/ScriptReference...ulate.html
Quote:Calling Physics.Simulate does not cause FixedUpdate to be called.
Quote:Wouldn't I effectively get the same result from reducing Unity's physics timestep rather than doing the complicated process of substepping Unity physics and then replacing all of my FixedUpdate calls with OnBeginStep callbacks? (Or am I supposed to have FixedUpdate in addition to OnBeginStep?)
There's two reasons why we have an explicit "substep" parameter instead of just relying on using a smaller 'global' fixed timestep:
- We can decouple Obi's update from Unity's own physics update. This is important when you have actors (ropes, cloth, etc) that need to be updated using a smaller timestep than the rest of the physics.
- Collision detection (finding potential contacts) is performed only once per step, and amortized over all substeps in the frame. This means that we can perform many substeps, without paying the cost of collision detection for each one. This makes substeps much more efficient than using a smaller global timestep, and more efficient than iterations, as they improve convergence a lot more while being only slightly more expensive. This idea is based on the "small steps for physics simulations" academic research article: http://mmacklin.com/smallsteps.pdf
So, reducing Unity's physics timestep and disabling substepping would result in the same behavior, at much lower performance (as collision detection would be fully performed every timestep).