A visible Isaac Lab scene or camera panel does not prove that the policy receives the intended image. Trace the configured camera output into the observation tensor, then into the model input. Changing the visualizer can make debugging easier while leaving that producer-to-consumer path unresolved.
This is an observation-contract check, separate from selecting a supported simulator version or comparing backend speed. The immediate question is which pixels, if any, reach the policy.
Separate the renderer, task mode and inspection view
Isaac Lab’s 3.0 backend and preset documentation distinguishes physics, renderer and task-specific presets, with the visualizer selected separately. Renderer configuration supplies camera rendering; a task preset can change observation modes and tensor shapes. Support is task-specific, so inspect the installed task’s help rather than assuming every named renderer or RGB preset works with it.
The visualization documentation also describes streaming views that can use an existing sensor or an automatically created camera. Such an inspection camera is not, by itself, evidence that the policy’s observation term consumes its output.
Trace one frame through the actual observation path
Use a proposed debugging record for one environment instance. Identify the camera, the output being read, the observation term and the preprocessing that reaches the model. A screenshot answers what the viewer displayed; a tensor record answers what the policy consumed.
| Stage | Record | Failure it can expose |
|---|---|---|
| Camera producer | Sensor identity and requested output | A different camera or modality |
| Observation term | Exact field and environment index | Image omitted or wrong instance |
| Preprocessing | Shape, channels and transformation | Unexpected crop, order or normalization |
| Policy input | Final tensor contract | Checkpoint and observation mismatch |
| Viewer | Displayed source and view settings | Inspection view mistaken for policy evidence |
Keep the same environment instance and frame relationship throughout the trace. Looking at one clone while logging another can produce plausible but unrelated evidence. If acquisition and inference run at different cadences, record which frame the observation term actually uses.
Keep checkpoint observations stable during playback
The preset documentation warns that observation modes can change tensor shapes and should remain consistent when loading a checkpoint. A model that loads successfully still needs the intended preprocessing and input meaning; matching dimensions alone do not settle channel order, image scaling or sensor identity.
Retain the training observation configuration with the checkpoint. When changing a camera layout or mode, treat the change as an input-contract change and assess it explicitly. Do not quietly substitute the viewer’s attractive image for the training-time input and assume the policy sees the same task.
The Isaac Lab demonstration-replay guide addresses state agreement and task success. This earlier debugging step asks whether the model receives the declared visual observation at all.
Finish with a trace that connects a named sensor output to the actual policy input. If the only evidence is a working viewport, leave the observation path unverified and investigate its missing edge.
Official release/3.0.0 branch documentation checked October 15, 2026. This branch can change; no Isaac Lab task or checkpoint was executed for the article.