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.

1 Like

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. (Just needs more testing)

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

  • Shape to Shape “RayCasting”

  • Kinematic Bodies mode for RigidBody (Done)

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

  • add the double precision option (Done and Works)

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.

1 Like

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.

From the newton website:

Newton Dynamics implements a deterministic solver, which is not based on traditional LCP or iterative methods

Quick update - double precision is working now as well as the world scaling option.

Double precision also works with the SSE, AVX and AVX2 plugins!

I’ve made numerous fixes and refactors as well as lots of continuous testing while making my current physics based game project.

So I am happy to finally release the project!

It is provided as a plugin for rbfx but could be adapted to work with upstream urho as well. (you would have to remove the new eastl containers)

The project comes with one Sample that showcases and tests many of the functionalities of newton.

I’d be happy to answer any question to users who are using it.

and of course bug fixes are always welcome!

I plan on continued development as I work on my own project that uses this plugin.


I’ve hit limits recently with single precision in Urho3D - not in Bullet per se, but in the Node class, which underpins character bone animation. I’m trying to measure delta-transforms on the character hips and apply the delta-translations to the character’s true root node. Numerical precision is terrible when I use inverse transforms on a scaled model. The order of error is large. Note I zeroed the Y value in this computation, but here I compare my output numbers to my expectations. The scale of the error is often approaching 10.

WARNING: WorldHips WAS -0.0136105 0.944575 -0.00740542–>-0.0133018 0.941086 -0.00822335 Inverse-Computed Delta -0.000887255 0 -0.000894101

Hi Lieth,

Generally I have found ( and I’m sure you know) that avoiding node scale as much as possible always helps. Usually in your hierarchy for the ragdoll if you enforce that all nodes should have (1,1,1) scale and then have child nodes that do have scale for visual stuff. then you can do the math on the root nodes without worrying about the scaling side effects.


In my case, fixing scale in the model asset turns out to be non-trivial (I waited too late…),
because although I can certainly scale my geometry and my armature in the asset, it’s already been baked into the bone translations of a whole bunch of animations, so it’s easier to just scale the entire model hierarchy such that both the mesh(es) and the armature (skeleton) receives said scaling.

In this instance, I managed to avoid the issue of compound errors due to scaling by moving my spatial calculations entirely to worldspace - since scale only appears on one early node in my character hierarchy, using worldspace means that scale only enters the transform math once, so we don’t end up accumulating errors due to imprecision in scale factors and their inverses.