Viggle Remake: 2つのH3 LoRAで任意の動画を撮り直す

左: ソースクリップ。右: 同じショットでパイナップルのマスコットを入れ替えたもの。モーション、カメラ、タイミングは変更なし。

Viggleは8月下旬のViggle-Animate以来この方向で開発を進めてきました。それは大きく蒸留されたH3 ref2vaファインチューン上で、1枚の塗り直したフレームからショット内のキャラクターを置き換えるものでした。Remakeはモデルカードがそこで予告していた「Viggle-Animate v2」であり、2つの点で前進しています。純正のH3トランスフォーマー上のLoRAでありファインチューンではないこと、そして人物以外も編集できることです。

2つのモード

どちらのモードも、ソースクリップと1〜4枚の参照画像を受け取ります。プロンプトでは <Picture 1> から <Picture 4> と呼ばれます。これらの参照は自分でペイントします。クリップから取り出したフレームの上に描いても、ゼロから描いてもよく、それぞれを元にしたソースフレームにピン留めできます。

• swap は人物やキャラクターを、1人でも複数同時でも置き換えます。
• edit はそれ以外すべてです。オブジェクトの入れ替え、削除、挿入、背景・天気・光の変更を行います。

編集LoRAがショットからオブジェクトを削除している間も、カメラの動きとプレートの残りはそのまま。

アイデンティティは顔エンコーダーやセグメンテーションマスクではなく、ペイントしたフレームから決まります。だからこそこのパイプラインにポーズ推定やトラッキングは不要で、また、同意を検証できないとモデルカードがはっきり述べている理由でもあります。アイデンティティが決まる唯一の場所は、あなたが描く画像です。

技術的な中身

各モードはPEFT LoRAで、rank 256、alpha 256、H3のFL2VAトランスフォーマーの302個のリニアレイヤーに適用され、bf16で保存され、4つの proj_in / proj_out テンソルはfp32です。ベースモデル自体は変わりません。LoRAはロード時に適用される差分です。リポジトリには、同じ重みをComfyUIのレイヤー名に詰め直したもの、マージ済みのint8およびGGUFトランスフォーマー、inference/sample.py の参照サンプラーも含まれています。

音声は生成ではなく引き継がれます。出力はソースクリップのサウンドトラックを保持するため、無音のソースからは無音の結果になります。また、オーディオのエンコードは末尾でパディングされます。ComfyUI標準のオーディオエンコードはトラックを両端から800サンプルブロック単位にトリミングするため、映像に対して最大400サンプルずれるからです。

ComfyUIでの手順

ComfyUIはH3をネイティブに実行するため、ノードパックがカバーするのは標準ノードと動作が異なる4点だけです。ComfyUI 0.42.0でテストされた3つのノードを追加します:

• Viggle Remake Conditioning: ソースフレーム、オーディオ、最大4枚の参照、ピンフレーム、プロンプトを受け取ります。
• Viggle Remake Keyframe Until: ピン留めした参照を、サンプリング範囲の指定割合までキーフレームに変換します。
• Viggle Remake Noise: シードに対する参照サンプラーの開始ノイズを再現します。

グラフはそれ以外は標準です: LoraLoaderBypassModelOnly、BasicGuider、euler を指定した KSamplerSelect、ManualSigmas、SamplerCustomAdvanced、2回のVAEデコード、24 fpsの Create Video。

1つの設定は速度ではなく出力を変えるため、繰り返し強調する価値があります。通常の LoraLoaderModelOnly はLoRAをbf16の重みにマージしますが、bf16では更新の多くが丸められて消えます。プロジェクトの計測では、アテンションとMLPレイヤーで残るのは37〜73%のみで、swapの例でマージしたレンダーはシャープさが7%低下します（21.2 dB 対 24.7 dB）。LoraLoaderBypassModelOnly はLoRAを別分岐として保持し、レンダーあたり2〜3%の時間増で済みます。

小型カード: int8とGGUF

bf16のルートには80 GBのカード1枚と約144 GBのベースモデルが必要です。それ以下では、各モードはLoRAをfp32でマージして量子化済みの単一トランスフォーマーファイルとして提供され、グラフ内のベース拡散モデルとLoRAローダーの両方を置き換えます。

プロジェクトのカード別表は、editの例を226フレーム、ピン留め参照2枚で測定したものです:

• 12 GB: Q4_K_MまたはQ8_0と --reserve-vram 8。int8は124フレームのみ。
• 16 GB: 832x480でint8。Q4_K_MまたはQ6_Kと --reserve-vram 6。1280x736ではQ4_K_Mと --reserve-vram 10、124フレーム。
• 24 GB: 832x480でint8またはQ4_K_M。1280x736ではQ4_K_MまたはQ8_0と --reserve-vram 20。
• 32〜80 GB: 832x480ならint8またはQ8_0で余裕。1280x736ではint8ファイルは48 GBおよび80 GBカードの226フレームでメモリ不足になる一方、Q8_0は予備領域を確保すれば24 GBに収まります。

bf16 + LoRAの参照に対する品質を全フレームのPSNRで測ると、int8はswapで27.2 dB、editで46.8 dB、Q8_0は26.9と49.8、Q6_Kは24.6と44.6、Q4_K_Mは20.6と38.3です。swapの列はノイズの多い結果です。同じbf16の重みを2回目にわずかに異なる方法で丸めるだけで、そのレンダーは29.6 dBに動くため、そこの数dBはフォーマットの順位ではありません。

速度

B200 1台、832x480、226フレーム、ピン留め参照2枚で、モデル読み込み後のComfyUIは1レンダー約95秒、6ステップで1ステップあたり約13.5秒、sample.py は約58秒です。読み込みを含む最初のレンダーは2.5〜3分かかります。1280x736では1ステップ64〜72秒、1レンダー510〜585秒です。プロジェクトはB200のみを測定したと明記しており、コンシューマー向けカードではより遅くなります。

制限

• 1回のレンダーは90〜345フレーム（17n+5、24 fps）のウィンドウをカバーします。プロジェクトは最大294フレーム、約12秒を推奨しており、それより長い動画はMCPサーバーがショット境界で分割するウィンドウになります。
• 6セクションのH3プロンプトが必須で、そのタイムスタンプはフレーム数と一致している必要があります。
• ペイントしたフレームがアイデンティティと見た目を決めます。ピン留めしたフレームはそのフレームの構図も固定します。
• 既知の失敗: 1つのロングテイクに非人型キャラクターがいる場合、細部の小さなアーティファクト、マルチショットクリップをピンなしでレンダーした際の時間的なドリフト。

ComfyUIワークフローに同梱されているswapの例: 226フレーム、フレーム12と184にピン留めした2枚の参照。

editの例: パンと光はそのままに、タービンがプレートから消える。

入手方法

重み、LoRA、int8およびGGUFファイル、ノードパック、ワークフローはHugging Faceにあり、COMFYUI.md、PROMPTING.md、MODIFICATIONS.md も同梱されています。リポジトリは完全版で約210 GBあるため、ComfyUIガイドでは comfyui/ と examples/inputs/ のサブセットのみをダウンロードします。2026年11月4日に公開され、同日に@viggleaiが発表しました。カードには他の編集モデルとのベンチマークはなく、上記の数値はプロジェクト自身によるものです。