Atlas Relief Geometry (MoGe-shaped) 🗺

The CrossView-Warp style of LTX camera moves wants a very specific shape of input: moge_geometry - metric depth per pixel, a validity mask, and intrinsics. The obvious way to get that is to run MoGe inside your graph. And for a pose-based camera path, that's a trap, not a convenience.

Here's the problem in one sentence: your camera arrives in metres from an Atlas solve, while MoGe's depth is a separate estimate of the same scene, made by a different model with its own scale and its own recovered lens - and nothing anywhere checks that the two agree. When they disagree, the move renders at the wrong depth with no error, no warning, no hint. Atlas Relief Geometry 🗺 exists to make that failure structurally impossible: it takes the geometry from the same solve the camera came from, so depth and pose literally cannot disagree, because they're one measurement.

How it works

The pack builds a relief mesh from the solve - terrain in Atlas world metres, already tuned by whatever edge settings built it. This node rasterises that mesh through the solve's own intrinsics into a MoGe-shaped moge_geometry: depth grid, validity mask, normalized intrinsics. Since both the geometry and the camera come out of the same solve, a metric camera path through them is coherent by construction.

There's a deliberate honesty in what comes out, too. Where the relief has no triangle - sky, holes, content the mesh simply doesn't cover - the depth is NaN and the mask is False, which the warp renders as magenta for the LoRA to fill. That is the honest answer to "what was never photographed", and it's the same answer the pack's 📽 Project view draws. No model guessing at where the sky is.

Inputs and outputs

The required inputs are the solve and the raster size: width and height should match the frames you feed the warp. frames (optional, default 1) is how many frames to emit - a still plate warped by a camera path needs one geometry per frame of the clip, so set it to the clip length. Outputs are moge_geometry and a report that tells you the raster the depth was built at, the metric depth range it covers, and the percentage of the frame that's real geometry versus magenta hole.

The default category in the pack puts this in the advanced tier, and it's aimed at one specific pipeline: a solved still being warped along a camera path rendered with LTX. If that's your workflow, this is the node that keeps the depth honest.

Where it sits in the pack

Its sibling for a dressed shot is Atlas Unreal Depth Geometry 🗺 - if your frame carries things built on top of the photographed terrain (a castle added in Unreal), the relief mesh doesn't know about them and they'd rasterise at the hill's depth, warping like paint on the hillside. Unreal's own rendered depth pass is the right source then. This node is for the plain case: the photo's own geometry, warped through the photo's own camera.

Installing and running it

Part of atlas-camera, so:

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

Then restart ComfyUI - no pip dependencies for this node; the heavy neural extras (GeoCalib etc.) are only needed by the solve nodes upstream, not by this one. Give it a solve that already carries a relief mesh - derive one via AtlasInput or AtlasDeriveReliefMesh first. Feed it a solve with no relief and it refuses with a clear error rather than inventing geometry, which is exactly the behavior you want from a node whose whole job is "don't invent a second opinion."

Gotchas

The width/height here are the working raster, not your delivery size - match the frames you actually feed the warp, or the intrinsics end up describing the wrong image. And set frames explicitly for a moving plate; forgetting it and running a clip against a single repeated geometry is a classic silent way to get a warp that doesn't move the way the path says it should.