Atlas Move Budget 📐

Every projection setup has a hard limit: move the camera too far and the photographed surface gets torn away - pixels that were covered by the foreground slide off it, and you see nothing behind. Atlas Move Budget answers the question nobody else bothers to: exactly how far can this camera move before that happens? It's the 📐 in Atlas/08 · Look & Render, and it's the node you run before you author a camera move, not after.

The output is a per-DOF envelope - dolly x/y/z, pan, tilt - telling you the safe range for each axis. That turns camera-move authoring from guesswork into something you can plan: dolly this far, but only pan that much.

How it works

The mechanism is honest brute force: it rasterizes the scene from candidate cameras and measures where the photographed surface has been torn away. The measure is "sealed-minus-covered," so the answer is unaffected by whatever backdrop you have and grows as you fill tears - the safer your scene gets, the more move budget you earn. It reports a per-DOF envelope, and if you connect a camera_path (the authored move), it checks every frame of the actual move and names the worst one in the report. Which is usually the question worth asking: not "can I theoretically dolly," but "is this move safe?"

Two results look wrong and are right: pan and tilt are often unbounded, because rotation about the optical centre produces no parallax and therefore can't open a tear. And any axis is unbounded when nothing is hidden along it. The report marks a saturated axis when the search hit your cap.

Inputs and outputs

• solve (required) - needs a relief mesh behind it (AtlasDeriveReliefMesh or AtlasInput), since that's what gets rasterized.
• camera_path - optional; the authored move to check per-frame.
• threshold - fraction of the frame allowed to tear open before a move counts as unsafe. Default 0.02 (2% of pixels); that's a reasonable number, tighten it for hero shots.
• bisect_steps - precision of the envelope search; 8 is ample, higher costs proportionally more.
• max_dolly_m - search cap in metres; 0 = auto (a quarter of the median scene distance).
• max_angle_deg - pan/tilt search cap, default 30°.
• backend - auto/torch/numpy. Leave it on auto.

Outputs: solve (with the budget attached) and report.

Installing it

Core-tier node - the rasterization runs on torch (which ComfyUI already ships), so a plain clone suffices:

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

Restart and it's in Atlas/08 · Look & Render (ComfyUI Manager: "atlas-camera").

Common issues

The numpy backend is real but punishingly slow - the docstring says roughly 60x slower than torch. If it's crawling, check that backend is on auto; it should never be set to numpy unless you're debugging the math.

And interpret the unbounded axes correctly. A report that says pan/tilt are unbounded isn't a bug - it's the physics of a projection camera. Rotation about the optical centre doesn't create parallax, so it can't tear. The dollies are where your budget actually lives, and that's where you should spend it.