GodnessMerger_MiddleBlock
Merging the U-Net's bottleneck on purpose
- GM_MIDDLE_BLOCK
GodnessMerger_MiddleBlock is one piece of SP-Nodes' modular "Godness Merger" system - the pack's own controlled-randomization approach to checkpoint merging. On its own it doesn't touch a model at all; it just decides what merge ratio to use for one specific chunk of a U-Net, and hands that number off to a combiner node elsewhere in the pack (not covered in this batch, so I won't pretend to know its exact wiring - just that a GM_MIDDLE_BLOCK value has to end up there to matter).
Why the middle block gets its own node
The Godness Merger family mirrors the actual sub-module names in the classic Stable Diffusion U-Net: time_embed, label_emb, middle_block, output_blocks, out. The middle block sits at the very bottom of the U-Net's hourglass - the lowest-resolution, most compressed representation, after the encoder has downsampled all the way in and before the decoder starts upsampling back out. It's a small fraction of the model's total parameters, but it carries an outsized amount of the model's "big picture" decisions - overall composition, pose, and anatomy tend to trace back here more than to the fine-detail layers near the edges of the network. That's exactly why merge tools like this single it out for its own dial instead of lumping it into one global ratio.
What it actually does
Give it a seed, a min/max range, a type (custom or random), and a custom_value. Set type to custom and it just returns custom_value untouched. Set it to random and it draws a number between min and max, deterministically seeded - run it twice with the same seed and you get the same ratio both times. That number comes out typed as GM_MIDDLE_BLOCK. It's a scalar with a label, nothing more.
The knobs worth touching
type-customfor a ratio you pick by hand,randomfor a reproducible roll.min/max- bounds for the random draw (0–1). Because the middle block punches above its parameter-count weight, even a narrow range here can shift composition noticeably once it reaches the merge.custom_value- only read incustommode.seed- the thing that makes "random" not actually random when you need to reproduce a good result.
Installing it
ComfyUI Manager: search "SP-Nodes," install, restart. Manual clone:
cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes
Restart after. This node is plain tensor-ratio bookkeeping - no model download, no extra pip install beyond what ComfyUI already ships with.
Common gotchas
Fresh install of a workflow that references this node without the pack installed gets you ComfyUI's usual red "missing node" box - install SP-Nodes via Manager (or its "install missing custom nodes" button), restart, done.
Beyond that, the mistake to watch for is architecture mismatch further down the pipeline: whatever combiner node eventually takes your two source checkpoints along with this ratio, they need to be the same base architecture (both SD1.5, or both SDXL). Merging across families isn't something ratio tuning can fix - you'll get a broken model or an outright error regardless of how carefully you pick this number. And if you're chasing a specific look through "random" mode, write down the seed (and ideally the resulting VALUES/RATIO_VALUES string from whatever node actually performs the merge) the moment you land on something you like - nothing about the U-Net-block naming is dramatic, but a good random middle-block ratio is genuinely hard to stumble back into by accident.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| 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_MIDDLE_BLOCK | GM_MIDDLE_BLOCK | — |