Simulate a solid steel chain

[zhuchun]

Hi,

I'm new to Obi Rope and have finished the doc, But don't know how to simulate a solid steel chain without any elasticity.

Any help would be greatly appreciated!

Cheers,
Zhu Chun

[josemendez]

Hi,

I'm new to Obi Rope and have finished the doc, But don't know how to simulate a solid steel chain without any elasticity.

Any help would be greatly appreciated!

Cheers,
Zhu Chun

Hi there, welcome to the forums!

What you ask for is impossible to achieve in the general case, in any physics engine.

Realtime physics engines perform several iterations of any given problem, getting closer to the exact solution each time. The more complex the problem, the larger the amount of iterations required to get the exact solution.

In the scenario you mention:

- The problem: get the chain to be inextensible.
- Problem complexity: amount of links in the chain--> Longer chains require more iterations to appear inelastic--> Longer chains are slower to simulate.

In Obi, you can increase the amount of iterations in ObiSolver->Distance constraint parameters->iterations. It is not uncommon to have between 20-50 distance iterations for inelastic ropes. Most of the time you can get a chain to look pretty inelastic by increasing iterations and/or decreasing Unity's physics timestep, but longer chains or chains that must support heavy weights will still look elastic again once certain force thresholds are surpassed.

You might benefit from reading a bit about physics simulation in general. I've been writting a series of blog posts on the subject, aimed at giving beginners a overview of the entire realm before focusing on Obi in particular. The last one talked about solvers and convergence, which is a relevant topic:
http://blog.virtualmethodstudio.com/2017...3-solvers/

[zhuchun]

Hi there, welcome to the forums!

What you ask for is impossible to achieve in the general case, in any physics engine.

Realtime physics engines perform several iterations of any given problem, getting closer to the exact solution each time. The more complex the problem, the larger the amount of iterations required to get the exact solution.

In the scenario you mention:

- The problem: get the chain to be inextensible.
- Problem complexity: amount of links in the chain--> Longer chains require more iterations to appear inelastic--> Longer chains are slower to simulate.

In Obi, you can increase the amount of iterations in ObiSolver->Distance constraint parameters->iterations. It is not uncommon to have between 20-50 distance iterations for inelastic ropes. Most of the time you can get a chain to look pretty inelastic by increasing iterations and/or decreasing Unity's physics timestep, but longer chains or chains that must support heavy weights will still look elastic again once certain force thresholds are surpassed.

You might benefit from reading a bit about physics simulation in general. I've been writting a series of blog posts on the subject, aimed at giving beginners a overview of the entire realm before focusing on Obi in particular. The last one talked about solvers and convergence, which is a relevant topic:
http://blog.virtualmethodstudio.com/2017...3-solvers/

Thank you! Thank you for both this very detailed answer and that blog post!

At first, I thought Distance/Tether constraints can have a max distance and enable projection mode like the native physics engine. Increasing iteration sounds promising in my game scenario.

[josemendez]

Thank you! Thank you for both this very detailed answer and that blog post!

At first, I thought Distance/Tether constraints can have a max distance and enable projection mode like the native physics engine. Increasing iteration sounds promising in my game scenario.

Hi! You're welcome

Obi uses constraint projection by default. This is because it relies on position-based dynamics, a simulation paradigm that directly moves bodies around and derives velocities from the resulting position differences.

"Regular" engines constrain velocities instead of positions. When enabling projection, you allow them to cheat a bit and force positions/orientations to be the correct ones for each constraint, which reduces the amount of error. However velocities and positions can get out of sync by doing this so momentum is no longer conserved. Obi works the other way around: first it calculates the correct positions of each body, then derives velocities from that. This way both positions and velocities are correct at the end of each physics step, and the resulting simulation is much more stable.

From PhysX's docs:

Under stressful conditions, PhysX' dynamics solver may not be able to accurately enforce the constraints specified by the joint. PhysX provides kinematic projection which tries to bring violated constraints back into alignment even when the solver fails. Projection is not a physical process and does not preserve momentum or respect collision geometry. It is best avoided if practical, but can be useful in improving simulation quality where joint separation results in unacceptable artifacts.

Both PhysX and Obi use iterative solvers, so both have the same limitations in regards to completely stiff constraints. However PhysX solves constraints by modifying velocities, and Obi does it by modifying positions which is beneficial for stability.

kind regards,