Newton Dynamics Integration


Here is a video of the physics world scale set to 1/16:


Porting The Urho3D Vehicle Demo to use Newton Dynamics. Steering is now properly controlled by a hinge actuator instead of applying a strong counter torque to over control bullet’s weak joints:


Adding the SliderConstraint to the vehicle demo (not a raycast car):


What is the status of the Newton Dynamics integration? Is it production ready yet (or at least at in testable state)?

After spending months building a world at realistic scale, I’m getting sick and tired of Bullet letting objects fall through the floor and other objects hovering above the ground, etc. I’d really like to try another physics engine in the near future.


It is very much in a testable and perhaps even usable state. It is built on the rokups branch.

you can try it on

The things that come to mind that need finished.

  • basic physics demo needs restored to its simple former self. (I have used that sample as a testing ground)

  • Improve the cmake integration.

  • Tool/Resource support for Importing Compound Collisions From meshes using

  • Shape to Shape “RayCasting”

  • Kinematic Bodies mode for RigidBody (should be simple just have not tried it yet)

  • world scale feature has a small bug in it (some small bug I intruduced recently)

  • add the double precision option

Newton also relies on a constant update rate (which Urho should have but doesn’t) It still works without it but is much more stable if you use my branch:
which changes the Engine.cpp to prioritize constant update rates.

Another fun video:


I started having a look at this and it looks promising.
Is there a way to enable the profiler statistics in the samples like in the original Urho samples, I’d like to compare the performance of Newton with Bullet in Sample 12 “Physics Stress Test”? Thanks.


I did this awhile ago - you can use tracy to profile:



Here is a link to the discussion thread:


Newton is certainly more accurate than Bullet, but it costs something for that accuracy - what is your use-case that requires such accuracy, and how does it apply to a game engine? Oh - and did you try Bullet with double enabled? real8 is a lot more accurate than real4 floating point


In my tests I’ve found newton to be on par with bullet as far as performance is concerned. I use this integration because of the rigidity and accuracy of the simulation. Constraints are rock solid and don’t suffer from joint wobble near as much as Bullet per the same iteration count/cpu cycles.


@TrevorCash for real solid joints you shouldn’t have simulated joints at all, but a single rigid body with the colliders (aka compound). Is there anything preventing you from doing that in your use case?
Edit: I just realized you might be talking about joints other than fixed, like for example hinge joints… you have to sim those ofc


Hi Alan, Yes of course, if you have 2 bodies with no degrees of freedom its best to make a compound. Its pretty easy with the API just add multiple CollisionShape components and 1 RigidBody component to a node. The RigidBody will use all attached CollisionShapes and form a compound internally.

If you look at the motorcycle video - the midframe of the bike is a compound formed this way.

with regards to joints - yes I am talking about well, the joints :slight_smile:


Performance from code only represents a percentage of your overall performance. A bunch more can be obtained from well crafted assets.

@TrevorCash This looks good man. I tried the vehicle demo on the Newton demos and it definitely controls better than whatever Bullet has. So far I like this.


My biggest problem with Bullet is the size limit of the dynamic objects:
“The minimum object size for moving objects is about 0.2 units, 20 centimeters for Earth gravity.” quote from Bullet’s manual. And also the largest size is about 5 or 7 meters (from what I remember).

So if you want to do a survival game and you want to have a box of matches which is 5 x 2 x 1 cm, you can’t do it with Bullet, as it’s too small and the object will fall through (the terrain or other objects) when you drop it. So, I tried scaling up the whole world to try and make the smallest object large enough, but then if you want to have vehicles, than you exceed the upper size limit and also if your terrain is too large, you start loosing float range accuracy (going to double would most likely affect performance). I could also try increasing the simulation rate, but then again you are reducing the performance of the game.

I’m hoping Newton can handle a wide range of sizes for dynamic objects (I’m yet to find out).


Bullet Dynamics works best with objects whose size ranges from a tennis ball, to a bus.
Outside of these limits, the numbers get too big or too small for the default 32 bit math.
You can switch your build settings for Bullet to use 64 bit math (double floats) and this gives you a much richer experience, with generally the same performance as 32 bit, just a greater numerical range to work with. I don’t know if Newton has some magical way to deal with numerical precision, but I suspect it uses 64 bits by default, where the platform can support it.

Oh, and the limits mainly apply to dynamic objects. Static objects can be enormous, Kinematic objects suffer tunneling issues at your discretion, and CCD helps a lot with tunneling on dynamic objects at high velocities, even on 32 bit precision. I would say that Newton and Bullet are similar in performance, except where it comes to things like impulse chains, where Bullet offers things like featherstone solver, but Newton uses classical iterative methods in its resolvers.