14-10-2020, 12:50 PM
(This post was last modified: 14-10-2020, 12:55 PM by josemendez.)
Substepping works by chopping up each timestep into several smaller steps. This greatly increases stability and simulation quality.
Constraint iterations can be used for the same purpose, but they don't punch as hard as substeps. This means 4 iterations have roughly the same cost as 4 substeps for Obi, but the results will be worse. Also, iterations can be applied to specific constraint types only, which lets you fine-tune where to spend resources. Substepping affects the entire engine.
Iterations/substeps are very basic physics concepts common to all engines, but its not uncommon to be unfamiliar with them or even oblivious to their existence until you come across an issue related to them.
If you have interaction between Obi particles and rigidbodies (two-way collisions, attachments), then both engines -Obi and Unity- must step in sync. Thats's what the "substep unity physics" checkbox does. You can't have several multiple engines interacting with each other if each one is updated at different times as that would cause jittering/spazzing and all sorts of issues. See: http://obi.virtualmethodstudio.com/tutor...aters.html
Obi amortizes collision detection over multiple substeps: it only generates contact pairs during the first substep of the frame, then reuses the same contacts for all following substeps. This makes substepping in Obi relatively lightweight. Unfortunately, Unity does not do this, and that makes substepping much costlier in Unity as the entire collision detection pipeline is run for each individual substep. If you have a very physics intensive scene with just a few Obi actors, enabling substepping can have a large impact on performance. In this case it is better to either:
- Use more iterations instead of more substeps.
- Use separate physics scenes, and only apply substepping to the one where Obi needs to interact with things. This is a more advanced solution and requires you to subclass ObiUpdater and use multi-scene physics. See: https://docs.unity3d.com/Manual/physics-...scene.html
Constraint iterations can be used for the same purpose, but they don't punch as hard as substeps. This means 4 iterations have roughly the same cost as 4 substeps for Obi, but the results will be worse. Also, iterations can be applied to specific constraint types only, which lets you fine-tune where to spend resources. Substepping affects the entire engine.
Iterations/substeps are very basic physics concepts common to all engines, but its not uncommon to be unfamiliar with them or even oblivious to their existence until you come across an issue related to them.
If you have interaction between Obi particles and rigidbodies (two-way collisions, attachments), then both engines -Obi and Unity- must step in sync. Thats's what the "substep unity physics" checkbox does. You can't have several multiple engines interacting with each other if each one is updated at different times as that would cause jittering/spazzing and all sorts of issues. See: http://obi.virtualmethodstudio.com/tutor...aters.html
Obi amortizes collision detection over multiple substeps: it only generates contact pairs during the first substep of the frame, then reuses the same contacts for all following substeps. This makes substepping in Obi relatively lightweight. Unfortunately, Unity does not do this, and that makes substepping much costlier in Unity as the entire collision detection pipeline is run for each individual substep. If you have a very physics intensive scene with just a few Obi actors, enabling substepping can have a large impact on performance. In this case it is better to either:
- Use more iterations instead of more substeps.
- Use separate physics scenes, and only apply substepping to the one where Obi needs to interact with things. This is a more advanced solution and requires you to subclass ObiUpdater and use multi-scene physics. See: https://docs.unity3d.com/Manual/physics-...scene.html