This is the third and final deep dive, and the last piece of something I set out to show a few weeks ago: that Senua AI's Measure can take any physics library it did not write, hold it to the answers physics gives, find where it departs, trace each departure to its cause and correct it, with proof. One library would not show that. A result on one engine can always be put down to the engine. So I chose three separate, independent physics libraries, from three different organisations, built by different teams with different solvers: Meta's SuperDex Physics, Google DeepMind's MuJoCo, and now Newton.
Newton is the open physics engine that Disney Research, Google DeepMind and NVIDIA started together. In September 2025 they handed it to the Linux Foundation, so that its direction belongs to the community that uses it rather than to any one company (Linux Foundation, 2025). It is written in Python on NVIDIA's Warp and released under Apache-2.0 on GitHub. It runs Google DeepMind's MuJoCo Warp as one of its solvers, so where that solver was concerned I checked it against MuJoCo's own C engine; its other solvers are Newton's own.
What makes Newton unusual, and why I left it for last, is that it puts several quite different solvers behind one interface (Newton's documentation). SemiImplicit and Featherstone integrate forces through time, Featherstone in the joint coordinates of his articulated-body method (Featherstone 2008). XPBD works on positions and constraints (Macklin, Müller and Chentanez 2016; Müller et al. 2020). VBD solves one body at a time (Chen et al. 2024), with an augmented Lagrangian form for stiff joints (Giles, Diaz and Yuksel 2025). And the MuJoCo solver runs Google DeepMind's own contact physics (Todorov, Erez and Tassa 2012; Todorov 2014).
That made Newton the hardest of the three to test, and for me the most revealing. It is the only one of the three where I could play the same scene on six solvers side by side. When two solvers disagree about where a sliding cube stops, at least one of them is wrong, and physics can say which.
I put Newton through Senua AI's Measure, holding it to the laws of physics and to the problems its own users report. It found 29 issues, counted once each, and resolved 23 of them, every fix proven in a study whose rules I published before its data existed. Here is what changed:
- Friction follows Coulomb's law again. On SemiImplicit and Featherstone a sliding cube stopped at 44% of the distance Coulomb's law gives (Coulomb 1785), and an impact took 75% too much friction. The cause was a single line: the friction's direction is divided by a Huber norm (Huber 1964) that is not scaled by its own width, so below 1 m/s friction comes out at Coulomb's times 2 / v. With Senua AI's patch the slide lands within 0.2% of Coulomb's distance and the impact is exact (Study 1).
- A load that friction can hold now stays put, on every solver. Push a cube with less force than its friction can resist and it should not move at all. As released it crept on every solver, up to 785 mm a second on SemiImplicit and Featherstone. With Senua AI's patches, and Newton's own options where they already do the job, it holds still on all of them (Study 18, Study 15, Study 11, Study 17, Study 19).
- A restitution of 0 means no bounce. XPBD bounced a cube 4% to 12% of its drop height with restitution set to 0, and its own restitution option removed the bounce only by cutting friction at the impact to as little as 9% of Coulomb's. SemiImplicit and Featherstone bounced too, more as the step got smaller, because their contact damped only while it closed. Senua AI's patches give no bounce on all three, with Coulomb's friction kept through the impact (Study 2, Study 3).
- Bodies fall under VBD. Released 10 m above the ground, a body under VBD did not fall at all. VBD read each body's velocity back from its 32-bit positions, and at that height one small step's change in position is lost in the rounding (IEEE 754-2019). Senua AI's patch carries the velocity instead, and VBD falls exactly as every other solver does (Study 4).
- Joints do what they are told. A joint turning past half a turn inside its limits was thrown on XPBD, its arms reaching 32.7 million rad/s. XPBD answered a torque 1.75 times too strongly and its drive grew stiffer with every iteration; Featherstone's joint limit diverged on light links; the MuJoCo solver's limit kept only 5% of the stiffness and damping it was given. Each is now fixed and validated, by Senua AI's patches or by fixes Newton's own contributors have proposed (Study 6, Study 10, Study 12, Study 13, Study 20).
- Chains keep their energy where physics says they must. A free two-link chain with nothing acting on it keeps its energy and angular momentum (Landau and Lifshitz). Featherstone and the MuJoCo solver added 9.7% in two seconds at a 10 ms step, XPBD and VBD took away 30% and 46%, and SemiImplicit blew up. Now Featherstone steps as the classic Runge-Kutta scheme (Hairer, Nørsett and Wanner 1993) and keeps it within 7 parts per million, the MuJoCo solver's own RK4 within 5, VBD's compliant path plays a chain 60 m from the origin as it does at the origin, within 2.2%, and XPBD's free chain loses less with every halving of the step (Study 9, Study 16, Study 36, Study 38).
- A spinning body's centre stays where it is. With nothing acting on it, a body's centre of mass cannot move off its line. The MuJoCo solver moved a spinning cube's centre 13 mm in two seconds and VBD let it drift; now both keep it in place (Study 9, Study 23).
- One scene gets one friction, whichever solver plays it. Newton's solvers combined two surfaces' frictions three different ways, so the same slide went 92.5 mm on one and 56.9 mm on another, and a static friction coefficient read from a USD file never reached the simulation. With Senua AI's patches every solver uses MuJoCo's rule and honours geom priority, and XPBD, SemiImplicit and Featherstone hold on the static coefficient until the push breaks the cube free (Study 26, Study 29, Study 30).
- Fast bodies stop at thin walls. A cube moving fast enough to cross a 4 mm slab in one step went straight through it. Now XPBD stops it with Newton's own settings, and Senua AI's patch stops it on SemiImplicit and Featherstone, at 90 and 110 m/s, without disturbing a slide. The MuJoCo solver, whose contact is MuJoCo's own, still lets it through (Study 35).
- A solver says when it ignores something. Some joint features, a velocity limit for one, were quietly ignored by some solvers. Now every solver names, when it is built, each feature it does not apply (Study 21).
- A cloth presses on a box with its own force. A light cloth resting on a box handed the box 19 to 139 times the force the cloth actually exerts. With Senua AI's coupling patch the box receives the cloth's own force, as Newton's third law requires (Study 24).
- MuJoCo's recommended settings now reach Newton. MuJoCo's noslip solver, which holds friction exactly, could not be set through Newton, and MuJoCo Warp refuses it outright. Senua AI's patches pass it to the CPU path and port it into MuJoCo Warp, where it holds a load still exactly as MuJoCo's C engine does (Study 11, Study 25).
- All of it stands on Newton 1.7.0. When Newton 1.7.0 came out on 14 October 2026, Senua AI played the whole record again on it. Every SemiImplicit, Featherstone and XPBD play came out the same, byte for byte (Study 7).
| Issues, counted once each | Resolved, each in a pre-registered study | Resolved in part | No departure found where measured |
|---|---|---|---|
| 29 | 23 | 3 | 3 |
Of the 23, fifteen were fixed with Senua AI's patches, two with options Newton already has, and three with fixes Newton's own contributors have proposed. Two more, a load that would not stay put and a spinning body whose centre wandered, were fixed on every solver with Senua AI's patches and Newton's options together, and one was fixed on Featherstone with no departure left to fix on SemiImplicit. Senua AI wrote 24 patches in all, each validated on Newton 1.7.0. I have put every registration, play, reading and rule on GitHub, so you do not have to take my word for any of it: github.com/senuamedia/senua-newton-accuracy.
What Senua AI found and fixed in Newton
| Newton as released (1.6.1; 1.7.0 where named) | What the Senua AI Robotics Core measured | With Senua AI |
|---|---|---|
| SemiImplicit and Featherstone give friction far above Coulomb's limit | A cube set sliding stops at 44% of the distance Coulomb's law gives; an impact takes 75% too much friction; with a narrower smoothing, a plate stops at 3.5% of its distance. The friction's direction is divided by an unscaled Huber norm (Huber 1964), so below 1 m/s friction is Coulomb's times 2 / v | Corrected. Senua AI's patch gives Coulomb's friction on both solvers (Coulomb 1785): the slide within 0.2% and the impact exact, whatever the smoothing. Validated: 11 of 11 pre-registered rules (Study 1) |
| XPBD bounces with a restitution of 0, and its restitution option loses friction | A cube rebounds 4% to 12% of its drop height. XPBD's own restitution option removes the bounce but cuts friction at an impact to 9% to 57% of Coulomb's, because its velocity pass applies normal impulses only | Corrected. Senua AI's patch to that pass: no bounce, as a coefficient of restitution of 0 means (Stronge 2018), and Coulomb's friction at and after the impact to 1 part in 3,500. Validated: 9 of 9 rules (Study 2) |
| SemiImplicit and Featherstone rebound with a restitution of 0 | A dropped cube rebounds, more as the step shrinks, 2.7% of the height at 0.156 ms: the contact damps only while it closes, so the spring hands back what the damper did not take | Corrected within its range. Senua AI's patch damps the contact in both phases and keeps it from pulling, the spring and dashpot of the contact literature (Hunt and Crossley 1975; Schwager and Pöschel 2007): no rebound at any step Newton's explicit integration can carry. Validated: 9 of 9 rules (Study 3) |
| VBD's bodies stop falling | Released 10 m up, a body does not fall at all; 1 m up, not at a 0.031 ms step. Free fall gets worse as the step is refined, as 32-bit positions predict (IEEE 754-2019; Goldberg 1991) | Corrected. VBD read each body's velocity back from its 32-bit positions; Senua AI's patch carries it, and VBD falls as Newton's other solvers do. Validated: 5 of 5 rules (Study 4) |
| The MuJoCo solver cannot play a slippery contact | At friction 0.001 or less its state stops being a number at a cube's first contact, with no warning. Traced to the default pyramidal cone in 32-bit arithmetic, whose regularization MuJoCo Warp scales with friction squared (run 012, run 023) | Fixed by Newton's own configuration. With MuJoCo's elliptic cone (Todorov 2014; Anitescu 2006) every play at friction 0, 0.0001 and 0.001 stays a number and the ground carries the weight to 0.2% (Study 9) |
| A joint chain does not keep its energy | With nothing acting on a two-link chain, Featherstone and the MuJoCo solver add 9.7% of its energy in 2 s at 10 ms, exactly as MuJoCo's C engine does; XPBD and VBD take out 30% and 46%; SemiImplicit blows up at every step played (run 014) | Fixed for a free chain on SemiImplicit, Featherstone, the MuJoCo solver and XPBD, and on VBD's compliant path. The MuJoCo solver's own RK4 within 5 ppm, and SemiImplicit with its joint damper off (Study 9); Featherstone stepped as the classic Runge-Kutta scheme (Hairer, Nørsett and Wanner 1993), within 7 ppm free and 20 ppm swinging (Study 16); VBD's compliant path with each pose carried in two 32-bit numbers (Dekker 1971), 60 m out within 2.2% of the origin (Study 36); XPBD's joints solved colour by colour (Fratarcangeli, Tibaldo and Pellacini 2016), 489 ppm at 0.1 ms against 9,587 as released (Study 38). Still open: VBD's legacy path far from the origin (Study 39) and a chain swinging under gravity on XPBD |
| Nothing holds at rest | A load inside the friction limit creeps on every solver: XPBD in proportion to the step, mostly its solve left unconverged (run 027, run 044), SemiImplicit and Featherstone at the push over their friction stiffness, up to 785 mm/s | Fixed and validated on every solver. SemiImplicit and Featherstone apply friction after the step as the impulse that stops each contact's slip inside Coulomb's cone (Stewart and Trinkle 1996): still at every step, a slide within 0.45% (Study 18). XPBD's friction bounded on the step's totals, within 4 um/s (Study 15). The MuJoCo solver with the elliptic cone and noslip (Study 11). VBD, both paths, by Newton's own contact history (Study 17, Study 19) |
| A spinning body's centre of mass moves | A cube spinning about a centre 5 cm off its origin, nothing acting on it: the MuJoCo solver moves that centre 13 mm in 2 s at 10 ms; VBD's compliant path more as the step shrinks. Featherstone keeps it within 3 um/s, so the drift users reported for it does not occur in 1.6.1 (run 030) | Resolved. A free body's centre moves in a straight line at constant speed (Landau and Lifshitz): the MuJoCo solver's RK4 holds it within 19 um/s (Study 9); Senua AI's VBD displacement patch keeps it still at every step, where as released it drifts at 8.2 mm/s (Study 23) |
| A joint turning past pi is thrown | A chain joint turning past pi, inside limits it never reaches, is thrown on XPBD at up to 32.7 million rad/s, and on VBD: the limit reads the angle wrapped into (-pi, pi]. SemiImplicit, Featherstone and the MuJoCo solver are unaffected | Fixed and validated: on XPBD by Newton's own proposed fix, pull request #4318, on VBD by Newton 1.7.0; the arm moves as one with no limit, to 1 urad (Study 10). XPBD's limit throwing an arm back off it is fixed by Senua AI's joint-angle patch at 64 iterations (Study 20) |
| The MuJoCo solver's joint limit is not the one it is given | An arm released onto a limit goes 4 to 6 times further past it than the given spring and damper allow: Newton's conversion keeps only 5% of each | Corrected. Senua AI's patch converts without that factor: the arm turns back within 0.022 rad of the spring and damper it was given. Validated: 9 of 9 rules (Study 6) |
| 1.7.0: Featherstone's joint limit diverges on light links | Users report Featherstone failing on 6-axis arms the MuJoCo solver plays. A light arm resting on its limit diverges at every step from 1/240 s to 10 us: the limit is integrated explicitly, stable only under microseconds on light links (run 055) | Fixed and validated. Senua AI's patch integrates the limit implicitly (Hairer and Wanner 1996), its force kept only where it pushes: the arms rest on the limit at every step (Study 12) |
| 1.7.0: XPBD answers a torque 1.75 times too strongly, its drive grows with its iterations, and it stops slow bodies | At its default relaxations an arm under a torque turns 1.75 times as far as the closed form; a drive acts as 0.69 times its stiffness for each iteration, 11.1 times at 16; anything slower than 0.1 mm/s is stopped | Fixed and validated: the torque by pull request #4317 with Senua AI's speed-floor patch, within 0.8%; the drive by #4318's PD drive, its own spring within 0.17%; the speed floor removed by Senua AI's patch (Study 10; run 054, run 065) |
| 1.7.0: joint features silently ignored | A velocity limit is applied by no solver, an effort limit by the MuJoCo solver only; a loop-closing joint's limit and drive are ignored by the MuJoCo solver and Featherstone, and SemiImplicit cannot play the loop at all (run 056, run 063) | Fixed and validated. Every solver now names, when built, each joint feature it does not apply (Senua AI's patch, with pull request #3552), and SemiImplicit plays the loop with Newton's own setting (Study 21); SemiImplicit's drive past a full turn and its two-axis D6 are held by Senua AI's joint patch (Study 13) |
| 1.7.0: one scene, a different friction on each solver | Two shapes' frictions are averaged on Newton's own contact, their geometric mean taken on VBD and the larger on the MuJoCo solver: the same slide goes 92.5 mm on one and 56.9 mm on another, and Newton's solvers depart from MuJoCo's C engine on a slide and a hold | Fixed and validated. Senua AI's patch makes every solver combine frictions by MuJoCo's rule and honour its geom priority (MuJoCo documentation), each mixed slide byte for byte its slide at the rule's coefficient (Study 26); with the record's friction patches one scene plays right on XPBD, SemiImplicit and Featherstone, and as MuJoCo's C engine does wherever it is right (Study 29) |
| 1.7.0: one friction coefficient, so nothing sticks before it slides | A shape carries a single coefficient: a cube pushed between what a static and a dynamic coefficient would hold slides on every solver, and a USD material's static friction never reaches the simulation | Fixed and validated. With pull request #4306 the static coefficient is imported, and Senua AI's static friction patch makes XPBD, SemiImplicit and Featherstone hold the cube, then slide on the dynamic coefficient once it breaks away, as static and kinetic friction behave (Popov 2010) (Study 30) |
| 1.7.0: fast bodies pass through thin walls | A body goes through a slab wherever one step carries it past it, speculative contacts as turned on changing nothing (run 060) | Fixed and validated on Newton's own solvers. XPBD by Newton's own configuration; SemiImplicit and Featherstone by Senua AI's speculative normal patch, every contact kept from closing past the surface within the step, the idea behind continuous collision handling (Redon, Kheddar and Coquillart 2002). No cube through a 4 mm slab at 90 and 110 m/s, the slides within 1 in 540 of Coulomb's distance (Study 35). The MuJoCo solver goes through regardless |
| A light cloth pushes too hard on the body under it | VBD hands a box 19 to 139 times the force a light cloth resting on it exerts, as Newton's issue #4698 reports | Fixed and validated. Senua AI's coupling patch hands the box the cloth's own force, action and reaction equal (Landau and Lifshitz): the box at rest, a throw's momentum kept (Study 24) |
| MuJoCo's recommended configuration cannot be set | Newton does not pass noslip to MuJoCo's C engine on the CPU path, and MuJoCo Warp refuses noslip on the Warp path | Resolved on both paths. Senua AI's patch passes noslip on the CPU path (Study 11), and ports MuJoCo's noslip solver (MuJoCo documentation) into MuJoCo Warp, where a load held still creeps at 1.3 mm/s as released and stays put with the patch, every play MuJoCo's C engine's (Study 25) |
Each patch only adds code. It does nothing until its switch is set, and with the switch off Newton plays byte for byte as released (the patches).
The fixes already out there, measured
Newton's contributors are working on several of the same problems, and a good deal of their work is already in pull requests. I wanted their fixes to get a fair hearing, so wherever one could be played, Senua AI's Measure held it to exactly the same rules as our own patches, on Newton 1.7.0 (Study 8, every fix with what it does and leaves). Several turned out to be the right fix, and where they were, the record validates them and uses them rather than ours.
| The fix | The problem | What Senua AI's Measure found |
|---|---|---|
| #4470, VBD's joint winding kept past half a turn (in Newton 1.7.0) | A joint turning past pi is thrown, on VBD | Validated: the joint moves as one with no limit (Study 10) |
| #4316, XPBD hinge angles that cross pi | A joint turning past pi is thrown, on XPBD | Stops the throw; leaves the limit throwing the arm back at 2.37 rad/s, and changes a limit short of pi (Study 8); validated in #4318's form (Study 10) |
| #4317, XPBD joint relaxation made consistent | A torque answered 1.75 times too strongly | Validated with Senua AI's speed-floor patch: within 0.8% (Study 10) |
| #4318, opt-in PD joint drives for XPBD | A drive that stiffens with every iteration | Validated: the drive its own spring within 0.17% at every iteration count (Study 10); on a loop-closing joint it loses the drive and the limit the release applies (run 075) |
| #4010, rigid contact friction kept inside the Coulomb cone | Friction above Coulomb's limit | Senua AI's friction to the micrometre at its default width, but the slide then depends on the width chosen, 1.8% long at 0.05 m/s (Study 8). Senua AI's patch is validated for this one (Study 1) |
| #4306, a static friction coefficient on shape materials | Static friction dropped on import | Validated as the importer, with Senua AI's static friction patch applying it (Study 30) |
| #3552, warn for ignored MuJoCo loop-joint properties | Joint features silently ignored | Validated with Senua AI's warnings patch (Study 21) |
| #4721, sparse VBD fixes (draft) | VBD's chains, limits and forces | To be measured when it applies to a release (fixes in the wild) |
The difference. A proposed fix often moves an error, shrinks it, or trades it for another, and that is no criticism of the people writing them: without a way to measure against the right answer, it is very hard to tell. Senua AI's Measure holds the engine to the answer physics gives, traces the error to its cause, changes only the cause, and proves in a study registered in advance that nothing else moved. Where a contributor's fix already does that, the record says so and uses it.
The same ten tests as SuperDex and MuJoCo
To compare the three libraries fairly, I used one yardstick throughout. The first deep dive held Meta's SuperDex Physics to ten known-answer tests, the second held MuJoCo to the same ten, and Newton's solvers took them too (the findings):
| Engine or solver | As released | With Senua AI |
|---|---|---|
| Newton's SemiImplicit and Featherstone | 4 of 10 | 7 of 10 with the friction and normal contact patches (run 020) |
| Newton's XPBD | 6 of 10 | 8 of 10 with its restitution option and Senua AI's patch |
| Newton's MuJoCo solver | 9 of 10 with its elliptic cone | |
| Google DeepMind's MuJoCo | 9 of 10 | 10 of 10 (the MuJoCo record) |
| Meta's SuperDex Physics | 6 of 10 | Its 12 departures corrected (the SuperDex record) |
One detail shows why I insist on measuring rather than assuming. With only the friction corrected, SemiImplicit and Featherstone failed a test they had passed before. The excess friction had been hiding a rebound in their normal contact (run 017). Fixing that as well brought them to 7.
What Newton gets right
A deep dive that only lists faults is not a fair one, so the record is just as careful about what Newton does well (the findings):
- It is deterministic to the byte on the CPU. Each of the six solvers played gives the same bytes when a play is repeated.
- Bodies fall at gravity's rate on every solver but VBD, at every step played.
- The ground carries the weight exactly on every solver.
- XPBD and the MuJoCo solver give Coulomb's friction on a slide and over an impact.
- The MuJoCo solver plays as MuJoCo's C engine does, and joint chains under Featherstone and the MuJoCo solver match MuJoCo's C engine to the part per million.
Proven, not claimed
I do not ask anyone to take these results on trust. This is how they were made, and how anyone can check them:
- 39 pre-registered studies and 142 runs. Every rule was written down and published before its data existed. 25 of the 39 studies held every rule they registered, and where a rule failed the study says so plainly: Study 39, the last, held 10 of 15, and Study 8 held 0 of 2, exactly as it predicted (the studies, the runs).
- The whole record played again on Newton 1.7.0, with 1.6.1 as the control. On 1.6.1 every play file of every solver came out as the record has it, 1,334 of 1,334 (Study 7).
- Checked end to end. Every run from 001 to 063 was played again and compared byte for byte, and every later run's readings and rules were made again from its kept files. The 5,672 numbers on the record's pages through run 138 were traced to the files they come from, with the last four runs being added, and all 1,294 links inside the record and 48 outside it resolve (the audit).
- Five checks on every patch. It is required, it is correct, nothing else gets worse, Newton is byte for byte as released when it is off, and the solver keeps converging (how it works).
- Held to textbook physics, with its sources. Coulomb's law of friction (Coulomb 1785; Popov 2010); free fall, the conservation of momentum, energy and angular momentum, and action and reaction (Landau and Lifshitz); the coefficient of restitution and the damped contact (Stronge 2018; Hunt and Crossley 1975); joint-space dynamics (Featherstone 2008); the integrators' known error and stability (Hairer, Nørsett and Wanner; Hairer and Wanner; Hairer, Lubich and Wanner); and 32-bit arithmetic (IEEE 754-2019). Every source is listed below.
All 29 issues, counted once, and what remains open
Before the first registered study, I gathered the problems Newton's users report and added the departures Senua AI's Measure found; where a report and a finding were the same departure, the record counts them once: 29 issues (the issues, what users report). I closed the deep dive on 21 October 2026 with Study 39. Three issues are resolved only in part, and three showed no departure where they were measured. I would rather say plainly what is still open than let a headline number speak for it, so here is exactly where each one stands:
- I ran no GPU compute. Newton is built for GPUs, but every play in this deep dive ran on Warp's CPU device. The parts of an issue that need a GPU were not played and remain open: issue 20's hydroelastic force calibration (Elandt et al. 2019), grasps and point clouds, whose volumes Warp builds on CUDA only; issue 23's determinism on the GPU; and issue 22's replay against PhysX.
- Issue 12, in part. VBD's legacy path far from the origin: with the pose carry its loss now falls as the step shrinks, 159 ppm at 0.025 ms against 7,837 without it, but it did not come within the registered tenth of the origin's at four of five steps (Study 39). A chain swinging under gravity on XPBD still loses energy (Study 38).
- Issue 20, in part. A body still goes through a thin slab on the MuJoCo solver whatever Newton's options, the contact being MuJoCo's own (Study 35).
- Issue 21, in part. Particles leaking through thin colliders in the implicit material point method solver (Sulsky, Chen and Schreyer 1994), Newton's issue #4712: narrowed and traced, no fix validated (Study 31, Study 32).
- No departure found where measured: determinism on the CPU (issue 23), and the MuJoCo solver's CPU path and VBD's joint limits on 1.7.0 (issues 24 and 29).
Three independent libraries, one Measure
When I began these deep dives, the question I wanted answered was simple to ask and hard to prove: does Senua AI's Measure work on any physics library, or only on the one it was first pointed at? A single deep dive could never settle it. If Senua AI's Measure had found and fixed problems in SuperDex alone, anyone could fairly say the method had been shaped around SuperDex. A second engine makes that harder to say. A third, from a different organisation again, with its own solvers and its own way of doing things, makes it very hard indeed.
So I chose three libraries from three separate organisations, none of them connected to Senua AI. Meta's SuperDex Physics, Google DeepMind's MuJoCo and Newton were written by separate teams, for different purposes, with different solvers underneath. Newton does offer MuJoCo Warp as one of its solvers, which is why I checked that one against MuJoCo itself; the rest of Newton is its own. Senua AI did not write a line of any of them. Each one was held to the same thing, the answers physics gives, by the same instrument, run the same way:
- The same kind of rig, every time. A thin adapter on each engine's own public interface plays the smallest scenes physics has an answer for. Senua AI's Measure never needs the engine's internals to judge it.
- The same known answers. Coulomb's friction, free fall, the conservation of energy and momentum, the coefficient of restitution: textbook physics, the same for every engine.
- The same rules about rules. Every study's rules are written down and published before its data exists, and a rule that fails is reported as failed.
- The same standard for a fix. Every patch is held to the same five checks, does nothing until it is switched on, and leaves the engine byte for byte as released when it is off.
- The same openness. Every study, run, raw file and patch for all three engines is public on GitHub.
Here is how the three came out:
| Engine | Made by | What Senua AI found | What Senua AI fixed | Pre-registered studies |
|---|---|---|---|---|
| SuperDex Physics | Meta | 12 departures | All 12 corrected, with 7 patches and 5 of SuperDex's own settings | 23 |
| MuJoCo | Google DeepMind | 21 issues, 20 counted once | 16 fixed and validated | 24 |
| Newton | The Linux Foundation, from Disney Research, Google DeepMind and NVIDIA | 29 issues | 23 resolved, 3 in part | 39 |
Three independent libraries, from some of the largest names in AI and robotics, and the same instrument found, traced and corrected departures in every one: 86 pre-registered studies in all. Nothing in Senua AI's Measure was particular to any of them. That was the point of doing three, and I believe the point is now made.
So this is the last deep dive. There will not be a fourth. I want to thank the teams behind SuperDex, MuJoCo and Newton for building their engines in the open, which is the only reason work like this can be done and checked at all. Everything the three engines taught us now goes into the Senua AI Robotics Core itself.
The Senua AI Robotics Core
The Senua AI Robotics Core is the software a robot is developed and run on. It has four parts:
- Senua AI's World, the simulator.
- Senua AI's Body, the real-time layer on the robot.
- Senua AI's Mind, the causal engine that perceives and decides.
- Senua AI's Measure, the instrument that holds a simulator to the truth.
All three deep dives are the work of Senua AI's Measure: Meta's SuperDex Physics, Google DeepMind's MuJoCo, and now Newton. Senua AI's Measure does not need to look inside an engine to judge it. A rig, a thin adapter on the engine's own interface, plays the smallest scenes physics has an answer for, and Senua AI's Measure holds what it records to that answer. Only then is a departure followed into the source, to find the line that causes it (how it works).
What we do not use
We do not use models. No LLMs. No SLMs. Of any kind.
The Senua AI engine learns the structure of a signal directly from the signal itself. No GPU, no data centre and no AI token costs, ever. It runs on low-end CPUs. Newton is built for GPUs, yet every play in this deep dive ran on Newton's CPU device on cloud CPU machines, and every measurement ran there and again on an Intel laptop.
What would it find in your engine?
SuperDex, MuJoCo and Newton are done, and the method does not change from one engine to the next. The same measurement, validation and patching apply to Isaac Sim, Bullet, Drake, an in-house engine, or a robotics framework built on any of them. If you maintain a simulator or build robots and want to know how far your simulation is from the right answer, I would be glad to run Senua AI's Measure on your engine. Contact us through senuaai.com.
References
The physics the record is held to, the methods Newton's solvers and Senua AI's patches rest on, and the published work cited above, each checked against its registry:
- Coulomb, C.-A. (1785). Theorie des machines simples, en ayant egard au frottement de leurs parties et a la roideur des cordages. Memoires de mathematique et de physique, vol. 10; new edition, Bachelier, 1821. doi:10.14711/spcol/b668151
- Popov, V. L. (2010). Contact Mechanics and Friction. Springer. doi:10.1007/978-3-642-10803-7
- Landau, L. D., and Lifshitz, E. M. (1976). Mechanics, 3rd edition. Pergamon. doi:10.1016/C2009-0-25569-3
- Stronge, W. J. (2018). Impact Mechanics, 2nd edition. Cambridge University Press. doi:10.1017/9781139050227
- Hunt, K. H., and Crossley, F. R. E. (1975). Coefficient of restitution interpreted as damping in vibroimpact. Journal of Applied Mechanics 42(2), 440-445. doi:10.1115/1.3423596
- Schwager, T., and Pöschel, T. (2007). Coefficient of restitution and linear-dashpot model revisited. Granular Matter 9(6), 465-469. doi:10.1007/s10035-007-0065-z
- Stewart, D. E., and Trinkle, J. C. (1996). An implicit time-stepping scheme for rigid body dynamics with inelastic collisions and Coulomb friction. International Journal for Numerical Methods in Engineering 39(15), 2673-2691. doi:10.1002/(SICI)1097-0207(19960815)39:15<2673::AID-NME972>3.0.CO;2-I
- Anitescu, M. (2006). Optimization-based simulation of nonsmooth rigid multibody dynamics. Mathematical Programming 105(1), 113-143. doi:10.1007/s10107-005-0590-7
- Featherstone, R. (2008). Rigid Body Dynamics Algorithms. Springer. doi:10.1007/978-1-4899-7560-7
- Hairer, E., Nørsett, S. P., and Wanner, G. (1993). Solving Ordinary Differential Equations I: Nonstiff Problems, 2nd edition. Springer. doi:10.1007/978-3-540-78862-1
- Hairer, E., and Wanner, G. (1996). Solving Ordinary Differential Equations II: Stiff and Differential-Algebraic Problems, 2nd edition. Springer. doi:10.1007/978-3-642-05221-7
- Hairer, E., Lubich, C., and Wanner, G. (2006). Geometric Numerical Integration, 2nd edition. Springer. doi:10.1007/3-540-30666-8
- Huber, P. J. (1964). Robust estimation of a location parameter. The Annals of Mathematical Statistics 35(1), 73-101. doi:10.1214/aoms/1177703732
- IEEE (2019). IEEE Standard for Floating-Point Arithmetic, IEEE Std 754-2019. doi:10.1109/IEEESTD.2019.8766229
- Goldberg, D. (1991). What every computer scientist should know about floating-point arithmetic. ACM Computing Surveys 23(1), 5-48. doi:10.1145/103162.103163
- Dekker, T. J. (1971). A floating-point technique for extending the available precision. Numerische Mathematik 18(3), 224-242. doi:10.1007/BF01397083
- Macklin, M., Müller, M., and Chentanez, N. (2016). XPBD: position-based simulation of compliant constrained dynamics. Proceedings of the 9th International Conference on Motion in Games, 49-54. doi:10.1145/2994258.2994272
- Müller, M., Macklin, M., Chentanez, N., Jeschke, S., and Kim, T.-Y. (2020). Detailed rigid body simulation with extended position based dynamics. Computer Graphics Forum 39(8), 101-112. doi:10.1111/cgf.14105
- Fratarcangeli, M., Tibaldo, V., and Pellacini, F. (2016). Vivace: a practical Gauss-Seidel method for stable soft body dynamics. ACM Transactions on Graphics 35(6). doi:10.1145/2980179.2982437
- Chen, A. H., Liu, Z., Yang, Y., and Yuksel, C. (2024). Vertex block descent. ACM Transactions on Graphics 43(4). doi:10.1145/3658179
- Giles, C., Diaz, E., and Yuksel, C. (2025). Augmented vertex block descent. ACM Transactions on Graphics 44(4). doi:10.1145/3731195
- Todorov, E., Erez, T., and Tassa, Y. (2012). MuJoCo: A physics engine for model-based control. IEEE/RSJ IROS, 5026-5033. doi:10.1109/IROS.2012.6386109
- Todorov, E. (2014). Convex and analytically-invertible dynamics with contacts and constraints: Theory and implementation in MuJoCo. IEEE ICRA, 6054-6061. doi:10.1109/ICRA.2014.6907751
- Redon, S., Kheddar, A., and Coquillart, S. (2002). Fast continuous collision detection between rigid bodies. Computer Graphics Forum 21(3), 279-287. doi:10.1111/1467-8659.t01-1-00587
- Sulsky, D., Chen, Z., and Schreyer, H. L. (1994). A particle method for history-dependent materials. Computer Methods in Applied Mechanics and Engineering 118(1-2), 179-196. doi:10.1016/0045-7825(94)90112-0
- Elandt, R., Drumwright, E., Sherman, M., and Ruina, A. (2019). A pressure field model for fast, robust approximation of net contact force and moment between nominally rigid objects. IEEE/RSJ IROS, 8238-8245. doi:10.1109/IROS40897.2019.8968548
- MuJoCo documentation: Computation (the cones and noslip) and Modeling (how two geoms' contact parameters combine). Google DeepMind.
- Newton documentation: Solvers. The Newton Developers.
- Linux Foundation (2025). Linux Foundation announces contribution of Newton by Disney Research, Google DeepMind and NVIDIA to accelerate open robot learning. linuxfoundation.org
The record
- github.com/senuamedia/senua-newton-accuracy. Every finding, patch, study and run, a page for each study, the issues counted once, the fixes in the wild and the audit.
- Newton. The Newton Developers. Newton 1.6.1 (Apache-2.0), at the commit given in the record, and 1.7.0 from PyPI.
- What Senua AI found and fixed in Google DeepMind's MuJoCo, 18 October 2026. The second deep dive. Its record: github.com/senuamedia/senua-mujoco-accuracy.
- The Senua AI Robotics Core, complete deep dive: Meta's SuperDex Physics, 15 October 2026. The first deep dive. Its record: github.com/senuamedia/senua-superdex-accuracy.