Atlas Merge Geometry 🔀

The atlas-camera pack deliberately builds scenes from composable pieces - a relief mesh here, fitted walls there, a sky dome somewhere else - and each of those derivations can come from a different solve. Atlas Merge Geometry is the explicit combinator that stitches two independently-derived solves' geometry together, the way a Nuke Merge node combines two plates. It's the 🔀 in Atlas/05 · Geometry.

It's the node you reach for when one solve gives you the building and another gives you the foreground, or when you've used AtlasBlenderMassing / AtlasMergeGeometry output to bring in geometry from a separate branch and need it welded into the scene. And it's chainable: Merge(fg, bg), then Merge(that, sky) - exactly how you'd stack Nuke merges.

How it works

The node takes two ATLAS_SOLVE objects - solve_a and solve_b - and combines their geometry into one solve. The important design note, spelled out in the code: solve_a's camera and intrinsics become the merged solve's camera. So the rule is to wire both branches from the same upstream solve so they share a camera; the node doesn't check for or correct a mismatch between the two. It's a geometry combinator, not a registration node - AtlasMultiViewSolve does that job. Use it to combine, not to reconcile.

Inputs and outputs

Required inputs:

• solve_a - becomes the merged solve's camera and intrinsics.
• solve_b - its geometry joins solve_a's.

Optional input:

• shot_cam - an optional AtlasDefineShotCam format attached to the merged solve for AtlasBlockoutViewport and exporters to conform to. It never affects this merge's own geometry or camera - it's a delivery format, not a transform.

Output: a single ATLAS_SOLVE with the combined geometry.

Installing it

Core-tier, no extras:

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

Restart ComfyUI; it's in Atlas/05 · Geometry (ComfyUI Manager: "atlas-camera"). It doesn't need any of the neural/vision extras to run - it's pure geometry bookkeeping.

Common issues

The one mistake people make with this node is treating it as a fixer. If solve_a and solve_b came from different cameras, the merge doesn't know and doesn't care - the output will happily combine geometry from two unrelated viewpoints and you'll chase the resulting mess. Both branches must trace back to the same solved camera for the merge to mean anything.

The other habit worth forming: chain explicitly rather than assuming a binary merge is enough. Three or more sources mean two merges, and the order matters the same way it does in a comp - foreground-last usually wins.