Object ownership, refcounting and memory allocations

[godlikepanos]

Hi,

I'm currently looking at the code and I have a few questions to the point where I think I missing something fundamental.

Jolt has the notion of refcounting for some objects. Shape is refcounted for example and Body holds a reference. Makes sense. Body is not refcounted though and TwoBodyConstraint just holds plain pointers to the two bodies. Why Body is not refcounted? Are there more special objects like that?

For shapes and constraints I can allocate the memory myself by bypassing Jolt's new/delete. I can just use my own memory, call placement new and finally call SetEmbeded(). Body is special once again when it comes to allocation. Why can't I allocate it myself and give the pointer to the body system?

Another question is around the XXXSettings classes (eg TwoBodyConstraintSettings). Why are these refcounted?

Thanks in advance!

[jrouwe]

Why Body is not refcounted? Are there more special objects like that?

Body is not refcounted because it requires very careful memory management: it is the main class that is safe to access from multiple threads. Also, internally Body and its (SoftBody)MotionProperties are allocated in the same memory block so you can't just call delete on them. This is done for performance reasons. I think it's the only object that is special in that way.

For shapes and constraints I can allocate the memory myself by bypassing Jolt's new/delete. I can just use my own memory, call placement new and finally call SetEmbeded(). Body is special once again when it comes to allocation. Why can't I allocate it myself and give the pointer to the body system?

See the answer above. Note that you can override Jolt's new/delete by overriding the Allocate, Reallocate, Free, AlignedAllocate and AlignedFree functions.

Another question is around the XXXSettings classes (eg TwoBodyConstraintSettings). Why are these refcounted?

For most of the ref counted classes, the assumption is that you can share them between unrelated objects. E.g. you can do:

Ref mesh = new MeshShapeSettings(....);

Ref compound1 = new StaticCompoudShapeSettings;
compound1->AddShape(<some orientation>, mesh);
compound1->AddShape(<other orientation>, mesh);

BodyCreationSettings body1(compound1, ...)
<create the body>

Ref compound2 = new StaticCompoudShapeSettings;
compound2->AddShape(<an orientation>, mesh);

BodyCreationSettings body2(compound2, ...)
<create the body>

The end result of this is that only 1 MeshShape will be created and it will be used 2x in body1 and once in body2.

In the case of TwoBodyConstraintSettings, these can be used e.g. in the RagdollSettings class to have a single SwingTwistConstraintSettings and reuse it on both shoulders of a humanoid ragdoll.

[MasterDrake]

For most of the ref counted classes, the assumption is that you can share them between unrelated objects. E.g. you can do:

Ref mesh = new MeshShapeSettings(....);

Ref compound1 = new StaticCompoudShapeSettings;
compound1->AddShape(<some orientation>, mesh);
compound1->AddShape(<other orientation>, mesh);

BodyCreationSettings body1(compound1, ...)
<create the body>

Ref compound2 = new StaticCompoudShapeSettings;
compound2->AddShape(<an orientation>, mesh);

BodyCreationSettings body2(compound2, ...)
<create the body>

The end result of this is that only 1 MeshShape will be created and it will be used 2x in body1 and once in body2.

In the case of TwoBodyConstraintSettings, these can be used e.g. in the RagdollSettings class to have a single SwingTwistConstraintSettings and reuse it on both shoulders of a humanoid ragdoll.

It's a noob question, but I was wondering how at Guerilla you used to save those Shapes and how do you access them, string, some ID or just index in a vector?
I have these shapes all around and I'm not sure how to address them.

[jrouwe]

We have a custom serialization system that is able to write out complex object graphs and restore them, so you'd have something like EngineBody (not real names) has a pointer to an EngineShape.

• EngineBody at runtime creates a Jolt Body
• EngineShape comes in different flavors, e.g. EngineMeshShape, EngineSphereShape etc.
• EngineMeshShape contains the uncompressed mesh data (in a format that's editable in our tools) and when 'cooking' the game data we:
  • Create a Jolt MeshShape
  • Save it using Shape::SaveWithChildren in a binary blob that's associated with the EngineMeshShape
• When loading the EngineMeshShape we also restore the MeshShape from the binary blob using Shape::sRestoreWithChildren
• The serialization system takes care that the pointer between EngineBody and EngineShape is restored (internally it uses UUIDs for that)
• There are some tricks for sharing shapes, so e.g. a EngineCompoundShape links to multiple child EngineShapes
  • At cooking time it creates a Jolt StaticCompoundShape
  • Before writing the shape to the binary blob with Shape::SaveWithChildren it inserts all leaf shapes (the Shape's associated with the child EngineShapes) in the ShapeToIDMap so they won't be included in the binary blob
  • Before loading the binary blob with Shape::sRestoreWithChildren it prepopulates the IDToShapeMap with the pointers to the restored Shape's from the child EngineShapes

[MasterDrake]

We have a custom serialization system that is able to write out complex object graphs and restore them, so you'd have something like EngineBody (not real names) has a pointer to an EngineShape.

• EngineBody at runtime creates a Jolt Body

• EngineShape comes in different flavors, e.g. EngineMeshShape, EngineSphereShape etc.

• EngineMeshShape contains the uncompressed mesh data (in a format that's editable in our tools) and when 'cooking' the game data we:

  • Create a Jolt MeshShape
  • Save it using Shape::SaveWithChildren in a binary blob that's associated with the EngineMeshShape

• When loading the EngineMeshShape we also restore the MeshShape from the binary blob using Shape::sRestoreWithChildren

• The serialization system takes care that the pointer between EngineBody and EngineShape is restored (internally it uses UUIDs for that)

• There are some tricks for sharing shapes, so e.g. a EngineCompoundShape links to multiple child EngineShapes

  • At cooking time it creates a Jolt StaticCompoundShape
  • Before writing the shape to the binary blob with Shape::SaveWithChildren it inserts all leaf shapes (the Shape's associated with the child EngineShapes) in the ShapeToIDMap so they won't be included in the binary blob
  • Before loading the binary blob with Shape::sRestoreWithChildren it prepopulates the IDToShapeMap with the pointers to the restored Shape's from the child EngineShapes

Woah, thank you for you detailed answer!

[godlikepanos]

Thanks for the answers!