stacking 1000 Boxes using BULLET

[thatname]

Hello all, i am game developer in China, I want to use a physic engine in my project, so i did some experiments:

I modified the APP_BasicDemo to stack 10 x 10 x 10 = 1k Cubes ,
at the beginning of the simulation , before the cubes reach ground plane , simulation takes 50ms per frame, after that ,the simulation takes 15ms per frame on average.

I also tested tokamak physics library for the same situation , unlike bullet library, the frame rate never goes down before all the 1k cubes collide with the ground plane. after that , both engines performance are comparable.

I have idea , why ?

[dphil]

From the Tokamak website:

Tokamak is specially optimized for stacking large number of
objects; one of the most frequently requested features by game
developers.

I'm guessing that's why. Though if you are asking exactly how Tokamak does it compared to Bullet, I don't know.

[thatname]

I think, tokamak may doing something like this:

in each simulation step:
1. sort all box along the gravity vector in bottom - up order .
2. move down the bottom layer of boxes ,check collision ,obviously there is no collision at all, so no contact point is generated.
3. move down the next higher layer, until all layers of the stack is moved,
4.next simulation step....until the bottom layer of boxes hit the ground plane .

is it?

is this kind of optimization possible with bullet engine?

[dphil]

Perhaps something like that. In essence, an arbitrary set of touching rigid bodies with no angular velocity, same starting velocity, and all being acted on by the same force (gravity, typically), can be treated as a single moving body, since all their transforms should change identically at each step (ex. origin.y -= ...). So it doesn't process any contacts. Just a guess.

[thatname]

yesterday i tried Nvidia's proprietary physx engine with the same scene, surprisingly it is not optimized like tokamak , before the 1k boxes reach ground , it runs slowly at 30 fps. open sourced tokamak outperforms physx.

[Dr.Shepherd]

I don't know much about tokamak, but from the dates of the website, it seems that it is not actively updated at this moment.

If you want to get a comprehensive comparison of current physics engine, check this paper:
Evaluation of real-time physics simulation systems.

Download Link:
http://dl.acm.org/citation.cfm?id=1321312

[dphil]

If you want to get a comprehensive comparison of current physics engine, check this paper:

Well, that paper is from 2007. Bullet has matured a lot and several other notable ones have somewhat dropped off the radar or otherwise stopped development since then.

[Dr.Shepherd]

If you want to get a comprehensive comparison of current physics engine, check this paper:

Well, that paper is from 2007. Bullet has matured a lot and several other notable ones have somewhat dropped off the radar or otherwise stopped development since then.

Yeah, that's right, I should point out that in case confusing others. It seems that there demands for an up-to-date version of survey on Physics Engine. Does anyone find some useful information?

Actually, Bullet is the first and only Engine I used. Even though it lacks for documentation, this won't be a big problem if looking into the code. I believe and support Bullet !

[Flix]

Personally I'm not too much interested in performance comparisons between physic engines, but in case somebody is, here is another link about it: http://bulletphysics.org/Bullet/phpBB3/ ... mance+test.

PS. Maybe sorting custom sets of rigid bodies (marked with a "stack flag"?), ordering them by their -Y position, before simulating them could help avoiding some collisions but I think that:
1) Manifold points can be created when distance is slightly positive (so a too packed falling stack wouldn't be faster).
2) Sleeping bodies should be moved to their own list to speed up sorting.
Thus I'm not sure this optimization would work in Bullet AFAIK.
Merging a huge number of non-rotating rigid bodies into a single shape should be something left to the end user (like in the glue/fraction demo): it's a too "specific" hack in my opinion (but I'm not a Bullet developer, nor I have a very good knowledge of the Bullet internal code...).

[monkeyman]

Merging a huge number of non-rotating rigid bodies into a single shape should be something left to the end user (like in the glue/fraction demo): it's a too "specific" hack in my opinion (but I'm not a Bullet developer, nor I have a very good knowledge of the Bullet internal code...).

I looked at the fracture demo and it's replacing the entire btDynamicsWorld. That code is as much a hack as any other... you definitely don't want the user to have to write that code to do this optimization. But the strategy is sound (turn touching objects into a compound, treat it as such until an impulse is applied to it over a threshold, then split again) and I guess this derived class should really be optimized and be available as a part of Bullet.

In any case, the OP has a good point. I too tried the exact same thing with the same result - a lot of wasted CPU cycles for no appreciable result, is the first reaction

I guess the ideal optimization here should work to speed up contact processing and constraint solving when objects touch by very rigid constraints (either implicitely through friction or by point-point constraints). Sort of like how it's done in the fracture demo, but better integrated into the engine.

[Flix]

[...] you definitely don't want the user to have to write that code to do this optimization. But the strategy is sound (turn touching objects into a compound, treat it as such until an impulse is applied to it over a threshold, then split again) and I guess this derived class should really be optimized and be available as a part of Bullet.

I think that the Bullet developers are now mainly focused on Bullet 2.x bug fixing and on Bullet 3.x development.

Moreover a class that merges touching bodies on contact into a btCompoundShape requires some non-trivial steps:
1) Transparent collision detection handling.
2) Extending the btCompoundShape so that it can store btCollisionObjects as well as other collision shapes (when we release objects their properties, like their center of mass offset, friction, restitution must be available).

All this stuff just for speeding up different rigid bodies that are falling without any difference in linear and angular velocity; and the different objects can have different friction/restitution while falling together (until an impulse is applied to them over a threshold): so a custom material callback should be used to achieve this (and the custom material callback is typically left to the "client" code, ie. not a part of the library).

In short, I'm not saying that it's impossible, but I guess that it won't be easy for us to see such a change in the official Bullet 2.x library

[monkeyman]

All this stuff just for speeding up different rigid bodies that are falling without any difference in linear and angular velocity; and the different objects can have different friction/restitution while falling together (until an impulse is applied to them over a threshold): so a custom material callback should be used to achieve this (and the custom material callback is typically left to the "client" code, ie. not a part of the library).

In short, I'm not saying that it's impossible, but I guess that it won't be easy for us to see such a change in the official Bullet 2.x library

Actually I think there are many cases where this is needed apart from the "together in free-fall" benchmark-case of dropping stacks of boxes.

Many games are starting to involve creative elements (like MineCraft for example) where you want to be able to build up compound objects from sub-objects and they should obviously be able to break into their constituents then as well. But while they are held together in their compound shape, actually simulating and keeping track of contact manifolds, interpenetrations etc between every part of them gets very expensive.

If the compound shapes really are normally non-moving, like if you think of houses in a city, then I guess it can work currently since the objects will be sleeping. But if you want to involve moving compounds as well (not just free-falling) you run into scalability problems pretty fast currently I guess, since you'll have forces acting on one end of a compound and the sub-objects' impulses will cause ripples of updates all across the compound.

Maybe there other possibilities to handle something like this in Bullet now? For example a rigid constraint-contact which simply propagates the impulse from one object to another without any calculations?

[Flix]

Actually I think there are many cases where this is needed apart from the "together in free-fall" benchmark-case of dropping stacks of boxes.

Yes, I'm aware of that.
Personally I agree that the glue/fracture demo is not flexible enough in many cases if it uses a custom btDiscreteDynamicsWorld, and that an extended btCompoundShape would be better.
Anyway this is slightly OT ("thatname" was talking about performance of dropping stacks of boxes).

Maybe there other possibilities to handle something like this in Bullet now? For example a rigid constraint-contact which simply propagates the impulse from one object to another without any calculations?

I don't know