CompoundBody performance

[BrianL]

The project I'm working on is making heavy use of CompoundBodies. I noticed yesterday that a CompoundBody with ~182 sub-bodies, when it's contacting the ground (static triangle mesh) the update time is in the area of 30 - 40 ms. Does that sound right? Or am I doing something wrong? If that is correct, is there anything I can do to help bring that time down?

This is on the PC (with a fairly modern processor), with the final target being the 360.

[Norbo]

That sounds very high, unless the triangle mesh is very detailed at the point of impact and most of the 182 subbodies have boundingboxes which overlap most of those triangles. 30-40 ms on the computer generally takes thousands of collision checks per frame to reach.

How many collision pairs are registered during the slowdown? A little repro-case would help if possible.

[BrianL]

Okay, that's the answer I was hoping for.

A little more info/context on the situation and the desired functionality is that I'm building objects out of cubes (currently 13x13x13). With the cubes acting as the sub-bodies of the CompoundBody. I realize 13x13x13 = 2197 and that's a pretty sizable number. I may end up providing the physical space of 13x13x13 cubes but only allowing maybe half or some smaller number than that for performance reasons -- if it comes down to it. The goal is to have a handful of these CompoundBodies in the game -- possibly 8+ active at any given time.

The static mesh is not super fine tessellated, but I'll get the exact numbers for you this evening. And no, the CompoundBody is not overlapping much of the static mesh. If need be, I can put together some video footage of it the scenario and/or provide source. Thanks.

Edit: I'll also check the number of registered collision pairs this evening as well.

[BrianL]

Okay, here are the details.

The ground geometry is 512 tris. Each cube is represented by a Box. There are 4 upward impulses being applied each frame, however those forces are eventually overcome as more cubes get added and the CompoundBody finally touches the ground.

[Norbo]

I'll do some fiddling around with this soon. Things are a little hectic right now; I should be able to get to it on Wednesday.

[BrianL]

I'll do some fiddling around with this soon. Things are a little hectic right now; I should be able to get to it on Wednesday.

Much appreciated.

[Norbo]

I've done some tests on a compound body composed of 8x8x8 (512) cubes packed tightly together bouncing around on the demo playground mesh as a baseline. In most areas, the physics time was around 2-4 ms (on a Q6600). When it was near larger diagonal triangles (with poorly fitting AABB's), this time could increase to about 5-6 ms.

Near one of the diagonal sides of the house on the playground mesh, all 512 cubes were being repeatedly tested against multiple large triangles, which pushed the time to about 13-15 ms. If I put it near the roofline on a diagonal side, it could go as high as 30 ms. The number of collision pairs in this situation was 4,000 to 6,000.

Do you observe similarly high collision pair counts, particularly near diagonal surfaces? If so, you may get a performance boost by actually increasing the number of triangles in the mesh (on diagonal surfaces mainly), so that each one has a tighter bounding box. Another more difficult solution would be performing some combination algorithm while you're building the character so that contiguous blocks are represented by single entities. For most characters, this would likely drop the number of entities involved significantly.

To make it run quickly on the Xbox360, aggressive approaches like combining shapes and limiting the maximum number of boxes will most likely be needed.

[BrianL]

Well, your test case is already significantly more stressful than the situation you see in the screenshots above. As you can see in those shots, I only have 36 cubes at the point of contact, with 140 collision pairs. This is making me wonder if I've possibly got something setup wrong with the physics space, or if on the EntityUpdate callback I'm doing something bad. I'll take another spin through the code and profile some additional suspect areas and report back.

I haven't been moving the object around while it's in that state, so I don't know if things get better or worse depending on its location relative to the ground mesh.

15-30 ms is somewhat manageable if I run things in parallel -- i.e. a rendering thread along side the main update thread, although in the end, I'm not sure if rendering is really going to consume that many ms -- will just have to see. Any guesses as to what you think 15-30 ms on the Q6600 will translate to on the 360? I'm thinking at least 2x slower?

And yeah, I may have to write some dynamic welding/combining entity code to help reduce the load.

[Norbo]

I went ahead and did the same test (about 5,000 collision pairs putting the compound body near the hut) on the Xbox360, and it came out to 350-400 ms. This is pretty much in line with expectations; the Xbox360 under the CF generally runs about an order of magnitude slower.

But yes, those 36 blocks should definitely be running faster than 13 ms. Given the 140 collision pairs, the total run time should be much closer to the baseline 1.11 ms of the first picture, maybe ~2 ms (on the PC).

[BrianL]

Okay, after digging around a little more I've discovered that the physics update time doesn't spike up until I start calling ApplyImpulse on the CompoundBody while contact is being made with the static triangle mesh. It's 100% reproducible. I don't know how easy it would be to add a user controllable impulse or even a persistent ApplyImpulse call every frame to your test case CompoundBody. But I suspect if you are able to do that, you should see what I'm seeing.

[Norbo]

Testing it with the BEPUphysicsDemos application with the GrabConstraint (the right click and drag function), which calls ApplyImpulse every frame, produced no noticeable unusual slowdowns. Could it be that the compound body was inactive until the ApplyImpulse was called (waking it up and slowing things down)?

[BrianL]

Testing it with the BEPUphysicsDemos application with the GrabConstraint (the right click and drag function), which calls ApplyImpulse every frame, produced no noticeable unusual slowdowns. Could it be that the compound body was inactive until the ApplyImpulse was called (waking it up and slowing things down)?

I stripped everything off that I could think of last night. I didn't add the EntityUpdated callback, and that didn't change anything. Then I remembered the upward forces at the four corners that I was applying using ApplyImpuse. Once I removed those, that seemed to stop the slowdown. I also have it setup to apply an impulse in the forward direction based off user input. Which is where I was able to confirm that ApplyImpulse was what was exposing the slow down. With the four upward forces removed, the CompoundBody just sits on the static mesh as expected and as I add more and more cubes, nothing time-wise really changes (which is good). However, when it's sitting idle on the ground there are no collision pairs registered either. I'm assuming that's because it's at rest. Once I pull the trigger and ApplyImpulse starts getting called, the collision pairs jump up to around ~140 or so, and things slow down.

I can put together a small video if that would help.

[Norbo]

The lack of collision pairs was indeed due to the compound body sleeping. However, nothing in that situation strikes me as out of the ordinary except for the excessive slowness that you get with 140 collision pairs. As a control group, perhaps you could try making a small modification to demo #28 (Playground) in the BEPUphysicsDemos project? It spawns a bunch of separate boxes which fall onto a triangle mesh, but it's trivial to change the code to add the boxes to a CompoundBody instead.

I believe I understand the situation, but if you'd like to make a video, maybe I can somehow spot something strange in it.

[BrianL]

Okay, I'll play with Demo #28 on my machine and see if I can get it to happen. I'll try to get around to it this afternoon.

[BrianL]

Wow, I'm inserting foot into mouth as I type. My timing code was flat out broken -- I was accidentally multiplying by 10000 instead of 1000 to convert my fractional seconds time to milliseconds.

My sincerest apologies. Everything is good to go.