MiniMax H3 Upscaler Settings Panel
The Node With No Logic That Saves You Ten Minutes of Widget Hunting
- status
What it is
Read the Python and you'll laugh: the entire class returns a string. Settings ready. Click Apply & Close in the panel, then queue the workflow. That's it. The node is a button, and all the work happens in web/VRGDG_MiniMaxUpscalerControlPanel.js.
That's the point. The pack's MiniMax H3 upscaler workflow spreads a single job - upscale this clip - across a loader, an A/V prepare node, an overlap-preset node, a scheduler, a sampler, a noise node and a fast VAE decode. Adjusting it means finding and editing eight widgets on seven nodes. This panel collects the seventeen settings that matter into one modal and writes them into the graph for you on Apply.
How it works
The JS adds an Open H3 Settings button to the node. Clicking it opens a modal with a Load Video button and a two-column grid of fields. On Apply & Close, it walks the graph and pushes values into nodes by class:
VRGDGLongVideoMetaBatchLoader / VHS_LoadVideo → video path, width, height, rate, frame cap
VRGDGOverlapPreset → preset, window, overlap, blend mode
MiniMaxH3SourceAVPrepareT8 → video mode, denoise
BasicScheduler → steps, sampler denoise
KSamplerSelect → sampler
RandomNoise → seed
H3FastVAEDecode → tile batch size
If a node isn't in your workflow it just skips it and reports how many it did find - so "Applied to 5 workflow nodes" when you expected seven is your signal that something's named differently. Matching is by class first, then by a title-contains fallback, and first match wins, which matters if you have two schedulers in the graph.
The Load Video button is the other half: it chunk-uploads your file in 50 MB pieces to the pack's own /vrgdg/long_video/upload route and drops the resulting path into video_path. No file widget, no upload-size limit.
The settings, and which ones you should touch
video_mode (remix / replace / enhance) and video_denoise (0.2 default) are the character of the pass - how much of your source survives. overlap_preset is the one that actually decides quality and VRAM: H3 Near 41 (39 / 5), H3 Balanced (73 / 17) and H3 Trained (124 / 22) are window/overlap frame pairs. Bigger window means more temporal context per pass and a more expensive run; custom_window / custom_overlap override the preset if you want to experiment, and blend_mode picks how the overlap region is cross-faded - cosine is the smooth default, linear is the one that shows seams on motion.
steps (5) and sampler_denoise (0.2) are deliberately low. This is a light refinement pass over an existing latent, not a generation, so five steps is normal here and you should be suspicious of anyone telling you 30. sampler offers sa_solver, euler and dpmpp_2m. seed fixes the noise so you can compare one variable at a time.
width / height (1024×576), force_rate, frame_load_cap set how the source is read; leaving frame_load_cap at 0 loads everything, which is how people OOM on a long clip. tile_batch_size (8) is the VAE decode batch - drop it when the decode is what runs out of memory, not the sampler.
One output, status, a STRING. The node is also marked as an output node, so it executes when you queue - it does nothing, prints nothing, and exists only to give the JS somewhere to live. Don't wire it into anything and expect behaviour.
Install
Manager → search vrgamedev, or:
cd ComfyUI/custom_nodes
git clone https://github.com/vrgamegirl19/comfyui-vrgamedevgirl.git
python -m pip install -r comfyui-vrgamedevgirl/requirements.txt
Restart and hard-refresh the browser (Ctrl+Shift+R). This is the node where that advice actually bites: the Python side registers fine and the button never appears, because your browser is still running the cached JS from before the install.
When it goes wrong
- No "Open H3 Settings" button. Cached JS. Hard refresh. If it's still missing, check the browser console - this extension only attaches to nodes whose class is exactly
VRGDGMiniMaxUpscalerControlPanel. - Settings don't take effect. You edited the modal but didn't hit Apply & Close, or your workflow uses different node classes than the ones it targets. The counts in the status line tell you which.
- The wrong node got your steps value. Two schedulers in the graph; it took the first. Rename your nodes or edit that widget directly.
- It's slow or memory-murders on a long clip. Window size and
tile_batch_sizeare the two dials, in that order. This is the general shape of video upscaling: tiling and windowing are far slower but use a fraction of the VRAM, and the difference is steep.
Worth saying plainly: this node is convenience, not capability. Everything it does you can do by hand in five minutes. It exists because in a workflow with this many knobs, "the settings that matter, in one place" is a real feature - and because the panel doubles as the uploader for the video you're about to upscale.
Inputs (16)
| Name | Type | Default | Description |
|---|---|---|---|
| video_path | STRING | — | |
| video_mode | COMBO | 3 options: remix, replace, enhance | |
| video_denoise | FLOAT | 0.200–1 | — |
| overlap_preset | COMBO | 3 options: H3 Near 41 (39 / 5), H3 Balanced (73 / 17), H3 Trained (124 / 22) | |
| custom_window | INT | 735–10000 | — |
| custom_overlap | INT | 171–5000 | — |
| blend_mode | COMBO | 3 options: cosine, smoothstep, linear | |
| steps | INT | 51–100 | — |
| sampler_denoise | FLOAT | 0.200–1 | — |
| sampler | COMBO | 3 options: sa_solver, euler, dpmpp_2m | |
| seed | INT | 10–9223372036854776000 | — |
| width | INT | 10240–16384 | — |
| height | INT | 5760–16384 | — |
| force_rate | FLOAT | 00–120 | — |
| frame_load_cap | INT | 00–10000000 | — |
| tile_batch_size | INT | 81–256 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| status | STRING | — |