Wan Animate 2 Shotboard Backend Bridge

In the IAMCCS V2V architecture, the Easy Shotboard shells are planners and the sampling graph is the executor, and something has to translate between them. IAMCCS_WanAnimate2ShotboardBridge is that translator: one input, twenty-three typed outputs. It takes the cine_linx contract produced by IAMCCS_V2VShotboardEasyWanAnimate2 and unpacks it into the concrete values - trim times, frame counts, strengths, context settings, prompts - that the backend (the IAMCCS_WanAnimate2Extends graph) actually samples with.

How it works

The node's map function reads the outputs.backend_settings block out of the CineLinX payload, with defensive fallbacks for every field (each value has a default, so a partially-built contract degrades gracefully instead of exploding). The interesting bit of logic: effective_lora_strength is only nonzero when the plan's apply_distill_lora is true - so a distill-LoRA that isn't enabled contributes zero strength to the backend, and you can't accidentally ship a half-applied LoRA. Everything else is a typed pass-through.

The full output list

The outputs mirror the Easy shell's knobs exactly: trim_start_s, trim_duration_s, target_frames, width, height, chunk_frames (normalized to 4n+1), generation_steps, generation_cfg, generation_seed, reference_strength, pose_strength, pose_start_percent, pose_end_percent, context_windows (BOOLEAN), context_length, context_overlap, pose_cache, empty_cache_each_chunk, positive_prompt, negative_prompt, pose_prompt, effective_lora_strength, and output_prefix.

Wire those into the corresponding inputs of IAMCCS_WanAnimate2Extends - trim_start_s and target_frames into the source loading, chunk_frames into chunk_length, the strengths and prompts into conditioning, the context values into the context-window machinery - and the backend reproduces the plan exactly.

Why you'd use it (or not)

If you drive the Easy shell directly, this node is the seam you never see - it lives inside the reference workflow the shell expects. Where it earns its keep is when you build your own backend around the shell's contract: instead of reading CineLinX JSON by hand, you get typed values that ComfyUI validates, and your graph stays compatible with any future Easy-shell change because the contract, not the widget layout, is what you depend on.

It's also the pattern to learn from if you're writing your own IAMCCS integration: the bridge is deliberately dumb - pure mapping, no defaults of its own, no sampling logic. The plan is the single source of truth, and this node just makes it consumable.

Ships with IAMCCS-nodes: ComfyUI Manager → search "IAMCCS", or cd ComfyUI/custom_nodes && git clone https://github.com/IAMCCS/IAMCCS-nodes.git, restart. No model files, no extra dependencies - it's a pure data-mapping node.