Atlas Export Camera Path (USD) π₯
Bake the viewport move into a time-sampled USD camera
- solve
- camera_path
- project
- usd_path
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.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| solve | ATLAS_SOLVE | β | |
| camera_path | ATLAS_CAMERA_PATH | β | |
| output_dir | STRING | atlas_exports | β |
| projectopt | ATLAS_PROJECT | Optional delivery project from AtlasProject β routes this export into the project tree's usd/ lane and supersedes output_dir. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| usd_path | STRING | β |