While Bullet works fine for simple scenarios, but once more complex things are needed it performs poorly.
Bullet has a maddening trait which is collision margins:
Using 0 collision margin breaks raycasts and convexcasts, and possibly more things, so it isn’t really an option.
Collision margins create rounded corners. For example with character controllers it breaks combining maximum climb slope and auto stair stepping algorithms, because stairs are now round and have portion of steep slope.
It causes small unexpected bugs too. For example my monster AI code has ledge detection that first checks if the monster stands on the ground, and because of collision margins it always missed. I solved it my moving the raycast up by the collision margin length.
Also the roundness only apply to some of the shape-shape collision combinations (which is btw not documented and only explained in this video).
Bullet also uses force based recovery from penetration, which can cause bad behaviors.
It may be the cause of bumping between convex hull floor segments, a body slightly penetrates the floor and bumps into the side of an adjacent floor body. (trimesh has edge connectivity utility that deals with that, but not convex hull)
Also, while trying to implement a character controller with advanced features (more than just pushing a rigid body), I’ve run into a lot of problems, and most of them led to catch-22’s with some broken feature in Bullet. for example:
Using 0 margin to avoid round stairs breaks ray/convex casting.
I find Bullet unsuitable for games which have complex environments, or require an advanced character controller, and those are quite general cases.
I don’t know how Newton Dynamics compares to Bullet, but AFAIK it doesn’t use collision margins which is a huge advantage over Bullet, so maybe it could properly handle things Bullet can’t.
Did anyone use Newton Dynamics, especially recent versions? Are there any problems with it?
I also wonder if physics engine choice could be abstracted under Urho’s Physics API?
If not would it be similar like choosing between Lua and AngelScript?
That was the first thing I tried, it doesn’t fix it. Neither does changing the collision margin, or trying to use capsule instead of a cylinder.
This one isn’t even a catch-22 that you could try to do magic to bypass, you simply can’t do anything about it.
Anyway this is not a support thread.
The thread is about if there are other Physics engines that function properly where Bullet breaks.
Newton Dynamics seems like the best candidate for this role - It doesn’t use collision margins, it has ray & convex cast, it’s actively developed, it’s documented.
Isn’t maintaining multiple physics engines going to be hell on Urho3D core developers? I don’t recall seeing lots of manpower handling the various things needing to get done. For the most part I’ve seen 2 people doing most of the work. Although possibly I have a limited perspective on how Urho3D contributions flow and how they are maintained. Anyways I’m generally aware that the more doo dads are added to an engine, the more maintenance effort is watered down. I suppose I would ask, what is so broken about Bullet that it can’t be fixed? I don’t have any experience with it really, I’m just asking. And, why can’t it be fixed upstream of Urho3D?
The fun thing about Urho3D’s use of systems is that you can bring in another physics engine without having to do anything with the original physics engine. It’s just a set of components. Just create the components that controls Newton’s system instead and refrain from using the Bullet components. Boom, integrated.
On that note, I have a basic Newton implementation already in place for libblu. So far only boxes, but I only spent a few hours on it.
That’s true. I’m proposing adding another engine because Bullet has traits that could make it less suitable for specific tasks, so another engine could help to better cover the engine’s possibility space.
bvanevery is quite spot on regarding the core developer manpower. It would be no problem to integrate Newton as an option (I will not make comments on its quality since I’ve not tested it personally in depth) if we got a contributor who does the integration and is then willing to maintain it. In general Urho3D’s problem is accumulating features while former steady contributors become inactive, leaving for the most part me and Yao Wei Tjong to maintain the whole.
One thing I’ve noticed on Newton is that it doesn’t support MinGW. For example, it looks for _MSC_VER instead of _WIN32 to identify windows platform in macros. Includes a little non-standard(?) code as well. For example, uses members of types with constructors in anonymous structs/aggregates.
While these are minor and can be fixed with a quick find and replace. It makes me believe that the library never even considered MinGW as a potential compiler. So there may further issues. (actually there are a few more)
The build system(s?) is pretty broken. Especially for Windows. But then again, that’s true for most other physics engine library out there.
Yeah it does need some love when it comes to the build system. Julio seems pretty open to pull requests regarding details like that.
Currently I am linking using objects and that is working very simply. I was able to cut out the project files and extra cmake stuff that was part of the newton sdk. I would like to get it linking using dlls though.
Terrain and Scene Collisions are working now. As well as the Kinematics Joint that is used to pick up the objects with the camera. (super useful if you just want a rigid body to go somewhere while still regarding physics laws)
Random CollisionShapes are added to the scene node at random transformations (and scales). When geometry is part of the scene collision - it is very fast and you can add lots of geometry. It is faster than spawning individual nodes with rigid bodies and collision shapes and setting their mass to zero which of course will have the same effect.
It’s nice to have another option besides Bullet, however I would have preferred nVidia PhysX. It seems to be the engine of choice for all major commercial engines (Unreal, Unity, CryEngine/Lumberyard, etc). Also it has a couple of game specific features that I like: world center shifting (useful for large worlds) and setting a scaling factor when initializing the engine (so you are not stuck to the 5cm-10m range of Bullet).
I seem to remember reading newton has a scaling feature - I’ll look into it. Also has double precision as an option.
I myself would have a hard time using phys x in any scenario - Its integration method is fast but not as stable as newton.