This script allows seamless tiling to be enabled separately for the X and Y axes.

You know how Automatic1111 has a "Tiling" checkbox that makes every image a seamless texture, and ComfyUI just… doesn't? That's the itch this node exists to scratch. The pitch is in the name: a KSampler where you can enable seamless tiling on the X axis, the Y axis, both, or neither - so a wall texture repeats left-to-right but doesn't do the same top-to-bottom. That's genuinely useful for game textures, sprite tiles, and panoramic strips.

Here's the thing you need to know before you build a workflow around it: the shipped code doesn't actually do the tiling yet. I read the source, and the headline feature isn't wired in.

What it actually does

Seamless tiling in diffusion isn't magic. A1111's checkbox patches the model's convolution layers to use circular padding instead of zero padding, so the left edge of the latent wraps around to the right edge and the sampler thinks the image is a cylinder. ComfyUI has no built-in version of this, so the custom-node ecosystem reimplements it - the canonical example being FlyingFireCo/tiled_ksampler, which ports A1111's approach.

Asymmetric_Tiling_KSampler is a fork of ComfyUI's own advanced sampling loop, with tileX and tileY toggles bolted on. But look inside tile_ksampler(): it calls comfy.sample.sample() directly with no set_model_patch, no circular padding, no touching of the model's convs at all. It's just prepare_noise → sample → decode preview, which is ComfyUI's normal path with a custom progress callback. So flipping tileX to "enable" doesn't change the sampling math - your output won't be seamless, no matter what the toggles say.

What the node does faithfully do:

• If both tileX and tileY are "disable", it falls straight through to ComfyUI's standard common_ksampler. Same results as the built-in KSampler.
• If either is "enable", it runs its own copy of the sampling loop, which produces equivalent output but spams your console with debug junk on every single step - the print_object_info calls print the type and every attribute of step, x0, x, and total_steps. That's not your install being broken, that's the node.

There's also a step_range input that's meant to control which steps tiling is active on (the source comments say "Start tiling from step N" / "Stop tiling after step N"). It's accepted, and then never used. In fact the whole file imports Conv2d, F, and Tensor - and has a commented-out import comfy.model_base - which reads like a promising idea that's still half-built. The pack is one "init" commit, no README, no requirements file. Early days.

The inputs that matter

It's a drop-in KSampler Advanced clone, so the familiar suspects are all there: model, seed, steps, cfg, sampler_name, scheduler, positive, negative, latent_image, denoise. The three that make it this pack and not stock ComfyUI are:

• tileX / tileY - the pitch. "enable"/"disable" per axis. Currently just switches between the two code paths above.
• step_range - the not-yet-hooked-up "tile for steps N through M" knob. Doesn't do anything yet.

The single output is LATENT, which wires into a VAE Decode exactly like any KSampler output. You'd find the node under Alsritter/Sampling in the node menu.

Installing it

There's no README to copy install steps from, but this one needs nothing special - no model downloads, no requirements.txt, and the only imports are ComfyUI core (torch, comfy, nodes, latent_preview). Either way works:

cd ComfyUI/custom_nodes
git clone https://github.com/alsritter/asymmetric-tiling-comfyui

Then restart ComfyUI. Or search "asymmetric-tiling-comfyui" in ComfyUI Manager's install-from-Git tab and hit install.

Should you use it?

Here's my honest take. As a KSampler, it's fine - it's a faithful copy of ComfyUI's own sampler with a SEED widget. As a tiling solution, don't. If you want working seamless textures today, grab FlyingFireCo/tiled_ksampler for the both-axes case, and for x-only wrapping you're better off finding a maintained node whose source shows an actual conv patch. Check back on this pack in a few months - the intent is right, and if the author wires up that conv patch and the step_range, it becomes the node it's pretending to be. Until then, treat tileX and tileY as a promise, not a feature.

Oh, and if you do run it with tiling "enabled," don't panic when your console floods with Attributes and methods: ... lines. That's by design. Annoying, but by design.