Do robot policies transfer between physics engines?

We compare learning and transfer across four physics engines in peg insertion, quadruped locomotion and object grasping, and fine-tune the generalist π0.5 policy in RoboLab. Our experiments show that the engine shapes learned policies, success rates in one engine may look very different in another, and a single simulator setting can change outcomes.

MuJoCo · Newton / MuJoCo-Warp · PhysX · Genesis
28 October 2026 · Data & methods

We study reinforcement learning for training robotics policies in different simulation engines.
Transfer between engines can be a challenge: A trained insertion policy scores 49/50 in MuJoCo, but only succeeds in 11/50 cases when run in PhysX (1).
Solver settings during evaluation influence performance in unpredictable ways: the fragile policy succeeded on 5 of 25 held-out starts under PhysX’s TGS solver with 100/1 iterations, 21 with PGS and 19 with TGS 4/0. More solver iterations did not make transfer safer (2).
Identically authored assets and scenes might not result in identical friction: the same authored quadruped foot friction is resolved to 0.8 (sticking) and 0.6 (sliding) in PhysX but 1.0 in Newton. Of 320 PhysX-trained ANYmals walking in Newton, we observe between 2 and 11 falls depending on chosen value resolution and solvers (3).
The training engine determines learned gait: every PhysX-trained ANYmal uses more joint torque than every Newton-trained one, in every engine, after matching friction or cone, and with Newton's hard-contact solver too (3).
A recipe validated for transfer still loses 20–29 points: In Isaac Lab’s grasp-and-lift task, Newton to PhysX drops from 88% to 68% and PhysX to Newton from 82% to 53%. The same policy scores 55–88% within one engine depending on evaluation conditions (4).
Behavior of generalist policies diverges in some scenes: π0.5 succeeds in 80–100% of episodes in both engines, yet 41 matched episodes have more failed grasps in Newton against 13 in PhysX. A scene saved at rest in PhysX may not be at rest in Newton: 17 against 4 successes in 40 episodes (5).
We discuss a series of checks for engine transfer: our list of practical lessons highlights which values to read back, and which test to perform before trusting a transfer number (6).

Train ANYmal in PhysX and it walks with about 35% more torque, in either engine

We trained matched ANYmal-D robots to walk with PPO

The robot is commanded to walk forward at 1 m/s. Every PhysX-trained seed uses more joint torque than every Newton-trained seed, about 35% more on average, even after transfer. This might even lead to a fall (PhysX-trained policies fell in 11 of 320 Newton runs and 1 PhysX run). The graph shows the largest joint torque at each policy step, coloured by training engine; dashed lines run in the other engine. Click or drag on it to seek. Replay provenance · torque data.

In part one, we compared how four physics engines respond to the same scripted controllers. The differences were particularly noticeable during contact. But what happens when we train a policy in one engine and run it in another?

Many engine comparisons measure speed, accuracy and stability [1, 2]. Compared to this, comparisons of learned behavior within different engines, as well as cross-engine and settings transfer are less well studied (with some exceptions [3]). However, especially for in-simulation training and evaluation, understanding how engines and settings shape behavior and success rates is crucial. This extends to transfer into real-world tasks. We study policy training and transfer within contact-rich manipulation, and massively parallel training in current engines. Section 6 discusses the wider literature.

Four cases and an appendix pilot
Case	Trained in → evaluated in	What we varied
Peg insertion · Panda, PPO	MuJoCo → MuJoCo, Newton, PhysX, Genesis	Training seed, reward, contact and solver settings
Walking · ANYmal-D, Isaac Lab	PhysX, Newton → both	Friction, contact stiffness, physics step
Grasp-and-lift · Franka, Isaac Lab	PhysX, Newton → both	Evaluation conditions
π0.5 · RoboLab	Pretrained, fine-tuned in PhysX → PhysX, Newton	Fine-tuning
Soft-ball insertion · appendix	MuJoCo, Newton (MuJoCo-Warp + VBD) → both	Pilot only

We train policies with reinforcement learning on a series of different tasks. We use PPO as our default RL algorithm, proprioception-based states, and Gaussian policies. We use the exact same assets and scenes across engines, and put an emphasis on where these engines diverge.

This article is the second in our series on simulation engines for robotics. In the previous post, we looked at differences between simulation engines in terms of contact resolution and different interactions such as deformables. In a final post, we will look at sim-to-real transfer of engines.

Background: An overview of simulation frameworks for robotics
Where physics engines agree and differ
Cross-engine policy transfer
(Coming soon) Sim-to-real transfer

1. Peg insertion

Trained to 100% success rate in MuJoCo, a policy might fail in 39/50 cases in PhysX

We train policies with RL to solve a peg-insertion task in MuJoCo. Evaluated in the same engine, the policy achieves 49-50 successes out of 50 trials across five training seeds. Within the same scene in PhysX, performance varies more between seeds: While one policy solves 49/50 tasks, a different training seed achieves only 11 successes. Looking at the source scores, we could not have distinguished between policies.

We use a precision insertion task: A Panda arm carries an attached rod into a bore with 0.10/0.25 mm radial clearance. The policies are trained across five seeds in MuJoCo and evaluated without adaptation on the same 50 new starts in four engines. An insertion counts as successful only if it meets the pose and hold criteria without triggering the contact-load stop.

Insertion setup and evaluation protocol

A Panda arm carries a rod already attached to its hand. It must align the rod with a bore, insert it, and hold the final position. Radial clearances of 0.10 and 0.25 mm make contact consequential. Varying initial offsets and tilts require correction. Removing the pickup phase isolates insertion from grasping.

Every engine receives the same scene definition and policy interface. Observations, action interpretation, reward and termination code are shared. Native adapters advance the physics. We retain the solver settings from part one's audit and a 1 ms physics step. Newton here uses its MuJoCo-Warp solver, so it is not an independent contact-model family from MuJoCo.

Policy. PPO with separate 64×64 tanh networks for actor and critic. The actor uses independent Gaussian actions during training and deterministic mean actions at evaluation. Its state observations include the robot, peg, goal and controller target, but no measured contact force. The baseline reward encourages alignment and insertion progress, with small action-change and effort costs.
Control. At 50 Hz, six actions adjust the desired hand pose by at most 0.25 mm or 0.002 rad per component. A shared task-space impedance controller runs at 1 kHz, with bounded target lead and 20 N / 2 Nm command caps.
Success. Depth of at least 19 mm, lateral error below 2 mm and tilt below 5°, held for the final 0.26 s of a five-second episode. Raw simulated peg-contact loads above 40 N or 4 Nm, invalid states and numerical failures end the episode unsuccessfully.

The load threshold is a stop rule, not a clamp: a single physics step can produce a larger peak before termination. These are simulated contact-wrench measurements. Passing the depth criterion does not certify a penetration-free physical fit, and agreement between simulators does not establish accuracy against the real robot.

Because earlier cross-engine results depended strongly on the training seed [3], we compare several seeds rather than one policy. For the main study, we train five MuJoCo CPU seeds with each reward for 262,144 transitions per run. Eight fixed layouts provide training starts, while 24 separate layouts select checkpoints. All ten selected checkpoints are at the final budget. Observation normalization is frozen at evaluation, with no adaptation to the target engine.

The reported test rates use 50 new starts, balanced across the two clearances, with offsets sampled within ±1.75 mm and tilts within ±1.5°. All policies see the same layouts. Eight previously used regression cases are reported separately in the supplement. The task and budgets were frozen after exploratory pilots. Test results did not select checkpoints.

Source success hides large differences between policies

The baseline policies solve almost every new start in MuJoCo, Newton and Genesis. In PhysX GPU, mean success falls to 74.4%, and the training seed matters much more.

Five MuJoCo-trained policies evaluated in four engines. Each solves 49 or 50 of 50 starts in MuJoCo, Newton and Genesis; in PhysX the counts are 49, 47, 32, 47 and 11. — Five MuJoCo-trained policies, tested on 50 new starts per engine. Newton uses MuJoCo-Warp.

Exact insertion results by engine and training seed

MuJoCo-trained baseline · successes on the same 50 new starts per policy
Evaluation engine	Seeds 0–4 (each out of 50)	Mean success
MuJoCo CPU	50, 50, 49, 50, 50	99.6%
Newton / MuJoCo-Warp	50, 50, 49, 50, 50	99.6%
PhysX GPU	49, 47, 32, 47, 11	74.4%
Genesis	50, 49, 49, 50, 50	99.2%

All 64 PhysX failures across the five policies are overload stops: the policies press too hard rather than stall short of the target depth.

One policy with four different contact responses. Seed 4 on one new start succeeds in three engines and stops at a 106 N peak in PhysX (selected failure example). Native recorded poses. Simplified display geometry and bore cutaway. Replay provenance · 3D replay data.

A start-aware scripted reference also struggles with PhysX, succeeding on 44/50 starts, versus 50/50 in the other three engines. Part one had already shown this contact sensitivity. For the learned policies, 55 of the 64 policy overloads occur on starts where the scripted controller succeeds, thus failing on many starts that the scripted controller completes.

This makes transfer a property of the particular policy as well as the engine pair. We cannot infer a reliable transfer rate from either a scripted controller or a single successful training seed. Nor does a high success rate guarantee matching trajectories or loads: it only says that the specified outcome and stop criteria were met.

Training ablation: adding a force penalty to the learning objectives improves transfer

We repeat the five MuJoCo trainings with a force cost added to the dense task reward. At each policy step, the penalty is 10 times the time-average of squared resultant force divided by (40 N)². A steady 10 N costs 0.625 reward, while 40 N costs 10. The weight is fixed before the new runs, without target-engine tuning. The raw force and moment stops remain unchanged.

Mean success across five seeds · 50 new starts per seed · same training budget
Evaluation engine	Baseline	Force penalty
MuJoCo CPU	99.6%	99.6%
Newton / MuJoCo-Warp	99.6%	98.4%
PhysX GPU	74.4%	84.0%
Genesis	99.2%	98.8%

PhysX improves by 9.6 percentage points, but most of the gain comes from seed 4, which rises from 11/50 to 37/50. Seed 2 improves from 32/50 to 34/50. The other three seeds decline slightly. The penalty helps the weakest baseline substantially without making every policy more transferable.

That is useful evidence for including contact loads in the objective, but not a universal recipe. It also illustrates why reward comparisons need multiple seeds: a single paired result could suggest a large benefit, a small benefit or a small loss.

Every training seed on 50 new starts. Baselines nearly all succeed in MuJoCo, Newton and Genesis. PhysX ranges from 22 to 98 percent; the force penalty chiefly improves seed 4 from 22 to 74 percent. — Each point is one training seed. Short horizontal marks show means. The paired PhysX results expose variation that a mean alone conceals. The eight historical starts are excluded. All seed results.

Training pilot: can the same recipe learn directly in PhysX?

Perhaps a policy trained directly in PhysX could learn to avoid the loads that stop the transferred policies. We test this with a smaller comparison: 131,072 transitions, seed 0, baseline and force-penalty rewards, trained in PhysX CPU. Archived MuJoCo checkpoints at exactly the same budget provide the comparison. Policy architecture, controller, starts and reward definitions remain fixed. We evaluate the predetermined final checkpoints.

The difference appears before transfer. On 24 source-validation starts, the PhysX baseline completes 12/24 insertions, with three overloads and nine incomplete insertions. Its force-penalty variant completes 0/24, with two overloads. Both matched MuJoCo policies complete 24/24 in their own source engine.

Successes on eight historical starts · one seed · equal 131,072-transition budgets
Reward / evaluation engine	PhysX CPU-trained	MuJoCo-trained	Scripted
Baseline / PhysX CPU	2/8	4/8	8/8
Baseline / PhysX GPU	1/8	8/8	7/8
Baseline / MuJoCo CPU	4/8	8/8	8/8
Force penalty / PhysX CPU	0/8	2/8	8/8
Force penalty / PhysX GPU	0/8	5/8	7/8
Force penalty / MuJoCo CPU	0/8	8/8	8/8

The PhysX-trained baseline still overloads on three of eight starts in each PhysX execution path. Its force-penalty variant has no overloads on these tests, but completes no insertions in any target. Lower loads alone do not demonstrate a more robust insertion strategy. The execution path matters too. The same MuJoCo baseline scores 4/8 in PhysX CPU and 8/8 in PhysX GPU.

This is a learning limitation under the tested configuration and budget. It matters to developers: an otherwise unchanged training setup that works in one engine may require further work in another. The pilot is limited: One seed cannot establish that PhysX generally learns less well, or that it cannot solve this task.

2. Contact and solver settings

One PhysX solver setting moves the fragile policy from 20% to 84% success rate

Beyond the choice of engine, there are many parameters which also determine success and failure during evaluation. In the following section, we keep the policies fixed and change the physics settings, one at a time.

The comparison so far fixes each engine at one configuration: a 1 ms step, friction 0.2, and PhysX's TGS solver with 100 position iterations and a 10 µm contact offset. We vary one setting at a time, using ranges from engine defaults and common practice. We use seeds 0 (robust), 2 (intermediate) and 4 (fragile), plus the scripted reference. Holding the policies fixed while changing only the simulator is the design Kadian et al. used to show that collision and noise settings can change which navigation policies look good [5]. Solver convergence may also explain reported differences between MuJoCo and MJX [4].

Every requested value is read back from the compiled MuJoCo model or the live PhysX stage before the first episode, and the run stops if one does not match. Smaller physics steps keep the controller at 1 kHz. One torque command is held across the substeps, and contact forces are averaged over each millisecond, leading to the 40 N stop measuring the same quantity at every step size. Repeating the unchanged configuration reproduces every outcome in both engines, with identical PhysX peak forces.

Stiffer MuJoCo contact reproduces the PhysX failures

Of thirteen MuJoCo variations, only the contact time constant substantially changes outcomes. Step size (0.5 and 0.25 ms), friction (0.1 and 0.5), a softer or harder impedance curve, a pyramidal friction cone, a higher impratio and noslip iterations leave seed 4 at its nominal score. Seed 2 varies by at most one success. However, stiffening the contact makes seed 4 fail the way it does in PhysX through overload stops, while seed 0 and the scripted reference are unaffected.

As the MuJoCo contact time constant falls from 20 to 2 milliseconds, seed 4 falls from 50 to 14 successes out of 50 and its median peak force rises from 10 to 48 newtons. Seed 0 stays at 50 successes. — **Stiffer contact exposes the fragile policy.** The same checkpoints run on the same 50 starts. The upper panel counts successes, and the lower panel shows seed 4’s median episode peak force. The dashed line is its nominal PhysX peak. *The 0.5 ms setting also uses a smaller physics step, 0.25 ms instead of 1 ms.

Exact contact-stiffness results and PhysX reference

MuJoCo CPU · successes on the same 50 new starts · seed 4 median peak contact force
Contact time constant	Seed 0	Seed 2	Seed 4	Seed 4 peak
20 ms	50	49	50	10 N
10 ms (scene default)	50	49	50	15 N
5 ms	50	49	39	32 N
2 ms	50	40	14	48 N
0.5 ms at a 0.25 ms step	49	41	15	42 N
PhysX GPU, nominal	49	32	11	82 N

The ordering matches PhysX: seed 0 stays robust, seed 2 degrades partly, seed 4 collapses. MuJoCo clamps the time constant to at least twice the physics step. 2 ms is the stiffest value reachable at 1 ms. 0.5 ms needs a 0.25 ms step and adds nothing beyond it.

A different PhysX solver improves the fragile policies

In PhysX, we screened fourteen settings, including the CPU execution path, on 25 of the new starts. Neither contact offset (0.1 or 1 mm), a positive rest offset, friction nor maximum depenetration velocity rescues seed 4. The last was a candidate cause of the 100 N peaks. At its unauthored default of 3 m/s it never activates, and lowering it to 1 or 0.1 m/s changes trajectories but not outcomes. Two settings improved success: four position and zero velocity iterations, the value Isaac Lab uses for locomotion, and the PGS solver in place of TGS.

We confirmed both on the 25 new starts the screen had not used, with the analysis fixed in advance: seed 4 success against the nominal configuration, exact McNemar test, Holm-corrected across three settings.

PhysX GPU · confirmation on 25 held-out new starts · paired change against nominal
Solver setting	Seed 4	Gained / lost	Holm p	Seed 4 peak
TGS, 100 / 1 iterations (nominal)	5/25	–	–	82 N
PGS	21/25	+18 / −2	0.001	24 N
TGS, 4 / 0 iterations	19/25	+16 / −2	0.003	19 N
TGS, 25 / 1 iterations	5/25	+2 / −2	1	46 N

No controller does worse under either setting. With PGS, seed 2 rises from 20 to 25 and the scripted reference from 23 to 25, so every controller except seed 4 succeeds on all 25 starts. Twenty-five iterations halve seed 4's peak force without changing its outcomes, so the effect is not a smooth function of iteration count.

One frozen policy under four physics settings. The same start and checkpoint produce different outcomes. MuJoCo with 2 ms contact and PhysX at its defaults stop within 30 ms of each other (50 N and 91 N). MuJoCo at its default contact and PhysX with PGS complete the insertion (peaks 10 N and 24 N). This start shows the pattern of 18 of the 25 held-out starts and was chosen after inspecting outcomes. Replay provenance.

We did not measure effective contact stiffness or solver convergence directly.

These scores use our load-stop criterion. A more permissive contact response could also allow more penetration. Higher success does not establish a better match to the real insertion.

Two unresolved results from the settings screen

Two screen results remain unexplained. A smaller PhysX step (0.25 ms) hurts the robust controllers: the reference loses 7 of 25 starts, mostly through incomplete insertions, and seed 0 loses 8 through overloads. Friction 0.5 lowers seed 2 from 12 to 5 of 25 in PhysX, although MuJoCo shows no friction effect at all. Both are exploratory, single-screen results.

3. Quadruped locomotion

Walking policies transfer, but keep their training engine’s gait

ANYbotics’ ANYmal-D learns to follow velocity commands on flat ground in Isaac Lab 3.0 (early access), with the stock task, rewards and PPO settings: 4,096 parallel robots and 50 Hz control. Both backends run the same task code and the same actuator-network implementation. Results are exploratory. Five training seeds per engine and cell, without a separate confirmation run.

Before training, we read the values each engine actually simulates. At Isaac Lab's defaults, the two backends differ in more than the engine:

ANYmal-D flat, Isaac Lab defaults · values read from the running engines
	Isaac Sim PhysX	Newton / MuJoCo-Warp
Physics step	5 ms	5 ms, two 2.5 ms substeps
Solver	TGS, 4 / 0 iterations	Newton, 100 iterations, elliptic cone, impratio 100
Contact stiffness	rigid; depenetration ≤ 1 m/s	1.8 ms requested, clamped to 5 ms
Foot–ground friction	0.8 static, 0.6 dynamic	1.0

The friction difference arises from identical authored values. PhysX multiplies the foot's 0.8/0.6 by the ground's 1.0, while Newton keeps the larger of the two coefficients. Isaac Lab's default budget of 300 training iterations is also too short for a fair comparison. PhysX policies are still far from converged at that point. Both engines plateau by 600–1,000 iterations, so we train for 1,000.

Interface check: matching joints by name

Moving a policy between backends has a trap of its own. Newton orders the twelve joints leg by leg, PhysX by joint type, and both the action term and the joint observations use the native order. Our evaluator maps joints by name. In a 16-robot check, a Newton-trained policy that walks well in PhysX with the mapping fell in 62.5% of episodes without it, and nothing raised an error.

One policy, two joint orders. The same Newton-trained policy and starting state in PhysX. With joints matched by name it walks. In PhysX’s native order its leg commands (purple arrows) are permuted and it falls after 0.8 s. Replay provenance.

At defaults, both strategies usually transfer

Each policy is evaluated in both engines with deterministic actions, a nominal robot, fixed starting states and five constant commands. Standing, walking at 0.5 m/s, sidestepping and turning show essentially no transfer cost. At 1 m/s:

Forward 1.0 m/s · 5 training seeds × 64 robots × 10 s per cell · mean over seeds
Trained → evaluated	Falls	Tracking error	Torque RMS	Foot slip	p99 foot force
Newton → Newton	0/320	0.074 m/s	12.7 Nm	0.19 m/s	2,411 N
Newton → PhysX	2/320	0.105 m/s	13.3 Nm	0.20 m/s	2,044 N
PhysX → Newton	11/320	0.080 m/s	17.1 Nm	0.21 m/s	1,100 N
PhysX → PhysX	1/320	0.076 m/s	17.5 Nm	0.32 m/s	627 N

The opening replay shows one of the PhysX-to-Newton falls for seed 0. Nearly all falls under walking commands happen within the first 2.5 seconds, while the robot recovers from its randomized starting state: a random body velocity, with each joint at 0.5 to 1.5 times its default angle. Once walking, policies rarely fall in either engine.

The policies usually keep walking after transfer, but use different torques and foot contacts. PhysX-trained policies use about 35% more joint torque and keep their feet down longer. Newton-trained policies hit the ground two to four times harder. We checked whether this was just seed variation: every PhysX-trained seed uses more joint torque than every Newton-trained seed, under every command, in either evaluation engine, and again after friction matching (exact permutation test, p = 0.008, the smallest possible with five seeds per group). At 1 m/s, every Newton-trained seed also lands harder than every PhysX-trained one. The longer foot contact is consistent across seeds only when evaluated in PhysX. Feet slip more in PhysX, consistent with its lower dynamic friction. That comparison runs each policy in both engines, so seeds cancel out, and it holds for 9 or 10 of the 10 policies under every command.

Matching friction removes most of the transfer cost, not the gait difference

Retraining with an effective foot–ground friction of 0.8 in both engines removes most of the remaining gap. PhysX-trained policies fall 3 times in Newton instead of 11, Newton-trained policies track as well in PhysX as within the training engine (0.077 m/s), and the extra slip in PhysX shrinks to 0.25 against 0.23 m/s. Even after matching friction, the policies still use different amounts of torque and hit the ground with different forces. Falls this rare make the 11-versus-3 comparison suggestive rather than conclusive.

One of the five friction-matched PhysX trainings shows a different weakness. Seed 1 learned an unstable stance: told to stand still, it rocks and falls in its own engine (8 of 64 robots) and more often in Newton (22 of 64), several seconds in. No other seed in either cell falls while standing. A walking benchmark alone would not have caught it.

A policy that cannot stand still. Friction-matched seed 1, commanded to stand, from a starting state where it falls in both engines (6.6 s in PhysX, 7.6 s in Newton). The purple joint commands show it correcting harder as the rocking grows: the mean command roughly doubles, from about 0.1 to 0.2 rad, in the seconds before each fall. In a separate rerun, another starting state that fell in Newton during evaluation stayed up, so Newton outcomes are not exactly repeatable run to run. Selected after inspecting outcomes. Replay provenance.

Newton's friction cone alone does as much as matching friction

Isaac Lab's flat-ground ANYmal preset runs Newton's MuJoCo solver with an elliptic friction cone and impratio 100. Its rough-terrain preset and MuJoCo's own defaults use a pyramidal cone with impratio 1. Switching only the cone, at default friction, helps PhysX-trained policies as much as matching friction does. They fall 2 times in 1,600 Newton runs over all five commands instead of 15. The policies and starting states are the same, and only Newton's contact model changed. Every seed falls less often. On 256 fresh starting states per command, falls drop from 39 to 12 of 6,400 (Fisher's exact p = 0.0002). Keeping the elliptic cone and lowering only impratio to 1 does not help (12 of 1,600), so within MuJoCo's solver the cone shape is what matters. Newton training is unaffected (final reward 21.6 against 21.4), and the resulting policies fall twice in PhysX, as before. The gait difference stays. PhysX-trained policies still use 42% more torque, with every seed apart (p = 0.008). Newton-trained policies land softer in the pyramidal-cone Newton (99th-percentile foot force 1.9 against 2.4 kN), and there the seeds no longer separate on landing force. Cone ablation data.

Same policy, same start, different friction cone. The PhysX-trained robot from the opening replay, at 1 m/s from the same starting state in Newton. With the default elliptic cone it falls after 1.4 s. With the pyramidal cone it recovers and walks. Nothing else changed: not the policy, the friction coefficients or the step. Three of the four robots of this seed that fall with the default cone walk with the pyramidal one, in the evaluation and in this recording. Selected after inspecting outcomes. Replay provenance.

Switching the cone on top of friction matching adds nothing: falls stay within a few robots of the friction-matched cell, and PhysX-trained policies track slightly worse in Newton (0.13 m/s). That cell changed only Newton settings, so its PhysX trainings repeated the friction-matched ones, and they produced byte-identical checkpoints. Repeating training reproduced seed 1's unstable stance.

A hard-contact solver points away from soft contact as the cause of the gait difference

Newton also ships Kamino, a solver that treats contacts as hard constraints with an exact, round Coulomb cone instead of MuJoCo's soft constraints. PhysX-trained policies fall 5 times in 1,600 Kamino runs, and 16 of 6,400 from fresh starting states. That is close to the pyramidal cone (12, Fisher's exact p = 0.57) and well below MuJoCo's default (39, p = 0.003). A round cone by itself is therefore not the problem. MuJoCo's soft elliptic cone is. One difference remains: Kamino averages the two friction coefficients (0.9 here, against 1.0 in MuJoCo), which may also help. Training in Kamino works (final reward 22.4 over three seeds) but takes about ten times longer per iteration. Kamino-trained policies walk like MuJoCo-trained ones. They use 12 to 13 Nm of torque in every engine, against 17 for PhysX-trained policies, with every seed apart (p = 0.018, the smallest possible with three against five seeds). Their landing forces lie between the two and separate from neither. The torque difference therefore comes from something both Newton solvers share, or from PhysX, not from MuJoCo's soft contact. In PhysX, one Kamino-trained seed tracks poorly (0.19 m/s) and another falls 4 times in 64 at 1 m/s, much as one MuJoCo-trained seed does. Newton's VBD solver has no articulation support in Isaac Lab yet, and its Steel solver is not released, so we could not test either. Kamino data.

At coarse physics steps, both engines produce policies that fail to learn normal walking. The recordings show feet sinking or jittering through the ground. Those are failures of the learning setup before they are transfer results.

When learning fails: step size and contact settings

Step and contact stiffness: a narrow working range

The last cells vary the physics step in both engines and Newton's contact time constant at the default step. In Newton, a larger step also forces softer contact, because the solver clamps the time constant to at least twice its substep. Pairing the cells separates the two effects.

Five seeds per engine · final training reward (≈ 21 is a competent walker) · falls over all five commands, 1,600 robot runs per pair
Cell	Newton contact	Reward, Newton / PhysX	Falls, PhysX → Newton	Falls, Newton → PhysX
Defaults (5 ms step)	5 ms (clamped)	21.4 / 21.6	15	2
2.5 ms step	2.5 ms (clamped)	22.7 / 22.0	2	6
10 ms contact, Newton only	10 ms	21.7 / –	–	0
20 ms contact, Newton only	20 ms	7–21 / –	–	37
10 ms step	10 ms (clamped)	4.9 / 12.6	374	77
20 ms step	20 ms (clamped)	−0.8 / 2.9	156	1,600

Within the working range, contact stiffness again shapes transfer. A 2.5 ms step, which in Newton also stiffens contact to 2.5 ms, brings PhysX-trained policies into Newton almost cleanly: 2 falls instead of 15. The price is harder Newton impacts, with a 99th-percentile foot force of 4.0 kN against 2.4 kN. Softening Newton's contact to 10 ms at the default step leaves learning intact, halves those impacts (1.2 kN) and gives the cleanest transfer to PhysX, with no falls.

Outside that range, learning fails before transfer can be judged. At a 10 ms step, Newton-trained robots never learn to walk and PhysX-trained ones learn only partly. At 20 ms, Newton training collapses: its robots fall within half a second, even in their own engine. The pairing shows that the 10 ms failure comes from the step, not from the softer contact it forces: the same 10 ms contact at the default step trains normally. At 20 ms, softness contributes: with 20 ms contact at the default step, two of five seeds fail to learn to walk. The large transfer numbers in these rows describe policies that were never competent, the same distinction the insertion pilot drew.

What the failed policies do

The coarse-step failures are not just low rewards: each engine fails in its own way, and the failure is visible in how the feet meet the ground. At a 20 ms step, Newton must soften contact to a 20 ms time constant, and the robot's feet sink about a centimetre into the ground within the first 0.2 s. Its policies never learn to stand: all 1,600 evaluation runs fall, even in Newton itself, half within 0.6 s. PhysX keeps contact rigid but solves it only once per 20 ms with four iterations: the feet jitter in and out of the floor by up to 3.3 cm between samples. Its policies survive by crouching low and staying still. At a 10 ms step, Newton policies stand in a crouch and never walk. At the default 5 ms, feet stay within 3 mm of the surface.

Four step sizes, four outcomes. Seed-0 policies, each trained and run in its own engine and step size, commanded to walk forward at 1 m/s from the same start. The 5 ms Newton policy walks 9.7 m. At 10 ms it stands in a crouch (0.1 m). At 20 ms it collapses after 1.3 s. The 20 ms PhysX policy stays low and barely moves (0.2 m). Foot heights are sampled at the 50 Hz policy rate. Selected after inspecting outcomes. The other recorded robots behave alike. Replay provenance.

These settings undermine learning before a transfer test can establish anything about a competent policy. A flat reward curve alone would not reveal the contact problem. Checking a few recorded rollouts helps distinguish this failure from a strategy that learns successfully but fails elsewhere.

4. Grasp-and-Lift

Isaac Lab’s transfer recipe still loses 20–29 points in our tests

Isaac Lab 3.0’s early-access transfer guide lists this Franka grasp-and-lift task among its validated cross-backend examples. How well do our trained checkpoints perform when evaluated in the other engine?

The arm must pick up one of eight objects (cubes, thin slabs, a sphere and capsules up to 20 cm long) and carry it to a target that moves every four to six seconds. The task is built for transfer: friction, object mass, joint gains, joint friction and gripper speed are randomized. The policy sees no body velocities to reduce sensitivity to the engine. A curriculum starts in zero gravity and raises it as the policy succeeds. We trained it with the guide's own command at its defaults, one seed per engine, side by side on one GPU.

Both policies eventually learned their source task. We used the default 15,000 iterations, then resumed each run for 5,000 more. Resuming also reset the curriculum and rebuilt the starting-state bank, so the eventual improvement cannot be attributed to the extra training alone. The training history and checkpoint recordings are below.

Both directions lose ground, and the size of the gap depends on the evaluation

We evaluated both final policies in both engines on 512 episodes each, with the curriculum at full difficulty. From the same random seed the two backends draw different starting states, so these comparisons are not paired episode by episode.

Grasp-and-lift success in three conditions. Under standard conditions the Newton-trained policy scores 88 percent in Newton and 68 in PhysX; the PhysX-trained policy scores 82 percent in PhysX and 53 in Newton. Under nominal conditions Newton-trained success reverses to 55 percent in Newton and 76 in PhysX. — **The transfer gap depends on the evaluation condition.** Each panel follows one frozen policy across both engines, with 512 episodes per condition. Lines connect aggregate rates, not paired episodes. Standard, playback and nominal conditions are defined below.

Exact grasp-and-lift success rates

Final policies · success in 512 episodes per engine and condition
Trained → evaluated	Standard	Isaac Lab playback	Nominal
Newton → Newton	88%	87%	55%
Newton → PhysX	68%	68%	76%
PhysX → PhysX	82%	83%	88%
PhysX → Newton	53%	52%	40%

Standard uses the training randomization and Isaac Lab's collision-checked starting states with the object free. Playback is Isaac Lab's own setting, where a quarter of the episodes start with the object already in the hand. Nominal switches the randomization off. Under the training conditions, the Newton policy drops from 88% to 68% in PhysX and the PhysX policy from 82% to 53% in Newton (Fisher's exact p < 10⁻¹³ for both). The randomized recipe did not eliminate the gap for these two checkpoints. We did not train a matched cohort without randomization, so this does not measure how much randomization helped. Engine-specific starting-state banks also prevent us from assigning the full gap to execution dynamics alone.

The two policies fail differently. With one seed per engine, we cannot tell whether these are traits of the training engines or of these particular seeds. The Newton policy commands large joint steps, typically 0.05 radians per 33 ms control step and up to about 1 radian. Isaac Lab's guide warns that such bang-bang commands can exploit how one solver integrates drives and limits, and in PhysX they trip the joint-speed limit far more often: 84 of the 162 failures in PhysX end that way, against 22 of 61 within the training engine. The PhysX policy’s failures in Newton include 97 joint-speed stops, 37 objects pushed out of the workspace and 109 episodes that run out of time without reaching a target.

Two training engines, two evaluation engines, one object. Both final policies with a 15 cm capsule (episode 5 of 512 in each run). Both succeed within their training engine. The Newton-trained policy fails in PhysX, where a joint exceeds its speed limit after 1.7 s. In this episode the PhysX-trained policy succeeds in Newton, which it does in 53% of episodes. Starts are similar but not identical across engines (see above). Selected after inspecting outcomes. Replay provenance.

PhysX-trained · in PhysX

PhysX-trained · in Newton

Newton-trained · in Newton

Newton-trained · in PhysX

Rendered episodes of the final policies in each engine, with Isaac Lab's playback starts (not matched across clips).

With the randomization switched off, the comparison changes again. Both policies lose objects out of the workspace in Newton (177 and 209 of 512 episodes) but almost never in PhysX (1 and 2). Because this happens to both policies, it is a property of Newton at these nominal values, which sit at the edge of the training ranges (object friction, for example, at its lowest). We have not established its cause.

Learning history: late progress and a curriculum reset

Learning arrives late, then all at once

The default budget is 15,000 iterations. In Newton, the policy spent the first 12,000 of them doing almost nothing: random motions trip a joint-speed limit that ends the episode with a large penalty, and the policy learned to keep the arm still. Then its exploration widened again, and within 2,000 iterations its training success rate rose from almost zero to 67%. PhysX was slower still: at 15,000 iterations it succeeded in 1.5% of training episodes, with the curriculum barely started. With one seed per engine, this timing difference may belong to the seeds rather than to the engines.

We extended both runs by 5,000 iterations, resuming from their final checkpoints. The PhysX policy then learned within about 1,000 iterations and ended at 96% training success, close to Newton's 98%. We cannot say how much of that jump the restart itself caused: resuming resets the curriculum to zero gravity and rebuilds the task's bank of starting states. Evaluated with Isaac Lab's playback settings on 128 episodes per checkpoint, the Newton policy succeeds in none up to iteration 13,000, then 2% at 13,500, 20% at 14,500 and 86% at the end. The PhysX policy succeeds in none up to 14,000, then 2% at 14,500, 48% at 16,000 and 81% at the end.

Six checkpoints, one start. Each policy at iterations 0 to 19,998, run in its training engine from one fixed start. In the Newton run the cube starts in the hand. At iteration 0 the untrained policy's first command, up to 0.1 rad per joint at once, moves the arm fast enough that the task's joint-speed check ends the episode after a single 33 ms step. 25 of 128 episodes at this checkpoint end this way, and the rest run out of time without success. At 8,000 the arm drops the cube and folds away, and by 14,999 it carries the cube into the target (translucent sphere, 5 cm success radius). Purple arrows show the policy's joint commands, green arrows the force on each finger. Replay provenance.

Iteration 0

Iteration 12,000

Iteration 14,000

Iteration 16,000

Rendered episodes along the Newton run (Isaac Lab's RTX renderer, 12 s each). The table turns green when the object reaches its target. The clips use Isaac Lab's playback starts and do not share one start. The replay above does.

5. From task-specific RL to general-purpose policies

π0.5 succeeds in both engines but grasps worse in Newton

π0.5 can retry a failed grasp and still finish a task. We ran the same checkpoint in both backends to see whether completion rates missed differences in how it handled objects.

In our earlier evaluation of open-source general-purpose robot policies, we compared five policies on RoboLab and found that success rates hid distinct weaknesses in grasping, transport, release and recovery.

Four RoboLab tasks without retraining

We test Physical Intelligence's π0.5, a generalist vision-language-action policy (the DROID joint-position release), first without retraining in RoboLab-Verified. Both backends, PhysX and Newton (MuJoCo-Warp), load the same USD scenes and render the cameras with the same Isaac Sim RTX renderer. The images the policy sees therefore differ only through the physics. Each backend runs at its defaults.

RoboLab's benchmark tasks have one authored layout, so every episode of a task starts from exactly the same state in both engines. Episodes differ only through the policy's sampling noise. We seed that noise per episode and per action chunk, so the PhysX episode and the Newton episode with the same index draw the same noise. In PhysX this makes repeated runs bit-identical. Newton is not repeatable from run to run: in a repeat with identical noise, only 2 of 10 episodes matched. Its pairing is therefore approximate.

Across four RoboLab tasks, both engines complete 40 to 50 of 50 episodes. Newton records more failed grasps in all four tasks; drops increase from 2 to 21 for banana to bowl and from 27 to 57 for bottle to pail. — **Completion can conceal rougher handling.** Each task has 50 noise-paired episodes per engine. Success counts episodes. Failed grasps and drops count events, which can occur more than once in an episode. The panels use different horizontal scales. Pairing is approximate because Newton reruns are not repeatable.

All RoboLab results, including discordant outcomes and completion times

π0.5 · 50 noise-paired episodes per task and engine · events summed over episodes
Task	Success, PhysX / Newton	Discordant pairs	Failed grasps	Drops	Median time to success
Rubik's cube → bowl	47 / 50	0 / 3	6 / 9	2 / 1	9.5 / 9.8 s
Banana → bowl	42 / 46	4 / 8	6 / 14	2 / 21	11.8 / 12.2 s
Banana → plate	49 / 49	1 / 1	2 / 10	1 / 6	10.9 / 11.3 s
Bottle → pail	47 / 40	10 / 3	14 / 32	27 / 57	13.4 / 20.7 s

π0.5 succeeds on 80–100% of episodes in both engines. The largest observed gap is bottle → pail: 47/50 in PhysX against 40/50 in Newton, or 14 percentage points (exact McNemar p = 0.09). These samples do not establish equivalent success rates. The handling records reveal further differences. In Newton the policy fails more grasps on every task, 1.5 to 5 times as many in total. Compared episode by episode, 41 noise-matched pairs have more failed grasps in Newton and 13 more in PhysX (sign test, p < 0.001), though per task the difference is individually clear only for banana → plate (p = 0.02). Drops rise clearly on two tasks: on banana → bowl the policy drops the banana 21 times against 2 (p < 0.001), but regrasps and still succeeds. On bottle → pail it drops the bottle 57 times against 27 (p = 0.003). On bottle → pail Newton also needs 50% longer to succeed. Behind similar totals the outcomes also disagree pair by pair: on banana → bowl, 12 of 50 noise-matched episodes end differently.

Setup checks and a simulator abort

Two engineering lessons came first. On our cloud host, the RTX renderer initially failed to start because the container lacked the NVIDIA graphics libraries. The policy then received images from a renderer that was not running, and RoboLab still recorded ordinary failures. Validating the camera frames once per setup would have caught this. We found it only because the failures looked implausible. Second, Newton once aborted a run with non-finite robot joint values (bottle → pail, step 586). A rerun with the same noise completed. We report the abort as a simulator failure, not a policy outcome.

Fine-tuning in one engine

We fine-tune π0.5 with low-rank adapters (LoRA) on a task it finds hard: putting a wooden spatula into a bowl, where it succeeded 4 times in 10 in a first probe. The training data are the policy's own successful attempts in PhysX: 104 successes from 180 recorded episodes (58%), stored exactly as the policy saw them. This is supervised fine-tuning on the policy's own successes, not reinforcement learning: no reward is optimized and the policy does not act during training. Base and fine-tuned policies are then compared in PhysX and in Newton on the same noise-paired episodes.

Before any fine-tuning, the base policy puts the spatula in the bowl in 22 of 50 PhysX episodes. Newton runs about three times slower on this scene, and its evaluation reached our four-hour limit after 40 episodes. On those 40 noise-paired episodes, the policy succeeds 17 times in PhysX and 4 times in Newton (exact McNemar p = 0.004). Every Newton failure happens at the grasp, with 2.5 failed grasp attempts per episode against 0.7 in PhysX. Here the scene itself changes before the grasp. The spatula stands in a utensil holder, and the scene's starting poses are a resting state in PhysX: there it leans against the holder's front wall and stays put until the gripper arrives. Newton models the holder's collision geometry and contact differently, so the same poses are not at rest. Within the first half-second the spatula tips into the back corner of the holder, beside a second utensil, in a slightly different place each episode. Bumped by the gripper, it slides deeper into the holder.

The robot is not needed for this. We loaded only the holder and the two utensils into Newton with RoboLab's solver and contact settings. At the saved poses both utensils overlap the holder's convex collision pieces by about 3 mm, and the holder floats 2 mm above the table. With no robot present, the spatula moves 6 cm and turns by 37° within half a second. Setting contact margins to zero does not change this. Neither does a five times finer convex decomposition of the meshes, nor Newton's own collision pipeline in place of MuJoCo's: the spatula still moves 6 to 8 cm.

The saved poses were a resting arrangement in PhysX, but not in Newton. The four tasks above start essentially unchanged in both engines. Only the bottle task's lying jug rolls slightly in Newton. It also limits what the fine-tuning comparison can show: every training episode was recorded in PhysX, with the spatula against the front wall. In Newton, the fine-tuned policy faces arrangements it never trained on.

Watch the grip on the wooden spatula. PhysX lifts the target out of the holder and completes the placement at 10.3 s. Newton makes repeated grasp attempts, then drops the wooden spatula from the closed gripper at 40.3 s. It falls off the table. The upper views show the whole scene. The wrist cameras below show the target and gripper. Full camera frames, original speed, run 2, environment 2 in both engines. The PhysX view holds its final frame after completion. Recording and event logs.

π0.5 · wooden spatula → bowl · successes on the same noise-paired episodes
Policy	PhysX, 50 episodes	PhysX, first 40	Newton, first 40	Failed grasps per episode, PhysX / Newton
Base	22	17	4	0.7 / 2.5
Fine-tuned in PhysX	34	26	12	0.5 / 2.2

The fine-tuned policy succeeds in 34 of 50 episodes against 22 for the base policy. On the noise-paired episodes it gains 17 and loses 5 (exact McNemar p = 0.017). Failures at the grasp fall from 24 to 13, and the median time to success drops from 23 to 20 seconds. The evaluation uses the same scene as the training data with fresh sampling noise, so this measures improvement on the training task, not generalization.

In Newton, the fine-tuned policy improves by a similar number of episodes, from 4 to 12 of 40 (12 gained, 4 lost, p = 0.08), despite facing spatula positions it never trained on. The gap between the engines stays about the same: 26 against 12 on the shared 40 episodes. The changed arrangement is a likely contributor. This comparison does not isolate it from other differences in grasp execution. We tested one task and one fine-tuning run. The Newton gain was uncertain (p = 0.08). We cannot generalize from that.

Watch a successful pair after fine-tuning

Fine-tuning helps in this selected pair. The fine-tuned policy succeeds at 18.7 s in PhysX and 28.8 s in Newton. These are run 1, environment 8 from the fine-tuned evaluations. The base-policy example above uses run 2, environment 2. The PhysX episode holds its final frame after it ends. The aggregate results describe all evaluated episodes. This example does not imply that fine-tuning closes the engine gap. Recording provenance.

6. Practical lessons

What to check before trusting a transfer result

Most of these policies transfer. The checks below are the ones that changed our conclusions, each with the number that made it matter. Roughly in order: confirm that the interface and the physics are what you think they are, confirm that the source policy is competent, and only then measure transfer, under stated conditions.

Checks before trusting a transfer result
Check	What we saw	What to do
Friction combine rules	Identical authored foot friction became 0.8/0.6 in PhysX (multiplied) and 1.0 in Newton (larger value kept). Matching it cut PhysX-to-Newton falls from 11 to 3 of 320.	Set pair friction explicitly and read it back from the running engine.
Friction cone	Isaac Lab's flat ANYmal preset runs Newton with an elliptic cone and impratio 100. A pyramidal cone cut PhysX-to-Newton falls from 39 to 12 of 6,400, with the same policies. Lowering impratio alone did nothing. Newton's hard-contact Kamino solver, with a round cone, gave 16.	Read back the cone type and impratio, and include the cone in the evaluation sweep.
Contact-stiffness clamps	Newton clamped a requested 1.8 ms contact time constant to 5 ms, twice its 2.5 ms substep. MuJoCo clamps to twice its step as well.	Read back the effective value. Stiffer contact needs a smaller step.
PhysX solver	The fragile insertion policy succeeded on 5 of 25 starts with TGS 100/1 iterations, 21 with PGS and 19 with TGS 4/0. Its peak load fell from 82 N to 24 and 19 N.	Put the solver configuration in the evaluation sweep. More iterations is not automatically safer.
Stiffer contact as a stress test	MuJoCo with 2 ms contact reproduced the PhysX failures: seed 4 fell from 50 to 14 of 50, while seed 0 stayed at 50.	Before a cross-engine study, rerun the frozen policy with stiffer contact in its training engine.
Joint order	Newton orders joints per leg, PhysX per joint type. In the wrong order, a walking policy fell in 62.5% of episodes, and nothing raised an error.	Map joints by name, or set Isaac Lab’s joint ordering, and assert the names.
Physics step	10 and 20 ms steps broke locomotion training in both engines. A 2.5 ms step cut PhysX-to-Newton falls from 15 to 2 but raised Newton foot impacts to 4.0 kN.	Keep legged RL at 5 ms or less, and check in a few rollouts that the feet stay on the ground.
Training budget	Isaac Lab’s 300-iteration ANYmal default was far from converged in PhysX, which plateaus at 600–1,000. The grasping task showed almost no success for 12,000–15,000 iterations before it learned.	Run past default budgets before concluding that a setup does not learn, and watch for collapsed exploration.
Evaluation conditions	One grasping policy scored between 55% and 88% in its own engine depending on starts and randomization. With randomization off, the engine ranking reversed.	Report starts, randomization and the success definition with every transfer number.
Same seed, different episodes	The backends drew different starting states from the same random seed.	Treat cross-engine comparisons as unpaired unless the starts are written explicitly.
Determinism and execution path	PhysX GPU reproduced training checkpoints byte for byte. Newton repeats matched 2 of 10 episodes. One policy scored 4/8 on PhysX CPU and 8/8 on PhysX GPU.	Name the execution path, not only the engine, and plan for run-to-run variance in Newton.
Scene at rest	A RoboLab scene saved at rest in PhysX re-settled in Newton. π0.5 then succeeded 4 times in 40 against 17.	Watch the first second before the first action, and settle scenes per engine.
Rendering	A renderer that failed to start produced ordinary-looking policy failures.	Inspect camera frames once for every new host or setup.
Numerical validity	In the deformable pilot, 835 of 1,218 MuJoCo training episodes ended in mesh invalidity, each with a penalty.	Count invalid episodes separately. A breakdown penalty becomes part of the reward.

Agreement across simulators still does not establish real-world accuracy. The next step in this series is to test which of these measurements predict behavior on the real robot.

How this relates to earlier work

Systematic comparisons of physics engines mostly measure speed, accuracy and stability on fixed systems, not what a learned policy does [1, 2]. The closest precedent to our question is Mohammed and Valdenegro-Toro [3], who trained standard control benchmarks with several reinforcement-learning algorithms in MuJoCo and PyBullet and evaluated each policy in the other engine. Policies trained in MuJoCo transferred best, none trained in PyBullet generalized, and outcomes depended strongly on the random seed. Our insertion seeds and the asymmetric grasping losses (20 points from Newton to PhysX, 29 in the other direction) fit the same picture: transfer belongs to a particular policy and direction, not to an engine pair.

Solver settings have been implicated before. Discussing a humanoid policy that ran well in MJX, MuJoCo's GPU port, but failed in CPU MuJoCo, MuJoCo's developers explained that the two reach close constraint solutions when the solver converges, but “can differ if you stop the solver early”, and that aggressively lowering solver iterations “can impede transfer” [4]. Our PhysX ablation examines a related dependency: changing the target solver or lowering its iteration budget improved a fragile insertion policy’s score. Kadian et al. [5] showed that evaluation settings alone can change which policies look good. Navigation agents in Habitat had learned to slide along walls. With the nine trained models held fixed, switching sliding off and removing actuation noise raised the correlation between simulated and real success from 0.18 to 0.844. Our grasping evaluation makes a related point within simulation: the ranking of the two engines reversed when randomization was switched off.

Higher fidelity is not uniformly better. Navigation policies trained with simple kinematic motion reached 100% success on a real Spot robot, against 40–67% for policies trained with contact dynamics in Bullet [6]. For precise ball control in robot soccer the reverse held: a policy trained in an ODE-based simulator scored in 9 of 10 real trials, against 4 of 10 for one trained in an abstract simulator, which nonetheless did better in simulation [7]. Closest to our contact results, Tac2Real [8] compared tactile contact models for peg insertion: two reached nearly the same success in simulation (0.776 and 0.789) but 91.7% and 15% on the real robot. As in our studies, equal success in the training simulator said little about behaviour elsewhere. Engine choice is usually argued on throughput. Brax, for example, learned Ant at about the same rate per step as MuJoCo and, with an accelerator-based training pipeline, reached the same score in about 10 seconds instead of about 3 hours [9]. Our results suggest the engine also shapes what is learned and how well it travels.

Appendix

Deformable insertion pilot: the simulator’s failure modes enter the training signal

The earlier cases show policies adapting to contact dynamics and carrying those dependencies into another engine. With deformables, the training signal can also depend on whether the simulated object remains valid. In part one, we tested soft objects with scripted controllers. Here we trained PPO in MuJoCo and in Newton, which couples two solvers for this task: MuJoCo-Warp for the rigid arm and VBD (Vertex Block Descent) for the soft ball, exchanging contact forces in both directions. The policies push the 60 mm ball through a 55 mm opening. The script supplies the broad manipulation sequence. The network learns corrections to arm targets, finger opening and grip force.

The replay below follows the same Newton-trained policy in both engines from a matched start. It reaches the goal in Newton. In MuJoCo, a small volume element of the ball's mesh inverts and ends the episode. That changes how we interpret this transfer failure: the target simulation loses mesh validity before we can assess completion of the physical task.

One learned policy, two execution engines. Newton-trained seed 29, matched start 10103. In Newton the ball passes during lowering and reaches the goal at 3.336 s. MuJoCo detects mesh invalidity at 3.286 s. Each panel holds at its endpoint. The gold sphere marks the goal, reached before floor contact. This selected pair illustrates a numerical failure during transfer, not a general ranking of the engines. Saved native states, half-speed playback. Replay provenance.

This also affects what the learner experiences before transfer. In the three MuJoCo training runs, 835 of 1,218 episodes ended in numerical invalidity. Each such termination carries a penalty, so avoiding simulator breakdown becomes part of the optimization problem. A network could learn to avoid a numerical boundary that has no equivalent in the physical task. We have not shown that these policies learned such avoidance: corrections did not consistently improve on the script, and different observation normalization further limits the comparison. The lesson is to audit the simulator's failure modes as part of the training signal, before attributing a learned behavior or transfer gap to physical dynamics.

Policy replays, scripted controls, and study limitations

Small corrections change the contact sequence. On matched start 10103, Newton-trained seed 29 makes the ball pass during lowering in Newton, while the same policy encounters mesh invalidity in MuJoCo. The script waits for the push. Each recording holds at its own endpoint.

Another policy delays passage until the push. On matched start 10117, the script passes early in Newton. Learned seed 11 retains the ball until pushing in both engines. These selected trajectories illustrate execution differences, not distinct learned strategies.

The scripted control helps locate the problem. On matched start 10102, MuJoCo's mesh inverts beside the rounded rim at 3.347 s. Newton continues to the push. In the MuJoCo scripted baseline, 13 of 17 invalid episodes occurred while seating the ball with the fingers still closed. The issue therefore also occurs without learned corrections.

Failure mechanism, not yet a root cause. The inspected MuJoCo failure localizes an inverted element beside rim contact. We have not isolated whether mesh resolution, material modeling, contact handling or the solver causes it. Newton also has invalid episodes, including cases following escape during transport. The 20 Hz saved traces do not resolve the substep forces. Newton's invalid traces retain the last accepted state. A half-step check changes outcomes, but the Newton check also changes batch size, so it cannot isolate timestep sensitivity.

The learning comparison remains limited. Three seeds per engine received 32,768 transitions each, with 24 paired evaluation starts and eight-start half-step checks. Learned corrections did not consistently improve on the script. Escaped balls could fall until timeout, producing extreme distance-based penalties. Newton's saved ball-height normalization had a standard deviation of 5.7–8.0 m, versus about 8 cm in MuJoCo. Common-input prediction differences therefore include different preprocessing as well as learned weights. A cleaner follow-up needs workspace termination and shared fixed input scales from the start of training.

The Newton training runs recorded 120 invalid episodes out of 936. Across the 400 evaluation episodes, 162 ended with nonpositive tetrahedron volume. All invalid episodes remain in the evaluation denominators. All accepted successes occur before floor impact. Later landing behavior is outside the task. The experiment is paused, with its aggregate results and failure diagnostics retained.

Data and supporting methods

The five-seed study data include all ten selected checkpoint identities, the frozen protocol and per-seed results. The 2,552 episode records include scripted references and retain the distinction between new and historical starts. Export code, figure code and checksums accompany them.

The separate PhysX training pilot provides matched checkpoint identities and 192 validation and comparison records, with its own export code and checksums. The settings study provides its screening design and confirmation design, both fixed before their outcomes, with screen and confirmation results (including every engine readback), the override code and checksums. The locomotion results include per-seed metrics and engine readbacks, with export code and checksums. The friction-cone ablation and the Kamino transfer matrix list per-seed falls and metrics for every evaluation. Replays are rebuilt by one and another export script. ANYmal-D display meshes come from ANYbotics' ANYmal D simple description (BSD-3-Clause, © 2023 ANYbotics AG; licence), converted by this script. Their link frames match the simulated Isaac Lab model exactly. The simulation itself used Isaac Lab's ANYmal-D asset. The grasping results list every evaluation and training checkpoint, with the training cell, the evaluation code, a replay export script and checksums. Its Panda display meshes are part one's. The RoboLab fine-tuning comparison includes 180 episode records for the four policy/backend evaluations. Its recording provenance identifies the selected episodes and source checksums. Export code composes the original camera recordings. The grasp comparison includes the selected event logs and camera checksums, with its export script. The main result graphs are rebuilt by the plotting script from the published summaries and the retained RoboLab table. The original plan distinguishes the larger proposed study from the experiments reported here.

The deformable pilot includes evaluation summaries, mesh-failure diagnostics, and replay selection and file checksums. Its interactive replays render saved 20 Hz native states without rerunning physics. Validity and goal entry were checked at 1 kHz. Terminal panels are held, and invalid Newton episodes show the last accepted state.

For the earlier rigid-body studies, native traces store body poses independently of the camera, including finite terminal states, for interactive 3D replay. Display poses are sampled at 100 Hz. Reported load peaks use the full 1 kHz physics rate. Raw checkpoints, frozen scenes and complete native traces are retained in the experiment archive but are not included in these downloadable exports.

References

T. Erez, Y. Tassa, E. Todorov. “Simulation tools for model-based robotics: Comparison of Bullet, Havok, MuJoCo, ODE and PhysX.” ICRA 2015. doi:10.1109/ICRA.2015.7139807
M. Kaup, C. Wolff, H. Hwang, J. Mayer, E. Bruni. “A Review of Nine Physics Engines for Reinforcement Learning Research.” arXiv, 2024. arXiv:2407.08590
A. P. Mohammed, M. Valdenegro-Toro. “Can Reinforcement Learning for Continuous Control Generalize Across Physics Engines?” arXiv, 2020. arXiv:2010.14444
“Causes of different behaviour in MJX and CPU MuJoCo.” google-deepmind/mujoco, issue #1341, 2024. github.com/google-deepmind/mujoco/issues/1341
A. Kadian, J. Truong, A. Gokaslan, A. Clegg, E. Wijmans, S. Lee, M. Savva, S. Chernova, D. Batra. “Sim2Real Predictivity: Does Evaluation in Simulation Predict Real-World Performance?” IEEE Robotics and Automation Letters, 2020. arXiv:1912.06321
J. Truong, M. Rudolph, N. Yokoyama, S. Chernova, D. Batra, A. Rai. “Rethinking Sim2Real: Lower Fidelity Simulation Leads to Higher Sim2Real Transfer in Navigation.” CoRL 2022, PMLR 205. proceedings.mlr.press/v205/truong23a
A. Labiosa, Z. Wang, S. Agarwal, et al. “Reinforcement Learning Within the Classical Robotics Stack: A Case Study in Robot Soccer.” ICRA 2025. arXiv:2412.09417
N. Yan, S. Wang, X. Shen, H. Wang, H. Wang, Y. Xiang, J. Pang. “Tac2Real: Reliable and GPU Visuotactile Simulation for Online Reinforcement Learning and Zero-Shot Real-World Deployment.” arXiv, 2026. arXiv:2603.28475
Google Research. “Speeding Up Reinforcement Learning with a New Physics Simulation Engine” (Brax). Blog, 2021. research.google/blog

Acknowledgements

Thank you to everyone who read drafts of this post and gave feedback, especially Eric Heiden.