← All research
Photoreal · Research preview

Augmentic's first step toward photoreal robot simulation

A first technical report on Augmentic's learned renderer: G-buffer-conditioned, autoregressive, 1 to 4 denoising steps, measured over 1,000-frame sequences and compared with FrameDiffuser.

Augmentic Research · Oct 26, 2026 · 7 min read
Frame 345 of the daylight warehouse layout: Unreal Engine 5.6 reference on the left, our renderer's output on the right Engine reference Our output · 4 steps

Every robot shipping today is being trained and tested in a generic warehouse, a clean kitchen, lighting that never changes. Real sites have a ton of surprises.

At Augmentic we believe robotics companies can scale 10x faster when they can train and test with confidence inside their own sites, under every condition a robot might exist in: morning sun through the loading dock, the night shift under LEDs, the aisle that was rearranged last week.

That is why we are building Augmentic. We want creating a hyperrealistic, physically accurate digital twin of a real site to be as seamless as recording a video of it, so every release can be tested before it ships, every situation that has not happened can be generated, and every failure can be captured and replayed in simulation.

This post is the first step on the visual half of that promise. Here are the results of V0 of our photoreal renderer.

Introducing the renderer

Engine reference, Frame 100 Our output · 4 steps, Frame 100 Engine referenceOur output · 4 steps
Daylight layout

Augmentic turns a phone scan of a real site into a digital twin that runs in Isaac Sim, MuJoCo or Gazebo. The physics engine owns the scene: geometry, objects, contacts, camera pose. What it cannot cheaply give you is the image a real camera would record there, under the lighting of that shift, with the glare, shadow and noise a perception stack has to survive. That is the job of our learned renderer.

The renderer reads the engine’s G-buffer, the per-pixel surface colour, normal, depth and roughness that any deferred rasteriser already produces, and generates the photoreal frame. It also reads its own previous frame, reprojected into the new camera view with the engine’s depth and pose, so appearance carries from frame to frame.

5.8to 9.8 fps

Frame generation at 768×448 on one GPU, four steps to one step.

1,000frames

Autoregressive sequences on two layouts the model never saw, one in daylight and one at night, from one model.

0.41LPIPS

Perceptual error against Unreal Engine 5.6 renders on the unseen night layout at four steps.

How it works

The simulator keeps control of everything that matters to the task. The renderer only learns appearance.

G-buffer (t) basecolor · normal · depth + Warped render + irradiance (t−1) warped with depth + pose Noise (t) latent 96 × 56 × 4 Basecolor (t) divides warped luminance Render (t) 768 × 448 · 5.8 to 9.8 fps QQQ KKK VVV G-buffer ControlNet 14-channel hint trainable QQQ KKK VVV ❄❄ SD 1.5 UNet + Hyper-SD LoRA frozen · bf16 D ❄ Decoder × 1 / 2 / 4 steps · TCD sampler ÷ luminance → irradiance channel render (t) reprojected with engine depth and relative pose → context (t+1)
Cyan blocks and arrows are trained or computed per frame; grey blocks with a snowflake are frozen.

Measured results

We evaluated three things separately:

  1. Similarity to the engine reference
  2. Behaviour over long sequences
  3. Inference time

The references are Unreal Engine 5.6 renders of two held-out warehouse layouts with their own exposure settings, 1,000 frames each, with a walking robot-height camera. Camera 1 is daylight, camera 2 is night. The first frame uses the engine’s frame 0 as context; every later frame uses only the renderer’s own previous output. Nothing else from the reference enters the loop.

Image fidelity across a full sequence

LPIPS measures differences in learned visual features (AlexNet backbone), PSNR measures pixel-level reconstruction, SSIM measures structure. All three are averaged over every one of the 1,000 frames, not a selection of stills.

SequenceStepsLPIPS ↓PSNR ↑SSIM ↑fps
Camera 1 · day40.43611.40.4555.7
20.45411.60.4659.5
10.51411.70.4739.8
Camera 2 · night40.41312.10.3345.9
20.43612.20.3409.5
10.49112.20.3469.7
1-step output, frame 1001 step · 9.8 fps
4-step output, frame 1004 steps · 5.7 fps
Engine reference, frame 100Engine reference
Frame 100 of camera 1 at one step, at four steps, and the engine reference. One step is softer; four steps recovers edges and box texture. Both carry the same slightly warm, over-exposed cast relative to the reference.

Temporal consistency, measured with motion compensation

Frame-to-frame flicker matters to a policy as much as per-frame fidelity does, and it is usually reported badly or not at all. A raw difference between consecutive frames mixes real camera motion with flicker. Because we already reproject the previous frame with exact depth and pose, we can separate them: we warp the previous output into the current view, compare it with the current output over the valid mask, and do the same for the engine reference. The ratio tells you how much more the rendered video changes than the scene itself does. At four steps, our output changes roughly six times more than the engine reference after motion is removed.

Warping error per frame, camera 1, 4 steps (mean absolute error after reprojection)
00.030.060.090.1202505007501000■ our output■ engine reference

Inference cost on one GPU

Each value is the mean over 999 frames of a 1,000-frame sequence, with GPU execution synchronised before and after. The timing covers reprojection of the previous frame, the ControlNet and UNet passes for each step, and the VAE decode. It excludes loading the G-buffer from disk, metric computation and video writing. Hardware is a single RTX PRO 6000 Blackwell, bf16 for the networks, fp32 for the decoder.

StepsSeconds per frameFrames per secondMedian95th percentile
10.1029.80.1050.116
20.1059.50.0970.160
40.1735.80.1700.214

The curve is roughly 0.09 s fixed plus 0.02 s per denoising step. The fixed part is dominated by the full-precision VAE decode and is the obvious next target: a half-precision or distilled decoder would about double the frame rate at every step count without touching the renderer’s weights.

See the output

Our output on the left, the engine reference on the right, both at 24 fps playback. Twelve seconds from the daylight sequence at four steps, starting three seconds in.

Daylight layout. Left: renderer, 4 steps. Right: Unreal Engine 5.6 reference.
Reference (top left) against the same weights at 4, 2 and 1 steps. The frame rates shown are the measured generation rates above.

What needs to improve

Compared with FrameDiffuser

OursFrameDiffuser
PSNR ↑11.714.17
LPIPS ↓0.420.363
Denoising steps410
Frames per second~6≈1
GPU cost per frame~6× lower1×
Number of frames1,000100

Fine detail and lighting both matter to a robot, and we are short on both.

Frame 500, our outputOurs · frame 500
Frame 500, referenceReference
Frame 1000, our outputOurs · frame 1000
Frame 1000, referenceReference

If you have a site and want a digital twin of it set up, book a call with us.