Nodes/Atlas Camera/Atlas Export Camera Path (USD) πŸŽ₯
ComfyUI Node

Atlas Export Camera Path (USD) πŸŽ₯

Bake the viewport move into a time-sampled USD camera

By mikejamesvfxΒ·Created 3 months agoΒ·Updated a day agoΒ· 1
Atlas Export Camera Path (USD) πŸŽ₯
  • solve
  • camera_path
  • project
  • usd_path
β—„output_diratlas_exportsβ–Ί

You've authored a camera move in the viewport's Camera Path mode - orbit, dolly, vertigo, all that - and the pixels are baked. Now you need that move in a DCC, and it needs to match the pixels frame-for-frame. AtlasExportCameraPathUSD is the handoff: it writes camera_path.usda, a time-sampled (Usd.TimeCode-keyed) animated camera from the path you baked, ready for any USD-pipeline application.

The whole point is fidelity: the DCC camera should be the same camera that rendered the frames, so your comp lines up instead of drifting. That's why this node exists separately from the pack's general AtlasExportUSD - it takes a different, specific required input: the ATLAS_CAMERA_PATH itself.

What it does

Required inputs: solve, camera_path (the ATLAS_CAMERA_PATH from the viewport's baked path), and output_dir (default atlas_exports). Output: usd_path (STRING) - where the .usda landed.

Two details from the catalog are worth knowing before you export:

  • Vertigo is honoured. When any keyframe carries a fov_deg (the πŸŒ€ Vertigo move is a dolly-zoom with a keyframed counter-fov), the focal length is time-sampled too - per-frame vertical fov converted to mm against the solve's derived sensor height. A static-lens path keeps one untimed solved focal. So a vertigo move comes out as a real dolly-zoom in USD, not a flat camera with a frozen lens.
  • Shake is applied. If the path's 🎬 Cinematic shake is enabled (the deterministic seeded rig noise - track chatter, jib bounce), it's baked into the exported camera, so the DCC camera matches the baked pixels. Analysis consumers of the same path always sample clean; this export is the "match the render" one.

Optional project routes the export into the project tree's usd/ lane and supersedes output_dir, same as the other export nodes. Output node, terminal step.

The one gotcha

The catalog is blunt about it: this node raises rather than no-ops when no path has been baked. That's the state of every first queue - you haven't authored a move yet, so there's nothing to export. It's why the pack's fan-out example ships this node muted: bake a path in the viewport first, then run the export. If you get an error about a missing path on your first try, that's expected behavior, not a bug - go author the move.

Install

cd <ComfyUI>/custom_nodes
git clone https://github.com/mikejamesvfx/atlas-camera.git

Restart (or Manager β†’ "atlas-camera"). This one needs the [usd] extra (usd-core β‰₯ 22.11) - USD import/export is lazy in this pack, so importing Atlas doesn't require USD, but this node does. The core export logic is otherwise dependency-free. Upstream depth/solve nodes may need [neural] if you use a learned solve, but a geometric solve + this export is a light path. Brand-new pack, no community folklore - the "raises on no path" behavior is the main thing that'll bite you, and it's documented honestly.

CategoryAtlas/10 Β· Export

Inputs (4)

NameTypeDefaultDescription
solveATLAS_SOLVEβ€”
camera_pathATLAS_CAMERA_PATHβ€”
output_dirSTRINGatlas_exportsβ€”
projectoptATLAS_PROJECTOptional delivery project from AtlasProject β€” routes this export into the project tree's usd/ lane and supersedes output_dir.

Outputs (1)

NameTypeDescription
usd_pathSTRINGβ€”