Best performance for big level models

[GiveUpGames]

Hi,

My levels are a combination of a model as a "StaticMesh" and some boxes, placed as non-dynamic entities for incidental collisions, barriers and such.

Let's say I have a level model of about 2500 verticies. In terms of expected BEPU performance, is it best to leave it as one big model? Are there any benefits to breaking the model up into a few smaller models? Are the extra performance hits when models have "tunnels" or other complex concave surfaces? Any tips on making a static mesh perform better?


Also, for the number of boxes, a few levels are built entirely from individually placed boxes that are supposed to serve as collisions only. Right now, for each box, i create an entity with mass of 0 and place it in the scene. A "large" scene is built from maybe 700 boxes, of wildly varying sizes and orientations.

Is there a better way to put so many boxes in a physics space? I tried building them into ONE compound shape, using "CompoundBody" in the bepu library. However, when i did this, i noticed an annecdotal DROP in frames, which lead me to believe it performed worse then the individual boxes. Any other cool ways to "bake" a bunch of boxes for "best consumption of the physics library"?


Thanks,
Mike

[Norbo]

Let's say I have a level model of about 2500 verticies. In terms of expected BEPU performance, is it best to leave it as one big model? Are there any benefits to breaking the model up into a few smaller models?

Leaving it as one model tends to work best in most cases. Breaking it up usually only helps when the model (or more often, Terrain) is so large that parts of it are being streamed in and out as the player moves around.

There's a couple of other cases where you might want to split a model. For example, if the mesh is two disjoint components separated by a big gap, the the majority of the mesh's AABB volume will be distant from actual collision geometry. If a lot of simulation stuff is inside that gap, it will end up being tested against the mesh pointlessly.

Are the extra performance hits when models have "tunnels" or other complex concave surfaces?

More triangles might need to be tested for collision, but that's about it. There shouldn't be any weird spikes in collision detection time because of it or anything like that.

Any tips on making a static mesh perform better?

Except in extreme cases, trying to tune content for StaticMeshes doesn't provide a big performance boost since StaticMeshes are rarely a bottleneck. If you see performance issues, running a profiler or compiling BEPUphysics with PROFILE to check stage timings might provide some insight. That said:

1) Make the mesh as simple as it can be, subject to #2.
2) Make triangles fairly regular in size in shape. If you can technically save a triangle by creating a really long sliver triangle, don't do it. Just keep it as multiple more regular triangles.

Those two recommendations follow from how collision detection works. An object is tested against the triangles with AABBs which overlap the object. Cost is roughly proportional to the number of triangles tested. A long sliver triangle can have a large AABB relative to its actual collision shape, so they are typically inefficient and splitting them is better.

Also, for the number of boxes, a few levels are built entirely from individually placed boxes that are supposed to serve as collisions only. Right now, for each box, i create an entity with mass of 0 and place it in the scene. A "large" scene is built from maybe 700 boxes, of wildly varying sizes and orientations.

Is there a better way to put so many boxes in a physics space?

Two options:
1) Use a StaticGroup. The StaticGroupDemo shows an example. It's like a StaticMesh, except for arbitrary collidables rather than just triangles.
2) Wait for me to rewrite a big chunk of the collision pipeline to make inactive and static objects basically free, making StaticGroup mostly pointless. I've got a fairly fat to-do list on a bunch of projects, so this might take me a few months to get to.

[GiveUpGames]

Very cool, thanks for the feedback.

About StaticGroup .... It wants a IList<Collidable> to be passed to the constructor, which means, as "shapes" come in, i need to maintain that list myself, then finally, build the StaticGroup with the list i was managing.

That's fine, but i can't find a version of a "box" that inherits from "Collidable". I see a box in "BEPUphysics.CollisionShapes.ConvexShapes", but that doesn't appear to inherit from "Collidable". Instead, it inherits from "CollisionShape". As soon i figure out what box object I can use, i'll be good.

Also, about profiling. I don't know how to enable it. I'm running the physics world asynch, as default, and to try to figure out how long stuff is taking, i did this....

Code: Select all

            Global3dGame.PhysicsWorld.BroadPhase.Starting += BroadPhase_Starting;
            Global3dGame.PhysicsWorld.BroadPhase.Finishing += BroadPhase_Finishing;
            Global3dGame.PhysicsWorld.BoundingBoxUpdater.Starting += BoundingBoxUpdater_Starting;
            Global3dGame.PhysicsWorld.BoundingBoxUpdater.Finishing += BoundingBoxUpdater_Finishing;
            Global3dGame.PhysicsWorld.Solver.Starting += Solver_Starting;
            Global3dGame.PhysicsWorld.Solver.Finishing += Solver_Finishing;

Then each of those handlers does essentially the same thing (with different keys / strings based on the event).....

Code: Select all

        void Solver_Finishing()
        {
            PerformanceManager.End("Solver");
        }

        void Solver_Starting()
        {
            PerformanceManager.Start("Solver");
        }

My PerformanceManager manages an instance of "Stopwatch", and keeps start and end times based on keys. Then right before draw, i figure the differences of those times and print the durations to the screen.
Is there a better built-in way?

I like my way only because it's unified across all systems. Maybe i can use some cool "built in" thing you made, and have the "PerformanceManager" internally use it, so the public interface is still the same.

Thanks again.


-Mike

[Norbo]

That's fine, but i can't find a version of a "box" that inherits from "Collidable". I see a box in "BEPUphysics.CollisionShapes.ConvexShapes", but that doesn't appear to inherit from "Collidable". Instead, it inherits from "CollisionShape". As soon i figure out what box object I can use, i'll be good.

There are three layers to be aware of:
1) Entity: Provides the mobility and dynamics of an object. Owns a Collidable, stored in the CollisionInformation property; the Entity type is not itself able to collide with anything. The "Box" entity type is just a convenience/legacy type which builds the collidable and shape for you.
2) Collidable: An object capable of undergoing collisions and generating contacts. This is the thing that actually lives in the collision detection pipeline. A Box entity's CollisionInformation property refers to a Collidable which has the collision geometry of a box.
3) Shapes: Describes collision geometry. A single shape can be shared among multiple collidables. For example, you can create and position a thousand InstancedMeshes based on a single InstancedMeshShape. (The StaticGroup is the one exception; its shape cannot be shared with other StaticGroups due to some mutability details. This is a bit ugly and will cease to be an issue when the rewrite eliminates the need for the StaticGroup.)

Look at the EntityConstructionDemo in the BEPUphysicsDemos to see a more detailed breakdown and usage examples of the above.

So, to put boxes in a StaticGroup, you'll need a collidable based on a BoxShape: ConvexCollidable<BoxShape>. Check out the StaticGroupDemo in the BEPUphysicsDemos to see a code example of using the StaticGroup with ConvexCollidable<BoxShape> collidables.

Also, about profiling. I don't know how to enable it.

For the built-in stage timings, you would need to recompile BEPUphysics with the PROFILE compilation symbol defined. Stages would then expose a Time property, which refers to the length of the previous execution of that stage.

If you've already got complete per-stage timings set up, it's not really necessary. The built-in version could just offer a little more detail on a per-stage level on types where it specializes, like the BroadPhase and NarrowPhase.

[GiveUpGames]

Wonderful!

Thanks. I just found the StaticGroupDemo on my local machine, and looks easy to implement. I'll post some profiling results of before and after i implement the change.

I'm taking a wild guess that if i see any improvements, it will be in the "broadphase" timing?

[Norbo]

Yup; moving the bunch of boxes into a StaticGroup primarily benefits the BroadPhase (for now, until it is rewritten). It will slightly increase NarrowPhase cost, but it should be a measurable win for any significant number of boxes.

That said, 700 boxes in the broad phase on the PC is almost nothing. It could be a little hard to get a signal above noise on anything but slow systems like the Xbox360 and phones.

[GiveUpGames]

Interesting. I might hold off then. About to be done with this game, and the most boxes for a level who's physics is comprised ENTIRELY of boxes, is only 260. So maybe i'll just leave it all be for now.

I've come to find, as other probably have, that most of my performance issues were drawing related. thanks for the help.