I basically require the ability to do intersection testing on spheres, boxes and capsules in 3D, and really not much else at all. I am wondering if the overhead (both in code and time spent learning) of using a full-blown engine like bullet or ODE is really sensible in this case? I imagine I could quite easily knock these level of tests up since my math is fairly good and I know the principles, but I prefer not to if there is some option which will get me up and running even faster. I wondered if there are any simple libraries out there focusing on ease of use and simplicity rather than massive featuresets?

Any advice welcome :)

I basically require the ability to do intersection testing on spheres, boxes and capsules in 3D, and really not much else at all. I am wondering if the overhead (both in code and time spent learning) of using a full-blown engine like bullet or ODE is really sensible in this case? I imagine I could quite easily knock these level of tests up since my math is fairly good and I know the principles, but I prefer not to if there is some option which will get me up and running even faster. I wondered if there are any simple libraries out there focusing on ease of use and simplicity rather than massive featuresets?

Any advice welcome

The temptation to roll your own in these kinds of situations is very strong. I am certainly guilty of it :-)

Nonetheless, I would recommend using an existing, open-source library... like bullet! There are two reasons for this recommendation. First, there are often lots of little niggly things that you are going to want in order to work with your spheres, boxes, and capsules, e.g. the ability to rotate and translate those shapes. So you need a vector class and then something for rotation... should you create a matrix class or a use quaternions? The list goes on. The ability to tap into functionality that already handles this is really nice. Secondly, if your usage is really minimal you may find a library where you can essentially take the standalone classes you want and simply incorporate them into your code base in whatever way works best for you.

-Josh

I'm not averse to using an existing library, but something like bullet is in my view perhaps a bit overkill... you have to write new code to get bullet running and so on. standard maths classes (vector, plane, matrix) are already provided by my rendering engine so the basics are in place.

I was wondering if there is a much smaller library that does basic stuff as a trade-off... avoid rolling my own but also avoid adding a large library to my project that every developer has to build, etc - the time to get something like bullet building across multiple OS and then document this for other developers is potentially more than rolling from scratch.

So a simple lib I can drop-in would be the perfect solution to me. Tried and tested but small and focused.

A resource you might consider if you want to roll your own is to find a library written in C# or a .net language that does these things, then use reflector to look at the code to see how it was done and pattern your own after it. Xna has all the methods you require built in and is openly available to look behind and study.

Do you need proper collision response or just basic detection.

Collision detection is pretty easy if you know what you are doing.

i.e. to write a sphere vs triangle, sphere vs box, box vs capsule etc... it fairly straight forward.

You then might need some structures for broadphase.

If you do not need solid collision resolution then you should be fine to roll your own. Managing contact resolution though is a whole new beast - and a scary one at that.

So in summary, if you only need the detection - roll your own or take a look around there are plenty of collision detection libraries out there (or at least well structured engines where you can just take the detection package). If you need rock solid resolution of said collisions, i.e. anything more complex that simple reprojection or stopping, then I would run with a full lib such as bullet.

I use Bullet for my physics engine but for simple intersection tests I use a homemade solution. Just a few functions like:

int sphereBoxTest(vec center, float rad, vec bMin, vec bMax);
int sphereSphereTest(vec center0, float rad0, vec center1, float rad1);
int sphereRayTest(vec center, float rad, vec start, vec end);

There dead easy to implement and plenty sample code exists on the internet. Using these tests for non physics related intersection tests (frustum culling etc) will keep bullet restricted to the physics portion of your code in case you want to ditch it at any point.

I am wondering if the overhead (both in code and time spent learning) of using a full-blown engine like bullet or ODE is really sensible in this case?

It is never too early to start learning a library. No idea what is overhead in terms of "code", are you referring to LOC? Library itself weights 0 LOC to maintain. As for the glue code... as suggested by someone yes, there is going to be glue. How much depends on your level of sophistication and integration. It's probably less than just writing your own vector, matrix and quaternion classes, let alone doing the work.

In terms of learning, you only have to gain by using a library.

Someone seems to suggest to avoid using a library for simple cases. This is of course doable but it will be a day in which simple physics will be no more sufficient. I want to ask those people, why should anyone spend effort twice? Personally I have decided to be bold: people saying you don't need a library are doing a disservice.

And by the way, in case you want to use Bullet - don't worry about giving it non-physics data to mangle. It's all numbers in the end.

In that case I will expand on my reasoning.

For a simple 3D game with a level mesh and some obstacles I did a "roll your own" collision system.

Because I had already written the rendering engine I had code for matrices vectors and planes already.

All the levels were less then 15,000 polys so I wrote a super quick function to store them in a 32x32 grid structure.

So to test a sphere against it results in about 20-30 triangles being tested in a sphere vs triangle routine.

Very little code and adequately satisfying results. It was easy to integrate and very very fast.

BUT - and there is usually a but - this was only suitable for the situation and will not suit most use cases.

It was a simple game with only very basic physics, gravity/collisions/orient-to-surface, that kinda thing, no full blown rigid body dynamics. So no proper rotations, inertia, mass or any of that stuff.

If I had more bodies in the levels with more realistic physics then and engine would have been the way to go. It would have been overkill for me though as it was a simple environment.

So it does truly depend on the situation, including what resources you already have available and you knowledge level.

My situation is I'm a professional developer, my aim is not to learn for its own sake but to get something working in the shortest time. I like learning new tech BUT when in work mode chasing a specific deliverable, I prioritise the destination rather than the journey! Hence in this specific case where I know the requirements of the application do not involve more complex physics, I am purely after whatever would be quickest to implement overall :)

My situation is I'm a professional developer, my aim is not to learn for its own sake but to get something working in the shortest time. I like learning new tech BUT when in work mode chasing a specific deliverable, I prioritise the destination rather than the journey! Hence in this specific case where I know the requirements of the application do not involve more complex physics, I am purely after whatever would be quickest to implement overall

Bullet physics is really quick and easy to get up and running quickly but the documentation is a little sparse after that.