MutableCompoundShape Usage Patterns

[JRBowman]

Hello!

There's a chance I'm missing the documentation or I need to review the usage patterns in the Jolt main repo so mind me if I've missed something!

I'm implementing Jolt Physics via JoltPhysicsSharp into my Silk.NET Framework/ECS where I support both 3D and 2D focused runtimes, I'm trying to implement a 2D TilemapCollider and it seemed that creating a Body using a MutableCompoundShape made the most sense to attach a shape for each Tile and have it managed by a singular body (I did a similar implementation using Velcro/Box2D physics in a previous iteration and that was the recommended approach there)

Does this approach make sense for Jolt Physics? Would it be better to consider a customized approach that links into the broadphase lifecycle with some sort of AABB (thinking aloud an incomplete thought there) or should I try to work out something that creates larger convex shapes from the Tiles? (I tried the latter approach with Velcro and it proved to be quite difficult to merge tile shapes into convex shapes!)

Any ideas are appreciated! Thank you!

[amerkoleci]

Hi,
First of all thanks for sponsoring me, really appreciate!

About the question, I would suggest to ask on Jolt discussion as the author of jolt is the real expert here (@jrouwe).

If there is something Jolt have and I didn't exposed to C/C# world I would gladly add it.

Cheers,
Amer

[JRBowman]

Got it and thank you for the quick response, I greatly appreciate it!

I did end up getting CompoundShape to work for me, I haven't actually tested the Mutability yet but adding shapes during "chunk loading" (where tiles are placed on the Tilemap) and then creating the shape from a MutableCompoundShapeSettings instance once the chunk finished worked, I must've been doing something out of order before!

The part I have to try and figure out next is actually removing shapes from the MutableCompoundShape instance attached to the Body during runtime (Not sure if there's a direct way to do that and the Body/Simulation knows about the changes or if there's other work involved!)

I know the ideal approach for performance is being able to merge as many shapes/vertices into combined shapes / hulls, I'll try to figure that out too at some point!

Lastly, thank you for this awesome project! I'm happy to sponsor (and eventually increase that tier) since I'll be taking this to 'production' one day with a game I've been working on! Also, if there's anything I find or code along the way with the Jolt API then I'll be sure to contribute back via PR or otherwise do what I can to contribute to the code!

Thank you,
Justin

[amerkoleci]

Thanks for kind words and feel free to ask/request feature and share some projects stuff along the road, take look on other mine open source project and see if you can use something else.

Thanks,
Amer

[jrouwe]

Does this approach make sense for Jolt Physics? Would it be better to consider a customized approach that links into the broadphase lifecycle with some sort of AABB (thinking aloud an incomplete thought there) or should I try to work out something that creates larger convex shapes from the Tiles?

I'm not sure how large a 'tile' is in your case. I would not place the entire world in a single MutableCompoundShape. The mutability comes at a performance cost. Instead you could divide your level in regions and have a body and a MutableCompoundShape per region, or alternatively have a StaticCompoundShape per region if the collision data in that region doesn't change after it has been loaded.

The part I have to try and figure out next is actually removing shapes from the MutableCompoundShape instance attached to the Body during runtime (Not sure if there's a direct way to do that and the Body/Simulation knows about the changes or if there's other work involved!)

I think it is best to look at the C++ examples for this:

https://github.com/jrouwe/JoltPhysics/blob/f95ad217f2c2797081cbc33b6d3463dd0ef65f84/Samples/Tests/Shapes/MutableCompoundShapeTest.cpp#L91-L110

[JRBowman]

Got it! Thank you for your response!

A tile is relatively small, I'm still working out a Pixels Per Unit conversion that makes the most sense but a Tile is likely to be between (0.0625, 0.0625, 0.0625) to (0.03125, 0.03125, 0.03125) in Simulation Unit Size (from a tile that's 16px x 16px)

My plan was to use the StaticCompoundShape for the static tiles and use the MutableCompoundShape for destructible tiles.

The max Shapes per Body would either be at Cell Size (256 Tiles) or maybe Chunk Size (a contiguous collection of Cells that could be a range in size but usually ~1-5 Cells) - My world would consist of 1-2 chunks being loaded at a time (Previous Chunk / Current Chunk and transition when loading the Next Chunk) and then of course only processing tiles that are part of a Cell that's on-screen (so I could let the Bodies of the other Cells Sleep until needed in Simulation)

@jrouwe Thank you for raising that fine point! As I was rambling above, it was making me think more about the best ratio for Tile Shapes to Bodies, I can imagine it's a fine balance of making sure it's even distributed for processing in the simulation!

I'll have to run some tests and benchmarks to figure out what works best and also brush up on your documentation to make sure I'm read-up on any existing metrics and best practices there!