Hello and greetings to the game development and programming community.

I hope this is the right section for this thread.

I am looking for a good quality 3d physics engine to integrate into my 3d Game Engine built using DirectX 11 and C++.

Creating my own physics engine is likely going to take a long time and I don't think I could take on such a challenge at this point. The problem is that I don't have enough programming experience specifically related to 3d physics (although I'm reasonably well versed to high school and even 1st year university physics).

I have looked around the world wide web and I have found a few sources, such as Vortex, Bullet and PhysX. I would like to use the last one, which is made by NVidia since I have utilized and programmed its technologies before, especially with CUDA.

I would appreciate to hear any opinions regarding various such physics engines, if you have any suggestions as to which one I could use, which one would be sufficiently easy to integrate. If there are any tutorials or practical books maybe? I've looked around a few docs & resources for PhysX but those are extremely limited and probably outdated. I require information from more experienced people in this field.

Some suggestions would be very welcome indeed.

Remember my 3 key requirements though: 1. Windows API, 2. Direct3D, 3. C or C++.

And keep in mind 4. (not a requirement, just a desire) Nvidia PhysX.

But really, suggestions, advice and discussion about any kind of 3d Physics engines are welcome.

Thanks.

3 hours ago, KeyC0de said:

I've looked around a few docs & resources for PhysX but those are extremely limited and probably outdated.

Probably that's the case with almost any physics engine, but they all have forums if you experience a problem.

I have experience with ODE, Havok, Bullet and Newton, in that order. 

Havok was quite good and had quite interesting features to mix character animation and simulation. (I do not think it's free anymore?)

Bullet was a disappointment - neither fast nor accurate. Lots of jitter, even with just a stack of two boxes. Joint with elliptical cone limit was broken and no motor support.

Newton was a total surprise. Unbelievable the work of a single man was so superior to anything else. Very accurate and robust, even with large mass ratios. Custom motorized joints can be made easily. And those joints were good enough to simulate a walking ragdoll at 120 Hz. No need to make a custom torque solver for this purpose which would be necessary for any other engine. Performance is comparable to the 'big' engines. No support for soft bodies or cloth yet.

I have never used PhysX. What i hear from others (and see in games), accuracy is probably below Havok but better than Bullet and performance is good. Most interesting if you want GPU stuff like fluid, soft bodies and cloth, but with a limitation to NV GPUs that's either an optional detail option or no option.

Keep in mind my experience with other engines dates back a whole decade and i prioritize accuracy, because i'm interested more in active stuff like robotics than in passive stacks of some crates in the background. Anything you hear is subjective. Performance is different to compare because you have to match quality first. There is a tool for comparision, 'PEEL', made by an Nvidia employee.

3 hours ago, KeyC0de said:

Remember my 3 key requirements though: 1. Windows API, 2. Direct3D, 3. C or C++.

Physics engines are independent of graphics APIs, usually cross platform and C++. (Rare exceptions, like some written in C#)

3 hours ago, KeyC0de said:

And keep in mind 4. (not a requirement, just a desire) Nvidia PhysX.

As you did not list any specific requirements, that should not be a bad choice. It depends on what you want to do.

Interesting.

Bullet would be my 2nd pick, since I know it's considered fast, plus it is heavily actively maintained and there is enough documentation to get me started fast.

I have taken a look at Newton, it is impressive indeed but somewhat slow and I don't require extreme levels of accuracy.

At least PhysX user guide is well written and freely available as well as the source of course. I will have to read the license more carefully though, as it seems shady.. (could be the reason why there aren't many tutorial around). When I get around to it I'll update the post.

Thanks for the info. If you have anything else please add.

Hi, I have experience with Havok and Bullet physics. Both are easy to integrate, and not dependent on platform or graphics API. Both support rigid and soft bodies. Bullet is completely open source MIT license, while you will have to buy a Havok license and you get no access to its source, just precompiled libraries (I tried it several years ago, when it had free demo for students). You can visit Bullet forums which are helpful, but with Havok you will likely get private support just because you paid for it. Havok has better debugging tools out of the box. For instance, you get a stand alone debug application that will visualize the physics world if you connect it to your game and lets you pick and objects with mouse, etc. Very helpful. With Bullet, you can use its OpenGL debug visualizer (I never tried it), or you can also overload callback functions and do your own debug rendering.

Right now I am using Bullet physics in my engine and fairly satisfied with it (although mainly I just use simple stuff). I would recommend first try Bullet, because it's free. You can take a look at my bullet physics wrapper which is less than 500 lines now and supports rigid bodies (sphere, box, convex mesh, concave mesh) and soft bodies (cloth, or any kind of mesh): https://github.com/turanszkij/WickedEngine/blob/master/WickedEngine/wiPhysicsEngine_Bullet.cpp

I also use Bullet for my engine, because it's free and relatively easy to integrate without any dynamic linking, just a bit of a header mess when you include internal things for modification, but that's more to blame on C++ legacy. Bullet is not as soft as Newton, but it's required to use continuous collision detection and catch small fast objects. I only use rigid collisions when the car hits something on the metal, because I implemented my own Stribeck friction model for wheels.