Better Rigidbody and Constraint Memory Management #101877

New Issue

Sonny Campbell · 2022-10-17T18:04:39+02:00

Sonny Campbell commented

2022-10-17 18:04:39 +02:00

Here is a general diagram of the relevant pieces of the Object and RigidBodyWorld models

Problem Scenarios:

There is an empty with the constraint. Two objects with rigidbodies are linked to the constraint.

Deleting one of the objects.
Deleting the empty with the constraint.

There is an object with a rigidbody and it has the constraint on it. There is another object linked to the constraint.

Deleting the other object.
Deleting the object with the constraint.

Scenario 1.A:
Empty - Has constraint.
Object1 - First object in constraint
Object2 - Second object in constraint.
Play simulation for a few frames. Pause simulation. Delete Object2 from scene.
Test1a.blend

Problem
For Object2, its btRigidBody has a pointer to the btTypedConstraint. When deleting the btRigidBody, we tell the btTypedConstraint to removeConstraintRef().
This however just marks Object2's btRigidBody as not colliding with Object1's btRigidBody, it does not remove the btRigidBody from the btTypedConstraint.
The memory for Object2's btRigidBody gets deleted, and btTypedConstraint now contains junk memory that crashes when attempting to run the simulation for the scene RigidBodyWorld.
From looking at the header of btTypedConstraint, it seems like the intent is to never swap out the rigid bodies or change them after the creation of the constraint.
So we need to ensure that when an object gets removed from the scene, the btTypedConstraint gets removed from the btDiscreteDynamicsWorld for the scene.
(This also happens when both objects are set in the rigidbody constraint, the simulation is played for a few frames and then paused, and then UNDO takes the object out of the constraint.)

Scenario 1.B:
Empty - Has constraint.
Object1 - First object in constraint
Object2 - Second object in constraint.
Play simulation for a few frames. Pause simulation. Delete Empty from scene.
Didn't cause any crashes that I could find

Scenario 2.A:
Object1 - Has constraint.
Object2 - Second object in constraint.
Play simulation for a few frames. Pause simulation. Delete Object2 from scene.

Problem:
Essentially the same as 1.A

Scenario 2.B:
Object1 - Has constraint.
Object2 - Second object in constraint.
Play simulation for a few frames. Pause simulation. Hit Ctrl-Z to undo and move back to start of simulation.
Test2b.blend

When hitting UNDO, we iterate throught the objects in the scene to delete and recreate them in the previous state.
When deleting, if Object1 is deleted first, that has the constraint on it, we delete the physics object and the constraint.
Each btRigidBody contains an array of pointers to constraints that it is in. When deleting the physics body, we need to ensure that it is removed from all constraints.
We remove the constraint from Object1's btRigidBody, and then delete the btTypedConstraint.
However Object2's btRigidBody still has a pointer to the btTypedConstraint. When deleting the btRigidBody, we attempt to remove it from the btTypedConstraint,
but the memory has already been freed, so we get a crash.

These are the most obvious issues with the current implementation, though it is not exhaustive. There are further problems with memory getting corrupted between undoing and rebuilding the simulation that I could not pin down so specifically, but I think these are representative of what the issues boil down to.
The crux of the issue is that when deleting any physics object, it needs to know about all the constraints it is in and all the other objects that are related to it in the physics simulation. And if it is in a constraint, but doesn't actually own the constraint, there's no way to find the other objects and relationships it cares about. This also leads to the order-of-processing issues depending on which objects get deleted first when undoing/rebuilding a simulation.

Resolution Ideas
My suggestion is to no longer free ob->rigidbody_object or ob->rigidbody_constraint directly from an Object.
The Scene's RigidBodyWorld should be responsible for handling removal of all rigidbody related data.

It should contain a map from Object -> Set<RigidBodyCon> so when any Object is being removed the RBW has a link to any related constraints. An object could be in multiple constraints, hence the Set<RigidBodyCon>. In theory we could loop through all constraints in the scene to find which constraints an object is in, but this would obviously have a performance impact on a scene with a lot of constraints.
When an object is being removed/deleted, the RBW will remove any btTypedConstraint that references it from the btDiscreteDynamicsWorld.
It can also remove the btTypedConstraint from any other objects in the constraint so it no longer has a junk pointer.

Create a hashmap on the RigidBodyWorld data structure to contain a map of Objects to the constraints they are in.

  /** (blender::Map<Object *, blender::Set<RigidBodyCon>>) */
  void *object_rbc_map;

When rigidbodies or constraints are going to be added to/removed from the scene, ensure that the RigidBodyWorld is responsible for deleting all relevant physics objects and constraints, rather than deleting them from the Object directly.

For Scenario 1.A/2.A: the RBW would ensure that if a btRigidBody is removed from a btTypedConstraint, the btTypedConstraint should get removed from the btDiscreteDynamicsWorld.

For Scenario 2.B: the RBW would ensure that when deleting a constraint, all objects in the constraint have the btTypedConstraint removed from their btRigidBody.

Here is a general diagram of the relevant pieces of the `Object` and `RigidBodyWorld` models ![image.png](https://archive.blender.org/developer/F13699309/image.png) **Problem Scenarios:** 1. There is an empty with the constraint. Two objects with rigidbodies are linked to the constraint. - Deleting one of the objects. - Deleting the empty with the constraint. 2. There is an object with a rigidbody and it has the constraint on it. There is another object linked to the constraint. - Deleting the other object. - Deleting the object with the constraint. **Scenario 1.A:** Empty - Has constraint. Object1 - First object in constraint Object2 - Second object in constraint. Play simulation for a few frames. Pause simulation. Delete Object2 from scene. [Test1a.blend](https://archive.blender.org/developer/F13699632/Test1a.blend) **Problem** For Object2, its btRigidBody has a pointer to the btTypedConstraint. When deleting the btRigidBody, we tell the btTypedConstraint to `removeConstraintRef()`. This however just marks Object2's btRigidBody as not colliding with Object1's btRigidBody, it does not remove the btRigidBody from the btTypedConstraint. The memory for Object2's btRigidBody gets deleted, and btTypedConstraint now contains junk memory that crashes when attempting to run the simulation for the scene RigidBodyWorld. From looking at the header of btTypedConstraint, it seems like the intent is to never swap out the rigid bodies or change them after the creation of the constraint. So we need to ensure that when an object gets removed from the scene, the btTypedConstraint gets removed from the btDiscreteDynamicsWorld for the scene. (This also happens when both objects are set in the rigidbody constraint, the simulation is played for a few frames and then paused, and then UNDO takes the object out of the constraint.) **Scenario 1.B:** Empty - Has constraint. Object1 - First object in constraint Object2 - Second object in constraint. Play simulation for a few frames. Pause simulation. Delete Empty from scene. Didn't cause any crashes that I could find **Scenario 2.A:** Object1 - Has constraint. Object2 - Second object in constraint. Play simulation for a few frames. Pause simulation. Delete Object2 from scene. **Problem:** Essentially the same as **1.A** **Scenario 2.B:** Object1 - Has constraint. Object2 - Second object in constraint. Play simulation for a few frames. Pause simulation. Hit Ctrl-Z to undo and move back to start of simulation. [Test2b.blend](https://archive.blender.org/developer/F13699634/Test2b.blend) When hitting UNDO, we iterate throught the objects in the scene to delete and recreate them in the previous state. When deleting, if Object1 is deleted first, that has the constraint on it, we delete the physics object and the constraint. Each btRigidBody contains an array of pointers to constraints that it is in. When deleting the physics body, we need to ensure that it is removed from all constraints. We remove the constraint from Object1's btRigidBody, and then delete the btTypedConstraint. However Object2's btRigidBody still has a pointer to the btTypedConstraint. When deleting the btRigidBody, we attempt to remove it from the btTypedConstraint, but the memory has already been freed, so we get a crash. These are the most obvious issues with the current implementation, though it is not exhaustive. There are further problems with memory getting corrupted between undoing and rebuilding the simulation that I could not pin down so specifically, but I think these are representative of what the issues boil down to. The crux of the issue is that when deleting any physics object, it needs to know about all the constraints it is in and all the other objects that are related to it in the physics simulation. And if it is in a constraint, but doesn't actually own the constraint, there's no way to find the other objects and relationships it cares about. This also leads to the order-of-processing issues depending on which objects get deleted first when undoing/rebuilding a simulation. **Resolution Ideas** My suggestion is to no longer free `ob->rigidbody_object` or `ob->rigidbody_constraint` directly from an `Object`. The Scene's `RigidBodyWorld` should be responsible for handling removal of all rigidbody related data. - It should contain a map from `Object` -> `Set<RigidBodyCon>` so when any Object is being removed the RBW has a link to any related constraints. An object could be in multiple constraints, hence the `Set<RigidBodyCon>`. In theory we could loop through all constraints in the scene to find which constraints an object is in, but this would obviously have a performance impact on a scene with a lot of constraints. - When an object is being removed/deleted, the RBW will remove any btTypedConstraint that references it from the btDiscreteDynamicsWorld. - It can also remove the btTypedConstraint from any other objects in the constraint so it no longer has a junk pointer. Create a hashmap on the `RigidBodyWorld` data structure to contain a map of Objects to the constraints they are in. ``` /** (blender::Map<Object *, blender::Set<RigidBodyCon>>) */ void *object_rbc_map; ``` When rigidbodies or constraints are going to be added to/removed from the scene, ensure that the RigidBodyWorld is responsible for deleting all relevant physics objects and constraints, rather than deleting them from the Object directly. For **Scenario 1.A/2.A:** the RBW would ensure that if a `btRigidBody` is removed from a `btTypedConstraint`, the `btTypedConstraint` should get removed from the `btDiscreteDynamicsWorld`. For **Scenario 2.B:** the RBW would ensure that when deleting a constraint, all objects in the constraint have the `btTypedConstraint` removed from their `btRigidBody`.

👍 1

Sonny Campbell self-assigned this 2022-10-17 18:04:39 +02:00

Sonny Campbell commented

2022-10-17 18:04:39 +02:00

Added subscribers: @SonnyCampbell_Unity, @lichtwerk, @vinegarshots, @PratikPB2123, @mod_moder, @ZedDB

Bastien Montagne added this to the Core project 2023-02-09 15:42:54 +01:00

Bastien Montagne removed this from the Core project 2023-02-09 18:20:29 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Better Rigidbody and Constraint Memory Management #101877