Sigmas RiemannianFlow

In flat, ordinary (Euclidean) space, the distance between two points is just the straight line between them. Curved spaces don't work that way - in hyperbolic space, distances stretch out as you move toward the edge; in spherical space, they compress; lorentzian geometry is the kind used in relativity, where space and time don't behave symmetrically. All four are real, established notions of geometry, and this node uses whichever one you pick to decide how the steps of a sigma schedule are spaced between a high and a low value - instead of a linear or Karras-style spacing, you get the pacing that metric's notion of "distance" implies.

Like Sigmas NormalizingFlows, PersistentHomology, and ZetaEta, this is a generator built purely for curve-shape exploration, not a documented technique with a known-good setting. Treat euclidean as your sanity-check baseline - it should behave the most like an ordinary, unremarkable schedule - and treat the other three as places to go looking for a specific, unusual pacing you can't get any other way.

The inputs and outputs that matter

steps sets the output length. metric_type picks the geometry - euclidean, hyperbolic, spherical, or lorentzian. curvature (default 1, range 0.1–10) controls how extreme that geometry's effect is; higher curvature means a more pronounced bend away from ordinary spacing. start_value and end_value set the schedule's high and low bounds, the same role max/min sigma plays anywhere else. All five are required, since this generates a schedule from parameters alone. One output: SIGMAS.

It's worth sitting with what "hyperbolic" versus "spherical" pacing actually implies before you reach for either. Hyperbolic geometry stretches distances as you move outward, so a hyperbolic schedule likely spends relatively more of its steps at the extremes (very high or very low noise) and less in the middle. Spherical geometry compresses distances toward its "equator," which would push the opposite way - more steps clustered around the midpoint of the range. Lorentzian sits apart from both, since it's built around a signature that treats one direction differently from the rest, which is the geometry most likely to produce a genuinely asymmetric pacing between the start and end of your schedule.

Installing it

ComfyUI Manager: search RES4LYF, install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/ClownsharkBatwing/RES4LYF/
cd RES4LYF
pip install -r requirements.txt

Portable ComfyUI users should point that at the embedded pip.exe. Restart and hard-refresh afterward.

Where people get tripped up

curvature is the parameter most worth being deliberate about - at low values every metric_type looks fairly similar to euclidean, and the differences only really show up as you push it toward the top of its range. If you switch metric_type and see basically no change, turn curvature up before concluding the setting does nothing.

Beyond that, this shares the same caveat as the rest of RES4LYF's generator family: there's no community track record to lean on, so check the actual output shape (a plot or preview node) before wiring it into a real generation, and compare against a plain scheduler so you can tell what the geometry actually bought you.