IAMCCS H3 PREVIS · Camera + Subject Blocking

Video models have no camera track. You ask for "slow push in" and hope the sampler agrees. MiniMax H3 got the closest thing to a fix - a Fun Union control patch that takes a control video (pose, depth, edges) and pins the render's geometry to it - but the obvious use has a trap: depth-estimate your own clip and you lock in the motion you already had.

Previs flips it. Author the move in a greybox scene, render it, and let that be the geometric authority while your references keep the identity. IAMCCS_H3PrevisControl is the converter that makes it work: previs frames in, H3 control video out, plus the text telling the model which cylinder is the protagonist.

What it actually does

Flip enabled on and it does three things: turn your previs frames into a normalised depth batch, inject that batch into the CineLinX bus under the same key the pack's IAMCCS_CineH3FunControlInput writes (so the Shotboard consumes it as H3 Fun control media), and emit a generated direction string plus a JSON manifest.

With enabled off it's a pure pass-through - the bus returns untouched and nothing comes out of the other three outputs, so the node can live in a graph permanently. previs_video is lazy and only requested when the switch is on, so nothing costs you anything until you use it.

The two depth routes, and where they diverge

representation is the first real decision.

rgb_proxy_to_depth is for coloured primitives. It runs DepthAnythingPreprocessor through ControlNet Aux's AIO_Preprocessor at preprocess_resolution (512 default, 128–2048 step 64) - the depth pass resolution, not your H3 render size. Leave it low; the geometry only needs to be readable. It hard-requires comfyui_controlnet_aux, and names the package in a RuntimeError if it's missing.

direct_depth is for previs you already rendered as depth - a Z or Mist pass out of Blender, a depth buffer out of an engine. The batch must be three-channel RGB where the channels agree: if any pixel's red/blue or green/blue gap exceeds 0.03, the node rejects it with "Direct depth is not grayscale. Use RGB proxy to depth for colored primitives." That's deliberate - an ID or colour render encodes no distance, and feeding it in silently breaks your blocking.

Here's the gotcha the widget order hides: depth_polarity only does anything in direct_depth mode, where near_black inverts the depth. On the rgb-proxy route it's ignored entirely - the manifest records near_white no matter what you picked.

The inputs you'll actually set

• bindings_json - JSON list, max 32 entries, each with proxy, subject, trajectory. The default reads like documentation: a yellow cylinder as proxy for "the protagonist in <Picture 1>". It all lands in the blocking_prompt output, which you append to the shot prompt.
• source_fps - your previs render's frame rate. The Shotboard uses it to map source frames onto each chunk's clock; get it wrong and control and shot drift apart.
• source_offset_seconds - recorded in the manifest for provenance, not applied. Trim upstream if your previs has a lead-in.
• previs_video - a decoded IMAGE batch (Load Video, VHS Load Video). A filename string gets you "a filename is not an IMAGE batch."

Outputs: cine_linx goes to the Shotboard. exact_depth_preview is the batch actually being sent - wire it to a preview when the shot ignores your blocking. blocking_prompt is the STRING. manifest is JSON and worth reading once: camera_authority and geometry_authority are true, identity_authority false, and the binding contract reads "text direction, not deterministic object tracking." Don't expect a cylinder locked to a pixel.

Install

ComfyUI Manager → IAMCCS Nodes, restart, hard-refresh the browser. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git

There's no requirements.txt, so nothing pip-installs. What you need: a current ComfyUI (the project asks >=3.0.0) with the MiniMax H3 Fun nodes in comfy_extras, the MiniMax H3 Fun Union patch in models/model_patches (legacy models/controlnet still works), and comfyui_controlnet_aux for the rgb-proxy route. No weights ship with the pack, and H3's community licence excludes the US, EU, UK and Korea - worth knowing before you build on it.

Wiring and the traps

The node sits on the CineLinX path before the Shotboard: H3 Settings or the CineH3Input fan-in → IAMCCS_H3PrevisControl → Shotboard (or into CineH3Input's h3_fun_control_input slot). Wire it downstream of the Shotboard and the depth is never read; upstream of Settings and you get "PREVIS requires the Settings/CineH3Input bus before Shotboard."

Then the part everyone forgets, because the media is invisible inside the bus: the H3 Settings node owns the switch. h3_controlnet_enabled must be ON, h3_controlnet_name must point at the Fun Union patch, and h3_controlnet_kind must be depth to match what the previs node produced. The author's own tooltip is explicit that these boxes don't run a hidden preprocessor - they declare what you already made.

One more, straight from the backend: if the previs clip is shorter than the shot, windowing hard-fails before sampling with "H3 Fun Control control_video is too short for this Shotboard chunk". Match the previs duration, or set the Settings short-source policy to hold_last. And keep the previs simple - Depth Anything on real lit footage flickers frame to frame, while flat-shaded primitives stay stable. That's the whole reason this workflow uses them.