GodnessMerger_InputBlocksExperimental
The input-blocks config, now model-aware
- model
- GM_INPUT_BLOCKS
This node is functionally identical to GodnessMerger_InputBlocks on the surface - same seed, min, max, type, custom_value fields, same GM_INPUT_BLOCKS output that wires into GodnessMerger_Apply's input_blocks slot - with exactly one visible difference: it also takes a model input. "Experimental" is the author's own label for it, and to be honest about the limits of what this brief can tell you, the schema doesn't reveal what that extra model input is actually used for internally. A reasonable guess is that the ratio it produces gets computed with some awareness of the model's own weights rather than being purely blind, but that's a guess, not a confirmed behavior - treat it as such.
How it works
Same mechanics as the standard version: type picks custom (a fixed custom_value) or random (a seeded roll between min and max), producing a merge ratio specifically for the input_blocks group of a UNet. The addition here is the required model input, which the plain GodnessMerger_InputBlocks node doesn't have at all.
The inputs and outputs that matter
model- required, unlike the non-experimental version. Given the node exists to feedGodnessMerger_Apply, wiring in one of the same two models you're actually merging (model1ormodel2from that node) is the sensible choice if you're experimenting with this - plugging in an unrelated third model is presumably meaningless for whatever calculation happens internally, though again, the schema doesn't confirm what that calculation is.seed,min,max,type,custom_value- identical to the standardGodnessMerger_InputBlocksnode.- Output:
GM_INPUT_BLOCKS- same target as the standard version.
The take
Given the "Experimental" label and the lack of any further documentation on what the model input changes, I'd start with the plain GodnessMerger_InputBlocks node first and only come back to this one once your merges are already behaving the way you expect and you have a specific reason to try the model-aware variant.
How to install it
Through ComfyUI Manager: search "SP-Nodes," install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes
Restart ComfyUI afterward.
Common issues
Same type-field gotcha as the standard version: custom mode ignores min/max/seed, random mode ignores custom_value, and there's no warning if you've got the "wrong" fields set for your chosen mode. On top of that, since the model input's actual role isn't documented, if results seem inconsistent between runs, try wiring it to one of the two models you're actually merging in GodnessMerger_Apply rather than leaving it disconnected from that context or pointed at something unrelated.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — | |
| seed | INT | 00–18446744073709550000 | — |
| min | FLOAT | 0.00–1 | — |
| max | FLOAT | 1.00–1 | — |
| type | COMBO | 2 options: custom, random | |
| custom_value | FLOAT | 1.000–1 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| GM_INPUT_BLOCKS | GM_INPUT_BLOCKS | — |