Real-Time Physics Simulation Forum

I'm talking about single-threaded. I know it's possibly not safe for deleting but what about adding within the tick?

The simple answer: no.

A more complicated answer: the step consists of multiple substeps. It might be ok to add/remove a RigidBody/CollisionObject between substeps, however there is no default hook for calling your add/remove logic between substeps: you would have to add your own.

Within the substep there are multiple stages including (but not limited to, and not necessarily in this order):

integrate - move objects forward in time
broadphase - figure out what objects overlap
narraowphase - figure out which overlapping pairs actually touch and create contact points
solve - apply contacts and compute new velocities
apply custom actions

Between which of those stages would you like to add/remove objects?
Why would it be a good idea to deprive earlier stages of knowledge about those objects?

Edit: fixed spelling typo.

Thanks for replying !

It's the gameplay code that triggers events of [ breaking up "fixed-constrained-rigidbodies" into separate ones], causing unexpected add/remove actions. The assertion checking for within-loop adding/removing was there long time ago , that's why it gets spotted.

I guess this is the design problem of our event system. I did not intend to let this happen, normally we'd avoid it and put it at the end of the tick.

Right now I'm already working on this problem

Again thanks a lot for replying. It helped !

I remembered something and figured I would mention it for the record:

I had a situation where I wanted to be able to add/update/remove objects ASAP for a multi-threaded system where the operations could arrive from a different thread. The pending ops would be collated into three lists (add, update, delete) and passed to the simulation thread in a lock, but since there was no standard callback between substeps --> I added one. That is, I derived MyDiscreteDynamicsWorld from btDiscreteDynamicsWorld and overrode the stepSimulation() method. My own version was just copied over from the original except I added a check between substeps which would lock, move the lists of ops into the simulation thread context, unlock, and then apply them. So even if my step happened to have multiple substeps I was still able to perform add/update/remove (in that order) as soon as "possible" (e.g. not mid-substep).