📐 Outpaint Direction Selector (Primitive)

If you searched the node menu for "Primitive" hoping for something like the core primitive nodes, this isn't it. PrimitiveCombo is the pack's direction selector registered a second time under a different key. Same Python class, same widgets, same outputs, same behaviour. The only difference is the display title: 📐 Outpaint Direction Selector (Primitive) instead of 📐 Outpaint Direction Selector.

You can verify that in one glance at the pack's __init__.py, where NODE_CLASS_MAPPINGS points both "OutpaintDirectionSelector" and "PrimitiveCombo" at OutpaintDirectionSelector. It's a 20-line class that returns its own inputs unchanged. There is no second implementation hiding behind the second name, so nothing about the "(Primitive)" version is faster, safer, or more capable.

So is it useless?

No, but the value is small and specific. Aliases like this exist for two reasons.

The first is compatibility. A shared workflow, a template, or a downstream pack can reference a node by its mapping key, and if that key is missing you get the red "missing node" outline instead of your graph. Registering an extra key means a graph that says PrimitiveCombo loads into the pack instead of erroring. You see this pattern all over the ecosystem - it's the same reason half the packs you install have an entry for a node they renamed two versions ago.

The second is legibility. Two instances of the identical node in one graph genuinely look like a mistake when you come back to the workflow a week later; two instances under two names at least read as two deliberate choices. That's a cosmetic benefit, and copy-pasting the original node also works, so call it a preference rather than a feature.

The genuinely confusing part is the name. In ComfyUI, "primitive" means a value source that mints a value from nothing: core ships typed PrimitiveInt, PrimitiveFloat, PrimitiveString, PrimitiveStringMultiline and PrimitiveBoundingBox, plus the older polymorphic Primitive that adopts whatever type you plug it into. Those all stand on their own with no input. This node has a required direction input like any other node - the "(Primitive)" suffix is just a label the author liked, presumably because it emits a bare string and float rather than pixels. Don't read it as a type claim.

Inputs and outputs

Identical to the selector, which is the point:

direction (required) - the same four options: center (50/50 both sides), bottom (outpaint TOP only / cielo), top (outpaint BOTTOM only / suelo), custom_vertical_bias (0.0=bottom, 1.0=top). Still no left/right, so watch it if the rest of your workflow assumes you can pick horizontal expansion from this node.

custom_bias (optional) - FLOAT 0.0–1.0, step 0.05, default 0.5, meaningful only for the custom_vertical_bias split, where it's the share of the leftover height placed above the source.

Outputs: direction typed * (the ANY wildcard) and custom_bias as FLOAT.

Same usage notes as its twin, then. Convert the pad node's direction widget to an input before wiring, and remember that the string travelling down that wire is matched by startswith downstream - a value starting with bottom, top, left, right or custom is honoured, and anything else quietly falls back to centred padding.

Install

Both keys come from the same pack, so there is nothing extra to do. ComfyUI Manager → search ComfyUI-OutpaintDirectional → Install → restart. Or, the one-liner:

cd ComfyUI/custom_nodes
git clone https://github.com/hyukudan/ComfyUI-OutpaintDirectional.git

One 200-line Python file, MIT, torch only, no weights to download.

Troubleshooting

"I don't see PrimitiveCombo in the node search." Search the display name instead of the class name - the menu shows 📐 Outpaint Direction Selector (Primitive). If it's still absent, restart ComfyUI; a stale process is the usual reason a newly cloned pack half-loads.

"The README only lists two nodes." The README's included-nodes table skips PrimitiveCombo entirely - it documents OutpaintDirectionSelector and OutpaintDirectionalPad and leaves the alias unmentioned. The code registers three keys. Trust the code.

"Do I need both nodes in a workflow?" No. Pick one name and use it as many times as you want; mixing them buys you nothing except a graph that's mildly harder to read.

The honest summary

A duplicate registration with a misleading name. Use whichever of the two names autocompletes first, ignore the suffix, and if you ever need to know what it does, look at the other three lines of the class. Worth flagging that this pack has essentially zero footprint in the community - no reddit threads, no shared workflows, no author history - so there is no forum consensus to lean on here. Just read the file; it's shorter than this article.