Help Unity physics interaction on v7.0

[goosejordan]

Hi! I'm trying to simulate rope climbing equipment in a VR environment. It involves a LOT of interaction between Unity physics and Obi particles.

This is an older video of what I'm doing using ObiRope 6

I made a custom attachment system that can feed the rope forward and backwards with friction. The rope needs to be high resolution so there are a lot of pin transforms involved.
I got the physics to work pretty nicely but I ran into a performance ceiling.
I thought I would try the GPU accelerated backend on the beta and sure enough performance is vastly improved! Great work on that improvement! And thanks a lot, that will be important for my game.

However, I'm experiencing some drawbacks. Right away it feels like the rope has much more inertia like it is very heavy or damped. The syncing with Unity physics seems to be different and lags after the object it is pinned to. Or it may be the rididbodies lagging after the rope...

I see there is an option for sync or async but switching that only lowered my framerate.

What is my best option here? Would updating Unity physics on Update instead of FixedUpdate help? Or would it be cleaner to try and model the equipment and hands purely as particles and constraints and position the object onto the particles representing it?

---

Oh, just realized that 7.0 is out of beta. I should try updating but how much can that affect?

[goosejordan]

Bumping this, I really need some input on what the best way forward is. Is my question too vague? I can provide more info such as a video to better explain the limitation I'm seeing.

[josemendez]

Hi there!

Rigidbody interaction hasn’t changed at all in Obi 7. A few parameters have been moved around though, most notably the amount of substeps: it has moved from ObiFixedUpdater (that no longer exists) to the ObiSolver component. Also, a max amount of steps per frame has been added to solvers, which would previously use Unity’s global maximum allowed timestep.

Assuming the amount of substeps in your solver are the same as in your old ObiFixedUpdater and that the maximum amount of steps is equal to your max allowed timestep divided by your fixed timestep, behavior should be the same.

Let me know otherwise, and in that case, a video of the behavior you’re getting with 7 sould certainly help .

Kind regards,

[goosejordan]

Hi there!

Rigidbody interaction hasn’t changed at all in Obi 7. A few parameters have been moved around though, most notably the amount of substeps: it has moved from ObiFixedUpdater (that no longer exists) to the ObiSolver component. Also, a max amount of steps per frame has been added to solvers, which would previously use Unity’s global maximum allowed timestep.

Assuming the amount of substeps in your solver are the same as in your old ObiFixedUpdater and that the maximum amount of steps is equal to your max allowed timestep divided by your fixed timestep, behavior should be the same.

Let me know otherwise, and in that case, a video of the behavior you’re getting with 7 sould certainly help .

Kind regards,

Thanks, your reply helped me get past the fixation that the simulation would run differently!
I pushed through and found the issues and a good setting. Another library (for hand interaction) was modifying the fixed timestep length as per a setting. This would work in the previous version getting its updates from there. Also found that some of the instability came from the profiler being active and the good ol' inspector window rendering.

A bit of an odd solution on the other library to modify fixed timestep. I see the need for it, VR hand physics look smoother if it updates with the framerate, but modifying fixed timestep is not the right way  
It is no longer possible to update Obi with the framerate, right?

[josemendez]

Another library (for hand interaction) was modifying the fixed timestep length as per a setting. This would work in the previous version getting its updates from there.

Obi still gets its fixed timestep from Unity's fixed timestep value. What it doesn't use is Unity's maximum allowed timestep, that puts a limit on the amount of times FixedUpdate() can be called per frame. Instead each solver has its own maximum amount of steps, this allows you to have finer control over how much budget is spent on particle simulation.

A bit of an odd solution on the other library to modify fixed timestep. I see the need for it, VR hand physics look smoother if it updates with the framerate, but modifying fixed timestep is not the right way  

Not an ideal solution, agreed. I guess they wanted to both have the hand update in sync with physics (probably for rigidbody interaction) but at the same time be as smooth as possible, so they just synced the fixed timestep to the framerate.

In these cases using interpolation is a better solution, as it allows you to have both smooth visuals and an adequate timestep.

It is no longer possible to update Obi with the framerate, right?

Depends on what you mean by "with the framerate". If you mean using a variable timestep (like in Obi 6 when using ObiLateUpdater instead of ObiFixedUpdater) then no. This was a deliberate choice, since using a variable timestep tends to make simulation unstable and doesn't allow for async simulation (keeping worker threads busy in-between frames, which is where most of the performance gains in Obi 7 come from).

If you mean having Obi updated exactly once per FixedUpdate(), then yes: just set the ObiSolver's "max steps per frame" to max allowed timestep / fixed timestep (or just a really high value).

kind regards,