Dynamic Convex Level Geometry

Gaming and Visualization Technologies APIs Physics Modeling (closed)
1

Hello!

I’m working on an indie project, and we are trying out PhysX for our physics and collision systems.

Our level geometry is built from a great number of convex meshes, that the user can modify in real time, however each mesh has the limitation that it has to be a valid convex polyhedron. They are just about the same thing as brushes from the Quake era, however we don’t use a BSP tree.

Each polyhedron is limited to 8 vertices, and 12 faces(They start as cubes, and each face can be triangulated once). So each mesh is very simplistic, however we have a lot of them. They will always be static and non-modifiable while the physics system is actually doing simulation however.

I’m doing some simple tests right now and my first approach was to simply generate a convex shape and a static rigid body for each “brush”, add them to the scene and let PhysX deal with it.

The level geometry can get quite dense in certain places, where the artist decided to go a bit crazy with the detailing.

As opposed to trying to guess a number of brushes, I’ve taken a screenshot from the visual debugger showing the complexity of a fairly full-featured room: Imgur: The magic of the Internet

We’re basically looking at 5-15 times that, for a level.

The question is if this is a decent approach or if I’ve completely missed some other way of doing things that would be preferable? In terms of polygon counts we’re not breaking any records obviously, however I’m worried about the sheer count of separate static meshes.

Any insight from someone with more experience would be helpful.

2

You might want to experiment with PxAggregate.

Large shape counts can put pressure on the broadphase. A good way of helping with broadphase performance is to create a PxAggregate and then add multiple actors to it. The caveat is that we only allow 128 shapes per PxAggregate.

You have a few options with aggregates. You can add a single rigid body, attach 128 shapes and then add the rigid body to its own aggregate. Alternatively, you could make 128 rigid bodies each with a single shape and then add all the actors to the aggregate. There’s probably not much performance difference but there will be a memory difference between these two approaches. My instinct is that the biggest difference will be how easy it is for you to implement code to add and remove shapes. Instinctively, it seems easier if you have one shape per actor. That comes at the cost of a larger memory footprint.

There is no guarantee that aggregates will give better performance. We’ve found they typically give a good boost but there are some scenarios where they make little difference. If they don’t help and you’re worried about memory consumption then you might want to look at just attaching multiple shapes to static actors. There is no limit to the number of shapes supported on a single actor so you could go to the extreme of having a single static actor and attaching all your shapes to it.

3

Thank you!

I will try the approaches you suggested.