Skip to main content
Capture a still image from a specific camera pose without moving the user’s interactive viewport. This is useful for MuJoCo-mounted dataset cameras, policy rollout reports, thumbnails, and visual regression checks. Unlike useFrameCapture, this renders the scene to an offscreen render target. It does not require preserveDrawingBuffer.
For the distinction between viewer cameras, MuJoCo cameras, explicit capture poses, and virtual debug camera overlays, see Cameras and Captures.

Signature

CameraFrameCaptureResult and CameraFrameCaptureBlobResult include source.kind, which is one of mujoco-camera, mujoco-site, mujoco-body, custom-camera, explicit-pose, or fallback-camera. Dataset recorders should prefer the MuJoCo-mounted source kinds.

Usage

API Ref Path

MujocoSimAPI exposes the same offscreen camera capture methods:
mujocoCameraCompatibility is only applied to named MuJoCo <camera> captures. It derives width/height from MJCF resolution, uses MJCF fovy, copies visual clip planes when available, and installs an asymmetric projection matrix from cam_intrinsic and cam_sensorsize when those arrays are exposed by the WASM model. Leave it off for synthetic position + lookAt probes where you are manually matching a dataset view. Use projectionMatrix when you already have calibrated camera intrinsics. Use visualOverrides to temporarily override scene background, environment, fog, shadow maps, tone mapping, or output color space for one capture. Use renderIsolation when policy or training images should be rendered with an independent offscreen WebGLRenderer instead of inheriting viewer renderer state.

Policy Image Payloads

Use usePolicyCameraFramesFromMountedStreams or capturePolicyCameraFramesFromMountedStreams when a policy expects image keys such as observation.images.front and observation.images.wrist. The helper resolves dataset stream names to mounted MuJoCo cameras, sites, or bodies, captures each stream, and returns both raw frames and payload-ready data URLs.
Use the non-hook helper when policy execution happens outside React:
Explicit Three camera poses are also valid policy streams. They do not move the user’s orbit camera:
Policy stream keys stay stable even when they resolve through aliases. In the example above, result.frames.wrist, result.images.wrist, and result.images["observation.images.wrist"] are populated even though the mounted MuJoCo camera is named wrist_cam.

Notes

  • Use cameraName for MuJoCo <camera> elements, or siteName / bodyName for robot-mounted camera frames.
  • Use positionOffset and quaternionOffset to calibrate a mounted camera pose without editing MJCF. Offsets are applied in the mounted camera/site/body local frame. Quaternion arrays use Three.js order [x, y, z, w]; convert MuJoCo [w, x, y, z] quaternions before passing them.
  • Use position + lookAt only for synthetic fixed debug cameras.
  • Use quaternion when replaying a recorded camera pose.
  • Use camera to clone an existing THREE.Camera.
  • The returned canvas is generated from an offscreen render target.
  • Use hiddenGeomGroups, visibleGeomGroups, or hiddenGeomNames to match a dataset renderer without changing the interactive scene.
  • Use visualOverrides and renderIsolation for canonical policy/training captures that should not inherit the interactive viewer’s visual effects.
  • Use flipX to mirror captured frames horizontally when matching a policy dataset or camera convention that stores mirrored images.
  • Advanced renderers can attach a function to CAMERA_FRAME_CAPTURE_RENDER_USER_DATA_KEY in scene object userData to provide custom Three pixels for capture.