anybody here use BULLET?

Based on your item #2, my assumption is that when you say "collision detection"....what you really mean is "rigid body dynamics + collision detection," or "collision detection and response" since collision detection alone has nothing to do with stacking.

So, I've used Bullet, and have integrated it with a couple of rendering engines (OpenSceneGraph and Ogre----even though I believe there is an existing integration with at least Ogre, I had a more specialized need and so did my own lightweight integration).

Bullet's collision detection system can support all of the things you mention. In fact, bullets colliding with geometry or characters can be a challenge for many collision detection systems, due to an artifact called "tunneling" where collisions involving fast-moving objects are not detected. The Bullet engine has so-called "continuous collision detection" (CCD) which can detect collisions with very fast moving objects such as bullets. (You might decide that the Bullet library was probably named because of this feature.) So in this sense, if you are going open source, Bullet is an excellent choice for your item #1.

As for item #2, yes, of course you can do stacking with this library. Any modern, complete rigid body dynamics engine will support stacking. (But this is not part of "collision detection.") Bullet, ODE, Tokamak, Newton, all freeware or open source rigid body dynamics engines...all of them can do stacking. In fact, stacking is automatic, as long as you use their system for rigid body dynamics.

The interface to Bullet is straightforward once you know something about rigid body dynamics. I have a background in physics and graphics...not sure where you stand, and I've done this a few times, but I am able to do a basic working integration of Bullet and a graphics engine in a day. This doesn't mean the art pipeline is all there in a day, and the system won't be optimized, but getting the physics loop working, tying physics engine objects to graphical objects, and putting together a basic demo would take me about a day starting from scratch. That is slightly more than just mad coding...does allow some time to read and figure out subtlties of an API. Most of the available physics API's are comparible in terms of their API and the way to integrate. They all should provide mechanisms for adding "extra" data to physics objects and/or visual/rendered objects to make it easy to tie them together. Your own progress would depend on your level of comfort with the graphics engine and physics in general. My assumption is that you may be a bit less experienced with physics and collision detection concepts, and so you'd spend more time on this. But a month seems reasonable as a conservative expectation.

I'm all for open source, and of all the engines I mentioned I would probably suggest Bullet as my top choice...other folks might come to different conclusions, as all the engines have their strengths and weeknesses. (I have used ODE. There is some nice flexibility there in terms of being able to make fully custom joints, but its user community seems less active than Bullet, and it does not have CCD.) One other thing to consider is that performance might be better with a commercial library. The Ageia PhysX library provides the same features as Bullet, including CCD, and more (fluids, explicit support for cloth and soft bodies, better automatic support for breakable/tearable objects, and support for hardware-based physics using Ageia's hardware)...PhysX in some cases might provide better performance than Bullet, and the licensing terms are very agreeable to hobby and independent/minimally or unfunded developers as long as your code uses their hardware when present (reverts to software when the hardware is not present). All things being equal, I'd suggest open source. But the extra features and potential performance improvements might be something you'd want to consider. Engine integration, for basic rigid body dynamics and collision detection, are going to be roughly equivalent to Bullet and the others.

My experiences with physics engine are:

1. writing my own:
Bad idea ! :)

2. trying out newton:
It is really ok, good documentation but got some issues with my special requirements.

3. bullet:
Currently using it, seems to be really stable and meets my requirements, but there is the problem with the documentation. The documentation is somewhat 'thin'. Often I've to analyse the bullet code to understand some features or parameters. It is ok for me, but it might be a little bit too frustrating if you're not so experienced.

--
Ashaman

Well, personally my hobby is building my physics library (along with collision detection), so I'm working on that at the moment :).

In any case, I didn't actually use Bullet. I looks very promising, for me as a sort of reference to learn from, but it looks very solid.

ghrodes, you said something about the licensing of PhysX. Can you elaborate ? If their library is closed source then I wouldn't be able to learn anything from it hehe

Yes, PhysX is closed source, and I recommended to consider it as a tool for production work, not to learn how to write a physics engine. Bullet or one of the other open source ones would be better to learn.

I'd agree with Ashaman73's comment that the Bullet docs are quite thin indeed. A lot of people use the forums to fill gaps and find examples, and the bullet forums are pretty good. I think ODE docs are a bit better, but again that library doesn't seem to have as much active development as Bullet. Depends on what you want.