integrating speedtree 5.0

[gjaegy]

Hi,

I am currently working on a SpeedTree 5.0 integration.

As you might know, speedtree API gives access to a collision shape for each tree instance, being made of some capsule shapes.

Now, I wonder what would be the best way to implement this using bullet - imagine a forest of 100 trees, each being made of 5 capsules

- create a rigid body for each capsule => 500 rigid bodies with capsule shape
- create a compound shape for each tree => 100 rigid bodies with compound shape
- create one single coumpound shape for the whole forest => 1 rigid body with compound shape (500 capsule child shapes)

My concerns are mainly about performance, as I am not sure how bullet will handle this internally (one can consider the tree being static, there fore they will be inactive most of the time ?).

Now, I assume the first option is the worst one.

The third option is great when nothing moves, as there are quite a few object intersections to test. However, in the case a vehicle is driving through the forest, each capsule will have to be tested.

So to me it seems the second option would be the best one, however, the CPU overhead is quite important (OK, I have a *huge* forest). See the profiler results below. Any idea how I could improve this ?



Thanks for any input.

Cheers,
Greg

[S.Lundmark]

Hi Greg,

Which version of bullet are you currently running?

I would suggest disabling the "m_forceUpdateAllAabbs" in btCollisionWorld.cpp (line 49) if you are running 2.75. That should decrease the "updateSingleAabb" calls by a lot. The drawback of this is that you will have to manually update the aabb of static objects if you move them around.

If you want to try using the "one-huge-compound-shape"-solution, I have implemented the Quantized-bvh into the btCompoundShape and I think that it wouldn't be a problem to share that code. Our compound-shape is much larger than 500 shapes and even though we still are having some minor performance-issues with it, I think that the obstacles are possible to overcome. The benefit of using one large compound shape is that dependant on the spatiality of your tree's, you might end up with a lot less collision-pairs. Plus the dbvt broadphase will probably go a lot faster as well.

Cheers,
Simon

[gjaegy]

Hi Simon, thanks for your answer.

Actually I am running bullet 2.75.

I would suggest disabling the "m_forceUpdateAllAabbs" in btCollisionWorld.cpp (line 49) if you are running 2.75. That should decrease the "updateSingleAabb" calls by a lot. The drawback of this is that you will have to manually update the aabb of static objects if you move them around.

What about non-static objects (and kinematic ones), will their AABB be updated automatically ? In that case this will be a good solution, as I never move my static objects (otherwise I make them dynamic) - not sure why one would create static objects and move them (just out of curiosity), should then the kinematic flag be used ?

If you want to try using the "one-huge-compound-shape"-solution, I have implemented the Quantized-bvh into the btCompoundShape and I think that it wouldn't be a problem to share that code. Our compound-shape is much larger than 500 shapes and even though we still are having some minor performance-issues with it, I think that the obstacles are possible to overcome. The benefit of using one large compound shape is that dependant on the spatiality of your tree's, you might end up with a lot less collision-pairs. Plus the dbvt broadphase will probably go a lot faster as well.

Do you think this would be a better solution ? I am not specialist in the physic engine field, but I guess the quantized bvh is a kind of octree for my shapes belonging to the "one-huge-compound-shape", right ? in the other hand, if I create one compound object per tree, they should be part of a hierachical acceleration structure as well, no (I am using the btDbvtBroadphase broadphase)?

[S.Lundmark]

Hi Simon, thanks for your answer.

Actually I am running bullet 2.75.

Good, the m_forceUpdateAllAabbs set to false should give you a better performance-result then. (with the drawbacks that we are discussing).

What about non-static objects (and kinematic ones), will their AABB be updated automatically ? In that case this will be a good solution, as I never move my static objects (otherwise I make them dynamic) - not sure why one would create static objects and move them (just out of curiosity) ?

Non-static objects will have their aabb's updated automatically anyway. All other objects will have their aabb updated if their simulation island is not sleeping. I'm not sure how bullet handles collision-islands for kinematic objects, but I assume that they should be included in the simulation islands since they move around.

If you want to try using the "one-huge-compound-shape"-solution, ...

Do you think this would be a better solution ? I am not specialist in the physic engine field, but I guess the quantized bvh is a kind of octree for my shapes belonging to the "one-huge-compound-shape", right ? in the other hand, if I create one compound object per tree, they should be part of a hierachical acceleration structure as well, no (I am using the btDbvtBroadphase broadphase)?

[/quote]

The quantized bvh is an optimized spatial structure, yes. The 1 compound object / tree does include an accelerated structure, yes. The broadphase uses the dbv-tree which is a fast dynamic tree. The compound shapes themselves also use the same type of structure. Looking at your profiler results, it seems like you are spending a lot of time in the btDbvtBroadphase::setAabb, most likely because you have a lot of objects in your broadphase. This scope will go down by a lot if you have less objects in your broadphase. Changing all the tree's into one larger compound shape will eliminate that cost but instead raise the cost of btCompoundCollisionAlgorithm::processCollision. In order to minimize the time spent in processCollision, using the bvh-tree instead of the dbv-tree should give you better performance for static structures. It is very important to point out that this will only work for btCompoundShape's that are not changed during runtime. The calculation of the bvh-tree is very expensive and should only be done as a pre-calculation in either compile or loading time.

Cheers,
Simon

[S.Lundmark]

Digging around a little bit, I notice that in btSimulationIslandManager.cpp - kinematic objects don't merge islands but they wake up all connected objects. That means that they would have their aabb recalculated when they are active even with the m_forceUpdateAllAabbs set to false

[gjaegy]

OK, I have modified my code to enable this AABB optimization, and it seems to have brought a lot

This is how the profiler results look like now:


Can I do anything more ? Maybe by using tome multi-threading stuff available in bullet - not sure how ?

This is using the "one compound shape per tree" option. Do you think your other suggestion would increase the workload ?

[S.Lundmark]

That's looking much better!

Could you please provide the profiler result for btCollisionDispatcher::dispatchAllCollisionPairs(), btCompoundCollisionAlgorithm::processCollision() and dbvtBroadPhase::calculateOverlappingPairs()?

Your performance is looking quite good I'd say. The only thing I'm worried about is the inclusive samples for the dbvtbroadphase compared to the amount of time spent in your btcompoundcollisionalgorithm. If the broadphase is taking up a lot of time, it could be reasonable to move that lookup into a bvh-lookup located in the compound-collision algorithm. But I have to see the time spents in the above scopes to be able to determine if it would be worth it. I could always check if I can provide the code and leave it up to you if you want to try it out?

Cheers,
Simon.

[gjaegy]

Simon,

I was using the "one-compound shape per tree" option until now, it was fine, but now I have sever performance issue with a new level.

So, I am definitively switching to the "one single compound shape for all trees" option, so I was wondering if you would like to share your Quantized-bvh code for the btCompoundShape class ?

Thanks for that !
Greg

[sparkprime]

How does your new bvh compound shape compare to the current dbvt support in the compound shape?

[gjaegy]

Good question
if it performs better, it might be a good idea to apply this change to the main trunk, no ?