Obi Solver changes gravity for rigidbodies ?

[VincentAbert]

Hello ! I'm getting more and more comfortable with Obi Rope, but a few things are still a bit complex for me :

first of all, the obi solver seems to change all the physics in my scene : I have not changed the default gravity in Unity (which is the same as the default obi solver value), but whenever there is an active solver in my scene, my character (rigidbody based) doesn't jump as high, as do any rigidbody when added a force ?

Another thing that doesn't make sense to me is the fact that you have to add an obi collider for a dynamic particle attachment : since the attachment will probably intersect with the end of the rope, it seems absurd to add a collider to it ?

Thanks a lot !

[josemendez]

Hi Vincent,

Solvers do not change the default physics settings in any way. There's no reason for your character to jump less when a solver is present in the scene, unless there's particles attached to the character and you're jumping by applying a force instead of an acceleration. F = ma, adding particles to the character increases its mass, so jump forces will result in less upwards acceleration. This is the correct and expected behavior: it's like jumping while wearing chainmail.

ObiCollider is basically a wrapper over Unity's Collider. It lets Obi "know" about Unity's physics, so anytime forces of any kind must be interchanged between Obi particles and a collider/rigidbody, a ObiCollider must be present to act as a mediator between Obi and Unity. That's why both collisions and dynamic attachments require ObiColliders: particles are able to apply forces to the object, be it as a result of collisions, or an attachment. In static attachments there's no forces involved (particle positions are directly set, like in a parent-child transform relationship), so no ObiCollider required.

[VincentAbert]

Hi Vincent,

Solvers do not change the default physics settings in any way. There's no reason for your character to jump less when a solver is present in the scene, unless there's particles attached to the character and you're jumping by applying a force instead of an acceleration. F = ma, adding particles to the character increases its mass, so jump forces will result in less upwards acceleration. This is the correct and expected behavior: it's like jumping while wearing chainmail.

ObiCollider is basically a wrapper over Unity's Collider. It lets Obi "know" about Unity's physics, so anytime forces of any kind must be interchanged between Obi particles and a collider/rigidbody, a ObiCollider must be present to act as a mediator between Obi and Unity. That's why both collisions and dynamic attachments require ObiColliders: particles are able to apply forces to the object, be it as a result of collisions, or an attachment. In static attachments there's no forces involved (particle positions are directly set, like in a parent-child transform relationship), so no ObiCollider required.


That is extremely strange then, because not only my character doesn't jump has high (simply disabling the solver while playing fixes it), but I have an effect where I can "blow a wall open". The way this works is that the wall is one mesh, and upon impact it is replaced by a "broken down" version made with multiple rigidbodies (which are instantiated at runtime, meaning there's no way they are attached to anything), and when the solver is enabled the instanciated rigidbodies' velocity is much less intense.

Yes that's what I understood, it just seemed strange to me. That means that, to avoid weird behaviour I have to change the phase. Thank you for that

[josemendez]

That is extremely strange then, because not only my character doesn't jump has high (simply disabling the solver while playing fixes it), but I have an effect where I can "blow a wall open". The way this works is that the wall is one mesh, and upon impact it is replaced by a "broken down" version made with multiple rigidbodies (which are instantiated at runtime, meaning there's no way they are attached to anything), and when the solver is enabled the instanciated rigidbodies' velocity is much less intense.

If you want I can take a look at it, but that seems really strange. Simulation of rigidbodies is performed by Unity and Obi has no power over that.

Make sure it's not a timestep length-related thing though: enabling the solver will cause frames to take a bit longer to render, so if you are incorrectly applying velocities/forces or other time-dependent stuff not taking Time.deltaTime or fixedDeltaTime into account, then of course enabling the solver (or making the game heavier in any way) will have an effect on your physics. The default AddForce method already takes timestep length into account, so this only applies if you're doing it in any other way. Also keep in mind that if you're using substepping, that will update physics multiple times per timestep.

Yes that's what I understood, it just seemed strange to me. That means that, to avoid weird behaviour I have to change the phase. Thank you for that

Same thing applies to Unity's joints: If you attach two rigidbodies using joints, you have the option to enable/disable collisions between them. Only difference is that for joints collisions are disabled by default, and you can turn them on. In Obi it's not just two bodies though, there might be multiple particles inside a collider, so collisions are turned on by default and you can turn them off on a per-particle basis using phases. See: https://docs.unity3d.com/Manual/class-Co...Joint.html

[VincentAbert]

If you want I can take a look at it, but that seems really strange. Simulation of rigidbodies is performed by Unity and Obi has no power over that.

Make sure it's not a timestep length-related thing though: enabling the solver will cause frames to take a bit longer to render, so if you are incorrectly applying velocities/forces or other time-dependent stuff not taking Time.deltaTime or fixedDeltaTime into account, then of course enabling the solver (or making the game heavier in any way) will have an effect on your physics. The default AddForce method already takes timestep length into account, so this only applies if you're doing it in any other way. Also keep in mind that if you're using substepping, that will update physics multiple times per timestep.



Same thing applies to Unity's joints: If you attach two rigidbodies using joints, you have the option to enable/disable collisions between them. Only difference is that for joints collisions are disabled by default, and you can turn them on. In Obi it's not just two bodies though, there might be multiple particles inside a collider, so collisions are turned on by default and you can turn them off on a per-particle basis using phases. See: https://docs.unity3d.com/Manual/class-Co...Joint.html

Ooookay so whilst shooting a video to show you the issue, I tried reducing the substeps, and it seems indeed that with 1 substep, the physics are the same as without the solver, I didn't think that would impact things that much. But then, that means I either have to run the sim with 1 substep or to run my whole game with what I use inside Obi Rope and adapt all my physics ? That would make the whole game more intensive for no reason... Damn.

[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

[VincentAbert]

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

Thank you for the amazingly detailed support man, I really appreciate it (on my way to the five star review straight away, obviously).

Since ropes will be ponctual additions to some levels, I think it makes more sense to just play with iteration, even if that ends up with a slightly higher cost. The main reason I had increased the substeps was because, even when the rope was pretty stretched, it was not in a straight line, and rather bouncy. To change that with constraints, I guess I'd have to increase the distance constraint's iteration ?

Thanks again for everything,

Vincent

[josemendez]

Thank you for the amazingly detailed support man, I really appreciate it (on my way to the five star review straight away, obviously).

Since ropes will be ponctual additions to some levels, I think it makes more sense to just play with iteration, even if that ends up with a slightly higher cost. The main reason I had increased the substeps was because, even when the rope was pretty stretched, it was not in a straight line, and rather bouncy. To change that with constraints, I guess I'd have to increase the distance constraint's iteration ?

Thanks again for everything,

Vincent

Thanks! reviews are greatly appreciated

Distance constraints are in charge of keeping rope length, so if your rope is too elastic, using more distance constraint iterations will improve that.

You can also try using a slightly shorter timestep. This is a global parameter in Unity, found in the Time settings with the name of "fixed timestep":
https://docs.unity3d.com/Manual/class-TimeManager.html

This is actually the value you get when calling Time.fixedDeltaTime, and it is the duration in seconds of a single timestep. If using substepping is too intensive, you can try reducing the timestep a little bit for an extra oomph. For instance, a timestep of 0.02 seconds and 2 substeps, is the same as a timestep of 0.01 seconds and a single substep. You can instead use a timestep of 0.015 for the equivalent of "1 and a half" substeps, if that makes sense. Still, this affects all physics in the scene (both Obi and Unity).