Convert Float To Int [LP]

Of the conversion family in this pack, this is one of the genuinely useful ones - not because the type coercion is complicated, but because it actually gives you a choice in how the rounding happens, which matters more than you'd expect once you're doing real math on dimensions or counts inside a workflow.

Why the rounding mode matters

Say you're computing an image dimension from a scale factor, or turning a calculated ratio into a step count. FLOAT outputs from math nodes rarely land on a clean whole number - you get 1023.7 when you wanted 1024, or 7.4 steps when you need an integer step count. Just truncating isn't always right: sometimes you want the nearest whole number, sometimes you specifically need to round down (so you never generate a dimension one pixel over a size limit), and sometimes you need to round up (so you never end up one pixel short of a multiple-of-8 requirement). This node gives you all three explicitly instead of picking one silently.

The inputs and outputs that matter

• float - the value to convert, default 0, with an effectively unbounded range so it won't clamp normal values.
• round_integer - a three-way choice: round (nearest, standard rounding), round down (floor), round up (ceiling).
• Output - a single INT.

How to install it

ComfyUI Manager: search "ComfyUI Level Pixel" or ComfyUI-LevelPixel, install, restart - auto-updates through Manager's "Update ALL." Manual:

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

Restart ComfyUI. No models, no extra dependencies.

Common issues & troubleshooting

Values at exactly .5 don't round the way you expect. Python's built-in round() uses "round half to even" (banker's rounding), not the "always round .5 up" behavior you probably learned in school - 2.5 rounds to 2, 3.5 rounds to 4. If your counts feel intermittently off by one, specifically at values landing on a clean half, this is almost certainly why. Switch the mode to round down or round up explicitly if you need deterministic, predictable behavior rather than whatever the nearest-even rule happens to produce.

You need a dimension that's always a safe multiple of 8 (or 16, or 64). This node alone won't guarantee that - it only rounds to the nearest whole number, it doesn't snap to a multiple. Combine it with your own multiply/divide math beforehand (divide by 8, round, multiply by 8 again) if that's the actual goal.

Downstream node still complains about the type. Double-check you're wiring the INT output into something that genuinely wants INT and not, say, a COMBO-typed field - this node only handles the FLOAT-to-INT conversion, not the wildcard-type tricks that StringToCombo-LP handles.