Simulation: collision steps and integration steps #142
-
|
The documentation for PhysicsSystem::Update says this: /// The world steps for a total of inDeltaTime seconds. This is divided in inCollisionSteps iterations. Each iteration However, I'd like to know more about the effect of different values and what good values are. Currently I use 1 for both and it seems to work just fine. My assumption is that raising inIntegrationSubSteps would improve stability? Though in my tests with ragdolls, Jolt is already pretty stable, when would I need higher values? For inCollisionSteps it sounds like if I pass in 32ms and inCollisionSteps==2, it might be the same as calling Update twice with 16ms. Is that the case or is there any benefit to the former? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
I would leave the integration sub steps at 1. You can use it to make constraints stiffer / support stacking more objects on top of each other by effectively making the integration delta time smaller without paying the cost of an extra collision detection step. When I wrote it, I thought I could use it to run collision detection at 30 Hz and integration at 60 Hz, but that didn't really work, so I may actually remove it completely at some point. W.r.t. to collision steps: Yes calling 2x Update(1/60, 1) is equivalent to calling Update(1/30, 2). The latter avoids a a little bit of overhead in preparing the job graph / locking the bodies, so is the preferred way. |
Beta Was this translation helpful? Give feedback.
I would leave the integration sub steps at 1. You can use it to make constraints stiffer / support stacking more objects on top of each other by effectively making the integration delta time smaller without paying the cost of an extra collision detection step. When I wrote it, I thought I could use it to run collision detection at 30 Hz and integration at 60 Hz, but that didn't really work, so I may actually remove it completely at some point.
W.r.t. to collision steps: Yes calling 2x Update(1/60, 1) is equivalent to calling Update(1/30, 2). The latter avoids a a little bit of overhead in preparing the job graph / locking the bodies, so is the preferred way.