Nodes/SP-Nodes/GodnessMerger_InputBlocksExperimental
ComfyUI Node

GodnessMerger_InputBlocksExperimental

The input-blocks config, now model-aware

By bananasss00·Created 2 years ago·Updated 6 days ago· 20
GodnessMerger_InputBlocksExperimental
  • model
  • GM_INPUT_BLOCKS
seed0
min0.0
max1.0
type
custom_value1.00

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 feed GodnessMerger_Apply, wiring in one of the same two models you're actually merging (model1 or model2 from 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 standard GodnessMerger_InputBlocks node.
  • 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.

CategorySP-Nodes/model_merging

Inputs (6)

NameTypeDefaultDescription
modelMODEL
seedINT00–18446744073709550000
minFLOAT0.00–1
maxFLOAT1.00–1
typeCOMBO2 options: custom, random
custom_valueFLOAT1.000–1

Outputs (1)

NameTypeDescription
GM_INPUT_BLOCKSGM_INPUT_BLOCKS