RS Camera Control

What it's for

The moment you put characters at explicit coordinates, framing stops being a prompt problem and becomes a layout problem. You ask for a wide shot, the caption lands, and now both characters are floating mid-canvas in masks sized for a medium shot.

RS Camera Control does both halves. It writes the view captions from four axes, and on request it also zooms, rotates or flat-plane-projects the character regions in the pipe so boxes and masks follow the framing you asked for. It's the local-side twin of NAI Camera Control - same engine, same editor, registered separately under RS/Camera, and it defaults to prompt_syntax=ComfyUI, which is the syntax the local side actually uses.

Reach for it when you're driving RS Multi-Character Sampler or an NAI context and want the camera moved. No diffusion model, no ControlNet, no extra sampler pass.

How it works

Captions first. Each axis becomes tag weights via a raised-cosine blend, s(t) = (1 − cos(πt)) / 2, so you get two neighbouring tags at complementary weights between knots instead of snapping between them. Azimuth maps from front / viewed from the left side or viewed from the right side / from behind at 0/90/180°, the horizontal weight scaled by 0.85 × cos(elevation)² - at ±90° elevation the horizontal caption disappears, because yaw means nothing at the pole. Elevation maps from above/from below at 60° and overhead view/worm's-eye view at 90°. Distance blends across five framing tags. Roll adds dutch angle. Everything is multiplied by strength, formatted as (from behind:1.02) or 1.02::from behind::, and bare tags in plain mode.

Then layout. layout_sync=fixed leaves coordinates alone. distance_and_roll zooms and spins every character region around the canvas centre - distance 0.5 is original size, 0 doubles it, 1 halves it, and positive roll rotates clockwise in image coordinates. Set canvas_aspect to your generation width ÷ height (1216/832 = 1.461538) or rotation comes out stretched. perspective goes further and applies a pinhole projection to the whole flat mask plane using azimuth and elevation, so the near side grows and the far side shrinks.

That last one is a flat-plane trick, not a 3D reconstruction. It doesn't invent the person's back silhouette or handle occlusion. At ±90° yaw or elevation the plane goes edge-on and the node stops with a readable error telling you to reduce the angle or use distance_and_roll.

The inputs that matter

• azimuth / elevation / distance / roll - the four axes, all draggable in the in-node diagram: click or drag in the left circle for direction, the right semicircle for height, wheel for distance, shift+wheel for tilt.
• strength (default 1.2) - just start at 0.8–1.4. Cranking it produces distortion, not obedience.
• layout_sync - the one people miss. fixed writes captions only; the mask transforms are opt-in.
• canvas_aspect - only matters with layout sync on, and it's the most common cause of mangled rotation.
• scope - scene_and_characters (default) appends the caption to character prompts too. Keep it; a view caption that lives only in the common prompt can get swallowed by regional conditioning.

Connect a building_pipe (draft or final character pipe, or an NAI_CONTEXT) and you get building_pipe back out for the sampler, plus prompt (scene + camera merged) and camera_prompt (captions only). base_prompt is where the scene goes if your pipe doesn't carry one - without it the node errors out rather than overwriting your scene with camera words.

random_mode=balanced keeps views inside −90…90 azimuth and −35…35 elevation; full uses everything. random_seed is a separate 32-bit camera seed, so randomising framing doesn't reshuffle your image seed. One execution draws one view; a batch downstream shares it.

Install

Manager → search ComfyUI_RS_NAI_API_Request → Install → restart. Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/raspie10032/ComfyUI_RS_NAI_API_Request.git
cd ComfyUI_RS_NAI_API_Request
python -m pip install -r requirements.txt

The requirements file drags in torch, segment-anything and scipy for the pack's detailer and tagger nodes; the camera node uses none of it and needs no weights, no token. Camera processing is entirely local - only the sampler downstream can spend money.

Where people get burned

Mask transforms need the partner pack. Silhouettes, boxes and body-part masks in a local pipe are decoded by RS Multi-Character Sampler, so if you're editing local mask records you want both extensions updated together. A plain native NAI context is fine without it - it just shows character points instead of silhouettes.

Ten characters, max. The local mask round trip is capped at 10 characters; beyond that the node tells you so.

Edge cases are errors, by design. Zoom or rotate until a character's whole mask falls off-canvas and you get "reduce zoom/tilt or adjust Position" instead of a character silently turning into global conditioning.

Chained sync compounds. Two layout nodes back to back multiply their transforms.

Don't expect a rear view just because you asked. Text-based framing loses to looking at viewer and front-facing descriptions. The author's own validation got a side-facing face on a rear-view attempt and mismatched character sizes on a wide shot. Treat it as a strong nudge; the layout transforms are the part you can rely on.