BSAI H3 MotionFix (fast-action glitch & noise repair guide)

You spent four steps on a MiniMax H3 fight shot, the punches came out as soup, and now you're staring at a smear that looks like someone dragged a wet brush across the frame. BSAI_H3_MotionFix is a node built for exactly that moment - but be clear about what it is before you wire it in.

What it actually is

It's a rules engine with a ComfyUI face on it. No model, no API, no key - you describe your shot (motion level, Turbo or not, attention backend, clip length) and it hands back a preset: step count, attention strategy, reference-weight target, a short negative prompt, a checklist, a post-processing plan.

That's the whole trick, and it's more useful than it sounds. H3 only opened up in August 2026, and what people know about stopping it smearing on fast action lives in scattered Chinese-language notes and Discord arguments. This node is one author compressing that into a lookup table - a stack of if statements you can read in five minutes, cross-verified on a date rather than measured.

The core claim matches what we know about distilled video models generally: a 4-step student has less room to refine detail than the teacher, and fast motion is where that shows first. Fewer, bigger denoising jumps means less temporal repair. Not a bug in your settings - the trade you made for speed.

The inputs worth thinking about

Three of the five required fields actually change the output:

• motion_level - fast_action (punch/run/turn), medium (...), static_slow (...). This is the big switch. Everything downstream keys off it.
• use_turbo_lora - default off. If you flip it on with fast_action selected, the node's first line of advice is to turn it back off and run native 20–24 steps. That's the single most opinionated thing it does, and it's right often enough to be worth obeying.
• attention - kitchen_attention (default), sage_attention, sla, native. Pick Sage with fast action and you get a warning about edge ghosting and frame tearing; pick SLA and you get the newer sparse-attention recipe (6–8 steps, CFG 6–7, don't mix accelerators).

ref_weight and clip_seconds don't change anything - they're echoed back inside the advice text so the numbers you read are about your shot. clip_seconds does one real thing: it becomes ref_length at 24fps. base_negative is optional and gets merged in front of the built-in negative list, not instead of it.

One oddity: the dropdown lists six options, three English and three Chinese. The Chinese ones are legacy labels kept so old workflow JSON still loads - they normalize to the English entries, same as native 原生. Ignore them.

The outputs, and which ones are actually wires

Six of the ten outputs are text you read, not connect: recommended_steps, attention_advice, ref_weight_advice, negative_prompt, checklist, post_process. It's an output node, so you can drop it in alone, hit Run, and read the plan in History. The other four drive a FastH3 graph:

• vsa_enabled (BOOLEAN) - False on fast action (turn VSA off, keep dense attention so you stop getting edge ghosting), True on the slower tiers.
• video_keep_percent (FLOAT) - 35% when VSA is on for fast action, 20% medium, 10% static.
• ladder (STRING) - always 999,749,500,250, FastH3's trained 4-step ladder. Don't rewrite it to a uniform grid.
• ref_length (INT) - frames for your ReferenceToVideo/ImageToVideo length. 8 seconds gets you 192.

Installing

No requirements.txt here, so the README's "no extra dependencies" claim holds up: ComfyUI plus your H3 setup, nothing else.

cd ComfyUI/custom_nodes
git clone https://github.com/xm6018924/BSAI-H3-MotionFix

Restart, then search BSAI_H3_MotionFix or MotionFix. It also looks for a sibling pack, BSAI-ComfyUI-Sol-H3, to apply a VAE-loading patch - no such pack, and the import is wrapped in a try/except and quietly skipped.

Where people get burned

Expecting the render to change. Nothing here touches sampling. If your ref_weight is 0.90 and the node says 0.78–0.82, you still have to go set it. Same for negative_prompt: H3 samples CFG-free, so a negative string is advisory unless your graph has somewhere to put it.

Assuming the advice installs the attention backend. Kitchen Attention, SageAttention and SLA are separate custom nodes. This pack only says which one to reach for - Kitchen, on a fight shot - and mixing accelerators is what makes people report "it broke".

Trusting the on-canvas card over the backend. The frontend JS recomputes the same plan live, but it doesn't know about sla - pick SLA and the card gives you the generic Kitchen line while the actual attention_advice output has the real, much longer SLA recipe. Read the output string, not the pretty card, when you're going down the sparse-attention road.

Treating it as a fix instead of triage. On 4 steps with genuinely fast action, the honest answer is "split the clip to ≤5s, drop to the 0.5MP tier, and re-shoot the master at native steps" - more work than people want, which is presumably why it ended up as a nine-item checklist.