LC²H | Lost Cities: Multithreaded

The Lost Cities, rebuilt to actually scale.

LC²H doesn't just slap more threads onto The Lost Cities and call it optimized. It reworks some of its heaviest worldgen algorithms and execution paths around faster computation, parallel planning, reusable data, safer async generation and optional GPU compute.

Current architecture: V4.2.2-LTS

Where does the speed come from?

A lot of "multithreaded worldgen" still runs basically the same expensive algorithms, just on several workers instead of one.

That can help, but it also means more synchronization, more contention and several threads potentially calculating the exact same thing.

LC²H V4 was designed around concurrency from the start.

The important bit: LC²H isn't fast because the thread count got bigger. The work each thread has to perform got cheaper.

The raw numbers

These are focused measurements from optimized LC²H V4 hot paths. They are not some fake "your entire world is now 28x faster" claim xd.

Up to 28.16x faster in measured V4 hot paths.

Actual chunk generation obviously depends on way more than LC²H. Your CPU, terrain generator, structures, lighting, disk, view distance, Distant Horizons and every other mod on the machine still exist :DDD

What these results show is that the underlying Lost Cities work itself can become dramatically cheaper.

That also lines up with real usage. Across the V4 testing cycle we've had users and modpack developers report exceptional worldgen improvements, especially in city-heavy setups where Lost Cities previously produced large stalls.

Async without turning Minecraft into a race condition

There's a pretty important difference between calculating what should happen and actually changing the Minecraft world.

Scanning terrain, calculating city data or preparing an immutable structure plan can often happen safely away from the main path. Random worker threads blindly changing live chunks cannot.

LC²H separates those two jobs.

• Workers scan and calculate data.
• Independent planning can happen in parallel.
• Completed results are published as reusable or immutable plans.
• Cross-chunk work keeps track of which chunks it actually owns.
• Sensitive world mutations are passed through controlled apply paths.
• Unavailable async or hardware paths fall back safely.

Do the expensive thinking in parallel. Keep dangerous world changes controlled.

Sounds obvious, but it is also the difference between useful async worldgen and a deadlock/race-condition simulator xd.

Terrain that actually understands the city around it

Cities need fairly stable ground for streets and buildings. Mountains obviously couldn't care less.

A simple city flattening system can therefore produce giant cliffs, sharp chunk borders or terrain which suddenly turns into a wall beside the city.

LC²H V4 uses a much broader terrain system.

It samples Minecraft's own natural terrain height and erosion information, compares that against the surrounding city layout and builds a continuous shift field around the city.

That field is calculated across 32x32 chunk regions with surrounding context rather than making every chunk guess what its neighbour is doing.

And instead of painting fake terrain over Minecraft afterwards, LC²H feeds the calculated shift back into Minecraft's native terrain density path.

In normal words: Minecraft still generates the mountain. LC²H tells that same mountain how it should naturally move toward the city.

Caves, surface layers, grass, snow, stone and the original generator's terrain style can therefore remain part of the transition instead of being replaced with a generic wall of blocks.

Chunks aren't isolated little universes

Minecraft generates in chunks. Cities don't stop existing every 16 blocks.

A building can occupy several chunks, a highway can pass through an entire region and a tree can start in one chunk while half its branches land in another.

LC²H therefore gives several systems knowledge and ownership beyond the currently generating chunk.

• Multichunk buildings can retain their complete footprint.
• Roads, highways and tunnels can make consistent cross-chunk decisions.
• Terrain transitions use surrounding regional information.
• Structures can avoid protected city space.
• Several workers can reuse the same regional planning data.
• Cross-chunk decisions don't randomly change halfway through placement.

That improves performance, but it also fixes an entire category of generation bugs which only really show up once several chunks are being generated at the same time.

And then there are trees...

Trees are somehow one of the most cursed parts of parallel worldgen :]

A tree can begin in one chunk while its trunk, branches and leaves touch several others. If Lost Cities clears one of those chunks while another worker is still placing the tree, congrats, you now have half a trunk and 200 floating leaves.

LC²H V4 has a dedicated deferred tree system for exactly this.

• Cross-chunk tree footprints can be detected before placement.
• Unsafe trees can be captured instead of being partially destroyed.
• The chunks required by that tree are tracked and retained.
• Tree block data is converted into a reusable plan.
• Replay waits until the required chunk window is safe.
• Large trees are split into bounded pieces instead of dumping thousands of writes at once.
• If the window becomes unsafe again, the tree can be retried instead of being half-applied.

The same philosophy applies to vegetation cleanup. Vines, glow lichen, leaves and supported modded vegetation can be cleaned without endlessly rescanning the world.

Because fixing six floating vines by introducing the next worldgen bottleneck would be kinda embarrassing xd.

Fast is useless if it's wrong

Worldgen optimization has one extra problem compared to normal performance work: the optimized path still needs to make the same decisions.

LC²H therefore includes parity and validation work alongside the performance systems.

• Noise parity error remained below 4.1e-16 in verified testing.
• 65,536 city random parity samples completed with zero double mismatches.
• Integer city parity completed with zero mismatches.
• Hardware-computed results are validated before generation trusts them.
• Failed hardware paths can fall back to CPU.
• World and dimension caches are scoped so old generation state cannot leak into another world.

An optimization which gives a bigger benchmark number but generates the wrong world isn't an optimization LC²H should ship.

Compatibility

V4's algorithmic core is shared between its supported platforms rather than maintaining two completely different implementations.

The shared LC²H code handles the major planners, caches, terrain algorithms, tree systems and cleanup logic. The loader-specific layers mainly connect those systems to the relevant Minecraft and loader APIs.

LC²H also contains compatibility handling for:

• Distant Horizons
• C2ME / FastChunkGen-style async chunk generation
• Quantified API
• Modded terrain generators
• Modded structures
• Cross-chunk worldgen features
• Large modpacks

Obviously LC²H cannot optimize every other mod in your pack. A 400-mod setup with custom terrain, giant structures and several async generation systems will behave differently from Lost Cities by itself.

Legacy or modern Lost Cities layouts

Modern Lost Cities versions introduced the newer Hierarchical Grid street planner, but not every existing profile was designed around it.

LC²H therefore keeps support for both approaches.

• Hierarchical Grid uses the newer Lost Cities street planning system.
• Legacy retains the older city and road layout behaviour.
• The mode can be selected through LC²H's config.
• Older custom profiles don't need to completely change their city layout just because LC²H was updated.

Config, diagnostics and benchmarking

LC²H includes an in-game configuration interface for its major systems instead of expecting everyone to edit files manually.

The V4 tooling also exposes diagnostics for things such as terrain-field readiness, generation decisions, cache behaviour and why particular work was deferred or rejected.

And because performance on your machine matters more than a screenshot from mine, LC²H also includes an integrated benchmark.

• Chunks loaded
• Effective CPM
• Average and minimum TPS
• Tick timing
• Freeze count
• Hardware information
• Final benchmark score

Same world. Same pack. Same machine. Then compare.

A clean Lost Cities test world versus a 400-mod pack isn't exactly science lmao.

Why V4 became what it is

LC²H originally started much simpler: make Lost Cities more multithreaded and stop cities from destroying worldgen performance.

V2 and V3 proved that a LOT of the work could be moved, cached and reused more efficiently, but they were still fighting against assumptions inherited from the original serial generation path.

Eventually patching around that architecture stopped making sense.

V4 rebuilt the important parts around scoped state, regional planning, immutable data, cross-chunk ownership, bounded caches, safer concurrency and actual profiling.

That's the difference between LC²H today and "Lost Cities but with some async hooks."

And yh, getting there produced some cursed shit. Deadlocks, chopped trees, floating leaves, missing roofs, giant terrain walls, disappearing structures, caches surviving into another world and basically every possible way worldgen can remind you that chunks don't exist in isolation :DDD

But that's also why V4 has been tested through real modpacks and real concurrency rather than being designed around one perfect benchmark environment.

LC²H V4.2.0-LTS is the architecture future LC²H development continues from.

LC²H V4.2.0-LTS | Lost Cities: Multithreaded | BlackRift Studios :]