#οΈβ£ Logic Switch
Compare two values and branch your workflow
- input_true
- input_false
- a
- b
- output
This is an if/else for your graph. It compares two values with an operator you choose, and passes through one of two inputs depending on whether the comparison is true or false. That's it - but "that's it" is deceptively powerful, because branching is what turns a static workflow into one that reacts. Image wider than 1000px? Take the upscale path. Prompt contains "portrait"? Use the face-detail branch. This node is the fork in the road.
If you've used rgthree's or Impact Pack's switch nodes you know the shape. SDVN's version bundles the comparison and the branch into one node: you don't wire a separate boolean into a switch, you give it a, b, and an operator and it decides.
How it works
You feed it two values to compare (a and b), two values to choose between (input_true and input_false), and a logic operator. It evaluates a <operator> b; if that's true it outputs input_true, otherwise input_false. Everything's a wildcard type, so the branch values can be anything - images, latents, models, strings, numbers - and the node just routes whichever one wins.
The eight operators cover the usual comparisons plus membership:
a = b,a != b- equality and inequalitya > b,a < b,a >= b,a <= b- numeric orderinga in b,a not in b- membership/substring (isacontained inb)
That last pair is the handy one for text: "portrait" in prompt lets you branch on what a prompt says.
The inputs that matter
- a and b - the two values being compared. For the ordering operators they should be numbers; for
in/not in,bis usually the container (a string or list) andathe thing you're looking for. - logic - which of the eight comparisons to run.
- input_true - passed through when the comparison is true.
- input_false - passed through when it's false.
The single output is output (wildcard) - the selected value, wired wherever the branch needs to go.
Common issues
The comparison is always false (or always true). Type mismatch. Comparing a number against a string that looks like a number (5 vs "5") can behave unexpectedly, and >/< on non-numeric values won't do what you hope. Make sure a and b are the same kind of thing; run them through a type-conversion node first if needed.
in isn't matching. Check the order - a in b asks "is a inside b," so for substring checks a is the needle and b is the haystack. Swapping them is the usual mistake.
Both branches seem to execute. ComfyUI evaluates the graph that feeds both inputs regardless of which one is selected - the switch chooses the output, it doesn't prune upstream computation. If an unused branch is expensive, gate it earlier rather than relying on this node to skip the work.
Installing SDVN_Comfy_node
ComfyUI Manager: search "SDVN_Comfy_node" β install β restart. Manual:
cd ComfyUI/custom_nodes
git clone https://github.com/StableDiffusionVN/SDVN_Comfy_node
Then pip install -r custom_nodes/SDVN_Comfy_node/requirements.txt from the ComfyUI root and restart. The pack has related flow nodes - plain Switch, Boolean, Auto Switch - worth a look if you're building automated graphs. This node is under π SDVN / π‘ Creative.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| input_true | * | β | |
| input_false | * | β | |
| a | * | β | |
| b | * | β | |
| logic | COMBO | 8 options: a = b, a != b, a > b, a < b, a >= b, a <= b, +2 |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| output | * | β |