TTools SD3 Resolution Solver

Every model has a native resolution it was trained at, and SD3/SD3.5's is "about a megapixel, in dimensions divisible by 64." The official SD3.5 example workflows lean on 1024x1024, 832x1216, and 1216x832 - all roughly 1MP, all multiples of 64. Push past that and quality degrades: SD3.5L users have documented distortion creeping into the top of frames once you get near 1600px wide. This node is a tiny calculator that keeps you out of that trap. Give it an aspect ratio, it returns a width and height close to 1MP, snapped to multiples of 64.

It's the second half of the TTools pack - same author (toxicwind), same small July 2024 repo, same "simple nodes for my various use cases" energy. It's also the more useful of the two nodes, and the more honest: it's a 20-line function wrapped in a node UI, and it works.

How it works. The math is one line. It computes a scale factor so the target area equals 1,000,000 pixels (sqrt(1e6 / (x*y))), applies it to both dimensions, then floors each down to a multiple of 64. If you asked for Portrait it swaps the two so width ≤ height; Landscape does the opposite. Finally, if the long side exceeds max_long_side, it scales everything down to fit. Feed it 832x1216 and you get 768x1152; 1024x1024 gives you 960x960. Those are exactly the sizes SD3.5's resolution guidance lives in.

The inputs. Five, and only three matter on a normal day:

• x and y - the aspect ratio you want, not a target resolution. Feed in your desired proportions (default 1024x1024).
• format - Portrait or Landscape, for when your ratio is ambiguous or you want to force an orientation.
• max_long_side - the ceiling for the longest edge (default 1280).

Two things to know about the rest. skip_if_mulof64 returns your x/y untouched whenever both are already multiples of 64 - and it only checks that, not whether you're anywhere near 1MP, so a 2048x2048 passes straight through. And the max_long_side clamp is a plain int() rounding, which means when that clamp actually fires the result can stop being a multiple of 64. Both are edge cases, but they're real.

Wiring it up. The node outputs Width and Height as two INTs - exactly what an Empty Latent Image node wants. So the typical graph is this node → Empty Latent Image → KSampler. Nothing else needed; it's a drop-in replacement for hand-typed dimensions whenever you're tuning a workflow for a new aspect ratio.

Don't over-index on the "SD3" in the name. The discrete-ratio constraint loosened across the ecosystem - most current models take anything in a megapixel band with soft degradation instead of broken anatomy - so this works fine as a generic "keep me near a megapixel" sanity node for Flux, Z-Image, and friends. The multiple-of-64 requirement is the part that actually travels; Flux is picky about it too.

Installing it. ComfyUI Manager: search "TTools". Or:

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

Then the pack's install is where it gets weird. The requirements.txt is broken - it lists stdlib modules and a PyPI package that doesn't exist (spacy-lang-en), so pip install -r requirements.txt errors out. The real dependencies, needed because the sibling JSON node uses them, are spacy, emoji, and the spaCy English model:

pip install spacy emoji
python -m spacy download en_core_web_sm

That last step is non-negotiable: the pack loads the spaCy model at import time, so without it ComfyUI throws on startup and neither node loads - including this one, which doesn't use spaCy at all. If you hit an import error, that's your cause. Restart ComfyUI after installing and the solver shows up under utils.

One thing worth saying plainly: if all you need is a resolution that keeps SD3.5 happy, you can type 832x1216 yourself. This node earns its place when you're iterating on aspect ratios - portrait crops, landscape banners, odd proportions - and want the math done for you every time, or when you're building a workflow someone else will reuse. It's small, it's sharp, and it does exactly one thing.