⬡ Polyhedron Sigma List

Every sampler hands you a scheduler dropdown - normal, karras, beta, sgm_uniform - and for a while that's fine. Then you download a distilled recipe and it doesn't say "use karras". It says sigma = 1.0, 0.75, 0.5, 0.25, 0.0 and tells you the author measured that. A distilled few-step model is trained on a specific noise trajectory; the grid is part of the recipe, in the same category as the LoRA weight and the CFG. Hand that to a scheduler that reshapes the curve and your 4-step Wan Lightning run looks nothing like the showcase.

⬡ Polyhedron Sigma List is the escape hatch: type the grid in, wire it straight into the sampler's SIGMAS input, and stop letting a name on a dropdown decide your trajectory.

Why anyone needs this

The flow-matching architectures that took over - Flux, Wan, Z-Image, the 2026 video models - straighten the denoising trajectory, which collapsed step counts and made aggressive schedulers actively harmful: Karras concentrates effort mid-run, a correction on a curved DDPM trajectory and a distortion on a straight one. Around the same time a second knob appeared: shift, the exponential timestep shift that moves effort between composition and detail. It's roughly the flow-matching replacement for choosing a scheduler, and it's model-specific - Z-Image Turbo wants 7 where ComfyUI defaults to 3, MiniMax H3 video wants 12. Published grids are usually raw, meaning unshifted, and the recipe expects that shift applied. Paste raw, set shift, done - instead of pasting pre-multiplied numbers, which is where digits get lost.

The four inputs

sigmas_text is the grid: highest first, strictly decreasing, and separators are free - commas, semicolons, spaces and newlines in any mix, so a list copied out of a paper, a README or a metadata header goes in verbatim. The parser is deliberately loose, because splitting strictly on ", " turns a missing space into a crash.

shift applies the flow-matching exponential shift s·x / (1 + (s-1)·x) to the whole grid. 1.0 is off, for grids that arrive already shifted. Use 12.0 for MiniMax H3 video, 5.0 for Wan 2.2 Lightning. It's only defined on a normalised grid: if any value is above 1.0 the node refuses, because a k-diffusion range (gaussians topping out near 14.6) isn't on that scale.

enforce_terminal_zero appends a final 0.0 when your list doesn't end at zero. Samplers expect the grid to reach zero; this is the "why is my last step grey mush" switch, and it defaults on. Leave it.

preset is a small table of published grids the author measured once and shipped so nobody retypes them: custom, hyperflow_8step_h3_raw (HyperFlow 8-step for MiniMax H3, shift 12.0, euler, CFG 1.0), wan22_lightning_4step_raw (lightx2v's list at shift 5.0, reproducing their published workflow to 1e-7, split across the HIGH/LOW experts), and three Align-Your-Steps grids for SD 1.5, SDXL and SVD at shift 1.0.

Here's the trap: anything but custom wins over the text field, shift and enforce_terminal_zero. A preset carries the whole recipe. Picking one and then setting shift by hand looks applied while running the wrong curve - the author says that's exactly what bit users the day presets shipped. The node now writes the preset's values into the widgets and greys them out, and the console names every value it replaced. Want your own grid back? Set preset to custom.

The two outputs

sigmas (SIGMAS) goes into a sampler that takes a sigma input rather than a scheduler name - the pack's own Polyhedron Sampler, or core's SamplerCustom. That's the whole point: you're replacing the scheduler, not tuning it.

steps is the step count the grid implies - points minus one, so nine values means eight steps. Your step-count widget and your actual grid can't disagree, which matters on Wan 2.2 where the two experts split the run.

Installing it

It's part of the Polyhedron Suite, one install for the whole pack:

cd ComfyUI/custom_nodes
git clone https://github.com/PolyhedronAI/ComfyUI-PolyhedronLoRAStack.git
# restart ComfyUI

Or in ComfyUI Manager, search "Polyhedron Suite". Dependencies: none - nothing here needs Pillow, requests, av or opencv, so it loads on whatever ComfyUI you already have. Newer builds load it as a V3 (comfy_api) node; older ones fall back to the legacy class with identical inputs, defaults and results.

When it refuses to run

This node fails loudly by design - the author's framing is that a typo should be the run's own refusal rather than a silently deformed generation:

• "need at least two values (a grid of N steps has N+1 points)." You pasted a single number or an empty field. Nine values, eight steps.
• "values must be strictly decreasing - position 3 (...) is not below position 2 (...)." Two values out of order, or a duplicate. Usually a grid typed from a screenshot where a 0.7 became 0.17, or something non-numeric mixed in - the message names the token.
• "shift only applies to a normalised grid." You left shift above 1.0 while pasting a k-diffusion range like the Align-Your-Steps SD 1.5 list. Set shift to 1.0; those grids are already in the right units.
• "but shift does nothing on my old workflow." Check whether your scheduler applies its own sigma shift and ignores the workflow's; some do, bong_tangent among them, and that confusion predates this pack. Here the console line names the shift actually used.