Random Tiling

Everything else in this pack is groundwork: cut boundaries, inpaint interiors, pick winners. This node is where you find out if it worked. Random Tiling takes your finished tile set and lays it down as a big random field - width by height tiles - respecting the Wang or Dual edge-compatibility rules as it goes. One glance at the output and you know whether your edges actually match, whether the set has enough variety to not look repetitive, and whether you'd put this on a wall.

What it does

It picks a random tile placement using the constraints encoded in the tileset: with a Wang set, every tile is chosen so its edges line up with its neighbors; with a dual set, the interior and cross tiles are placed on an offset grid and composited through the same diamond mask the boundary nodes produce. The stochastic placement is the point - the same tile set can generate an endless variety of tilings, and a good set looks cohesive no matter the draw. This is also the node that most directly proves the pack's thesis (Sartor & Peers, ACM TOG 2024): diversity in the tile library plus strict edge matching gives you texture you can tile by the room, not by the patch.

Inputs and outputs

• tiles (IMAGE) - your generated tile set (post-RejectCandidateTiles is typical)
• tileset (TILESET, forceInput) - kind, colors, resolution, candidates; required, and it must come from an upstream node
• width (INT, default 20), height (INT, default 20) - the field size in tiles. A 20×20 at 256px per tile is a 5120px image, so it's a real VRAM and decode cost; smaller for preview, bigger for the final check.

Output is a single IMAGE. Wire it to a PreviewImage first, and only SaveImage once you're happy - re-rendering a 20×20 field is cheap to redo, so iterate on a 4×4.

Installing and gotchas

Install is the pack standard: git clone https://github.com/samsartor/content_aware_tiles into ComfyUI/custom_nodes (or ComfyUI Manager → "content_aware_tiles") and restart. No model downloads - this node is pure tensor math on the tiles you already made.

The one error you'll actually hit is the dual-set check: for kind: dual the node requires exactly colors**4 * 2 tiles (the interior set and the cross set). If you only generated half, you get a clear ValueError telling you the expected count. Also: if your tiles came out of a boundary node without enough candidates and you see repetitive patches in the field, the fix is upstream - more candidates in the boundary node, and let RejectCandidateTiles keep the best. Zero community discourse on this pack, so the workflow JSON is your real documentation; but the node is a compact, readable wrapper around the packing code if you ever need to debug it.