Optimized physics approach.

For a 3d demo I’m doing, I need to procedurally generate a collision mesh on the fly.

I can do it with either a large number of box colliders, or by manually generating a mesh in code.

The total count could in theory get up into the order of 10k colliders, and I have some sneaking suspicions which route I should go down, but was hoping to get a couple of quick questions answered.

  1. I’m assuming the burden of the box colliders (particularly if they’re axis-aligned) should be managegable if PhysX does a decent job of partioning them spatially, but I suspect that unless I can turn OFF the parent objects, that the cpu burden from managing the objects themselves will make this approach pointless.

  2. If I instead generate a sufficiently detailed collision mesh, and assign it to one (or possible more if there’s a reason to do so) objects will prove more efficient in terms of the scene management, but I have no idea if PhysX can optimize such a large collision mesh on the fly (break it down into a collision Octree while the game is actually running). I don’t mind a 1-2 second lag to the game, as this happens only when the procedural game board is generated at the start of the game.

Generating a collision mesh on the fly isn’t any different than importing one. And yeah, the bigger it is the longer it takes to calculate.

–Eric