need performance tips

I am working on a voxel-based game world. Every exposed voxel is getting a box or convexMesh shape (if not cubic) at the moment, which is quite ok when dealing with static actors. The thing is, I want my voxel environments to be dynamic. Once a couple of thousands of box shapes start moving, it’s getting pretty bad performance-wise. Now before I spend many hours experimenting, I would like to hear from people more experienced with the engine.

I’ve thought of 2 approaches. One is pretty simple: just look for neighboring boxes - maybe divided by sectors (like 5x5x5 voxels in size) - to group them into larger boxes and reduce the number of shapes. The problem here is that only boxes can be grouped, and only those that can be described by a bigger box. Writing algorithms to find the best way of grouping could be a pain. Also, I want to make much use of “half-boxes” - divided diagonally - to make the world less “edgy”. But for grouping these I would need convex meshes.

That’s the other approach: create convex meshes to put several shapes into a single one. It would allow me to remove unneeded vertices as well. The question is, are convex meshes good for performance or should I stick with primitive shapes? And would re-cooking a mesh every time a voxel is added or removed from a buffer/sector have a big impact on performance?

Or maybe there’s something else I haven’t thought of?

Which version of PhysX are you using? If you are using 3.3.0, the SDK documentation goes into the different broadphase algorithm that is available in 3.3.0. I don’t know how much improvement you will see from changing the algorithm, but I suggest you check out the documentation.

If you’re using 3.3 or later then I would look at the documentation for the MBP (Multi-Box Pruning) algorithm to see if this better fits your needs. The other thing to think about is to use PxAggregate to cut down the number of bounds that are added to the broadphase. This can really help with ragdolls, for example.

Well, I have been too lazy to convert to 3.3 yet (still using 3.2). The changes become quite a pain, as the project gets bigger. Especially the raycast/sweep/ccd changes look like I will have to do a lot of rewriting. I finally added aggregates to my ragdolls though, thanks for reminding me. I had wanted to do that for a long time. I will see what can be done (and what MBP does) after I did the update.

I have done the conversion to 3.3 yesterday. Took me many hours, mostly because I had to change my self-made graphical ragdoll-, joint- and hitShape editor for skinned meshes to adapt to the changes in the twist/swing/linear joint limits and had to convert my data accordingly. However, I have had another idea: instead of rotating these huge voxel-compounds, it would probably be much better to rotate the entire scene around them (one scene for each). I just don’t know if it’s possible without excessive use of setGlobalPose or making everything kinematic. Maybe I could do 2 alternating simulation phases: One where everything simulates normally, and one where everything is set to kinematic and inverse-transformed by the world’s movement and rotation. Hmm…

Is there any way to give a RigidDynamic an acceleration that would do the same? the only way I can think of is to set every object’s center of mass to the scene’s origin, but then all other physical simulations become broken.

edit: Nevermind, I just experimented a little and it’s not hard at all. All My rigidDynamics in a scene now get their linear and angular velocities rotated by the (“imaginary”) world rotation and a “compensation”-vector on top of that for the shift in position. The voxel world doesn’t have to move, but there is no telling it isn’t now :)
No doubt this helps performance a lot more than any shape-grouping could.

The whole thing runs great, but there is one problem now: actors that are treated this way, get this weird movement-lock after serializing and de-serializing. I tried clearing force and torque before saving, but it doesn’t help. Even when I stop rotating them around the center (I use accelerate: velocity-change exclusively), and let the simulation continue running normally before saving, the actors that got rotated at some point - and weren’t added later - will not deserialize without becoming frozen in place. It’s like they have infinite damping: when colliding they show a 1-frame movement and then stop completely. But dampening is not the problem, it’s something else…