Telegram-канал r_unity3d - r/Unity3D: Unsorted - каталог телеграмм

r/Unity3D

12 April 2026 03:02

Unity's Job System (IJobFor.ScheduleParallel). On a 6-core CPU, 6 chunks are solving simultaneously. Cross-chunk conflicts at boundaries happen occasionally, and they're handled cooperatively: uncollapse the conflicting edge cells, reopen that chunk, let it re-solve just that boundary area.

# Wall #3: "Backtracking kills everything"

When WFC hits a contradiction (a cell with zero valid tiles), most approaches either restart the entire grid or pop a single snapshot off a stack. At scale, both of these hurt:

Full restart: you just threw away 100K collapsed cells because of 1 bad choice
Single-step undo: can take hundreds of backtracks to escape a real dead-end

What fixed it: Progressive depth + deferred execution. When a contradiction happens:

1. In-job: try undoing the last 1, 3, 7, or 15 steps (escalating depth based on repeated failures), all inside the Burst-compiled job
2. If that fails: flag it for the next job dispatch. The main thread just writes an integer to a shared array, and the Burst worker handles the heavier restore on the next frame
3. If the backtrack stack is fully exhausted: restart just that one chunk, not the whole grid

I profiled this before and after. Before, backtracking was eating 473ms per frame on large grids (mostly from sequential AC-3 + repropagation running on the main thread). After deferring that work to parallel Burst workers, the main-thread cost dropped to basically nothing.

# Wall #4: "Propagation lookup overhead"

When you collapse a cell, you BFS outward and ask each neighbor: "given what I just placed, what tiles are still valid for you?" This requires looking up compatibility rules.

Most implementations use a dictionary or hashmap: rules[(tileID, direction)] returns the set of compatible tiles. That works fine at small scale. But propagation is the hottest loop in WFC. On a million-cell grid, you're hitting that lookup millions and millions of times during a single generation run.

What fixed it: Pre-computed flat array. At startup, I flatten the hashmap into a plain array indexed by [moduleIdx * 4 + direction]. Array access is a single pointer offset; hashmap access involves hashing, bucket traversal, and potentially collision resolution. I didn't profile the exact per-lookup difference, but after switching, my propagation phase got noticeably faster on the profiler timeline. At the volume of lookups WFC does, even small per-lookup savings compound into real seconds.

# Wall #5: "Too many contradictions in the first place"

Even with great backtracking, contradictions are expensive. The best fix is not having them.

What fixed it: Look-ahead selection. Before committing to a tile, I check: "would placing this tile cause any of my 4 neighbors to have zero valid options?" If yes, skip it and try the next candidate. It's a simple 1-hop look-ahead (not deep search), and it prevents a huge chunk of contradictions for well-designed tilesets.

How much it helps depends heavily on your tileset. Look at the benchmark table above: the 25-tile palette and the 331-tile palette are running on the exact same solver with the exact same optimizations. The 10x speed difference is almost entirely from how often contradictions occur. Simpler, cleaner edge rules = fewer dead ends = look-ahead catches almost everything. Complex tile interactions = more situations where even look-ahead can't prevent a contradiction 2-3 hops away.

# How these work together

None of these optimizations work well in isolation. Multi-step execution without Burst compilation would be slow managed C#. Burst without multi-step would still have a million main-thread round-trips. Chunk parallelism without deferred backtracking would stall every time a chunk contradicts. And all of the above without look-ahead would spend most of their time backtracking. They're force multipliers for each other, which is why the combined result is so much better than any single optimization would explain.

# Things I wish I knew when I started

1. Profile before you optimize. My first