How to set the specific rigidbody's iteration count?

[Pro-Ly]

I know there's a way to set the whole simulation's iteration count. But what if I just want to set the specific rigidbody's iteration count? For example, a player hold a rope playing in the ground. In this case, I just want the rope to calculate more but not the whole world. Is there's a way to do this? (Of course the rigidbody that are connected by constraints should also be influenced) @RossNordby

[RossNordby]

Per-body iterations/substepping is not currently possible. It's something I've considered, but it comes with some pretty major costs that need to be mitigated.

The workaround is typically some modified constraint configuration. For ropes in particular, consider adding skip connections as in the RopeStabilityDemo.

[Pro-Ly]

Just curious, why is that? I've been used this API in PhysX. I thought that was a solved issue.

[RossNordby]

It's not conceptually difficult, it's just a practical complexity/value issue.

1. All constraints are batched for parallel execution. This is both at the level of threading, but also at the level of AOSOA layouts for vectorization. Within a batch, all the constraint bundles are contiguous and easy to load for the vectorized solver. This is part of why bepuphysics2's solver is so much faster.
2. The solver doesn't care about whether bodies are in different "islands" or not; it'll parallelize everything through batching regardless. Having larger individual batches is useful for hardware utilization- having a ton of partial bundles means a ton of empty SIMD lanes.
3. Because of the contiguous AOSOA representation, using islands creates a large amount of complexity in shuffling constraints between islands on split/merge operations. It can actually cause measurable frametime spikes. There are some incremental options, but they come with some tradeoffs (mainly a ton of developmental complexity).
4. In the worst case, a body/constraint configured with high iterations/substeps would promote other large islands it interacts with. This could create massive performance cliffs. Not performing the same number of substeps/iterations for constraints that can interact would result in problems: the unupdated constraints would have no influence while the rope (or whatever) continues to receive updates, which could yield penetration or other issues. You could avoid this with certain hacks like promoting the unupdated bodies to an ephemeral kinematic state and such, but this is yet more complexity and comes with its own weird behavior. Some bullet ends up getting bit.

In other words, I've focused on optimizing the worst case to be stupidly fast while preserving simplicity where I could.

I may still get around to something like this. If all the problems are dealt with, the combination of batching and islands can have scaling advantages due to smaller islands staying in deeper caches during the whole solve. Probably won't be this year or the next, though.