IAMCCS Viggle · Cine Video + Image
Viggle Needs a Driver and a Face — This Is Where They Come From
- cine_linx
- driving_video
- reference_image
- driving_audio
- fps
- report
Character animation needs three things: a performance to copy, a character to apply it to, and audio. In an IAMCCS H3 workflow you already loaded all three - they're just sitting in the project bus instead of on wires. This node pulls them out.
It takes cine_linx and returns driving_video (IMAGE), reference_image (IMAGE), driving_audio (AUDIO), fps (INT, always 24 for H3) and a report (STRING). No widgets at all. That's the point: the media was already authored in the Shotboard / Cine Info H3 layer, and this is the handoff to your local Viggle-Animate route.
Where the media has to come from
Three specific slots, read from the linx resources:
iamccs_minimax_h3_ref_video→driving_videoiamccs_minimax_h3_ref_image_1→reference_image(the first image only)iamccs_minimax_h3_ref_video_audio→driving_audio
In practice that means: load your driving clip and connect it to Cine Info H3's reference_video, and load your character image into reference_image_1. The node's error messages say exactly this - miss the video and you're told to connect Load Video IMAGE to Cine Info H3 > reference_video; miss the image and you're told the same about Load Image and reference_image_1. Clear failures, which is more than most bus-based nodes manage.
The audio fallback actually matters
If the driving video has no audio track, this node doesn't fail - it synthesises silence at 32 kHz sized to the clip's frame count, flags it internally, and says silent fallback in the report. Otherwise the report records source video audio.
That's the behaviour you want for a mute reference performance, and it pairs with the patch sold by the Universal / Viggle selector: VHS's lazy AUDIO output raises on a video with no audio stream, and this pair of nodes is the difference between a video-only driving clip being usable and being a graph-killing crash. If you generate your driving video in ComfyUI, it very often has no audio.
What you wire it into
driving_video and reference_image go to your Viggle-Animate-H3 inputs; driving_audio follows the performance through to the final combine; fps keeps a downstream combine node honest at 24. Then the generated frames come back through the selector node.
The pack is careful about this boundary - it does not import Viggle's implementation and does not ship it. Everything here is IAMCCS media extraction; Viggle stays a separate, optional install. Which is good, because the local Viggle path is one of several ways to do character animation, and the alternative in this same pack is the universal H3 route.
Install
cd ComfyUI/custom_nodes
git clone https://github.com/IAMCCS/IAMCCS-nodes.git
Or Manager → IAMCCS Nodes; restart and hard-refresh the browser afterwards, and keep one copy of the repo in custom_nodes - duplicate clones cause stale frontend routes, the README says so explicitly, and a bus node that "isn't there" is a classic symptom.
No dependencies for this node specifically. It reads tensors out of a dictionary.
Realistic expectations
Viggle-style body-swap animation has been around since 2024 and the community's verdict hasn't changed: the motion transfer is the easy part, the identity is the hard part. Every frame is a chance for the face to drift, and no amount of reference material fully fixes it. The reason the pack gives you reference_image_1 as a single chunky input rather than a gallery is honest signalling about what the downstream route can actually use.
Check the report before you blame your settings. If it says silent fallback when you expected the source audio, your driving file is mute and you're about to animate to nothing.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| cine_linx | IAMCCS_SUPERNODE_LINX | — |
Outputs (5)
| Name | Type | Description |
|---|---|---|
| driving_video | IMAGE | — |
| reference_image | IMAGE | — |
| driving_audio | AUDIO | — |
| fps | INT | — |
| report | STRING | — |