Cross-partition coherent generation in PCG with hierarchical runtime generation

Development Programming & Scripting
, ,
1

What’s the recommended pattern in PCG for generating procedural structures whose footprint is larger than a single partition cell, so they span multiple partitions coherently?

My setup: a partitioned PCG graph with hierarchical runtime generation, building a village generator. Village centers come from a custom node that returns all centers globally and deterministically. Because a village can extend across partition boundaries, each partition either sees only its slice (fragmented village) or has to recompute the full layout itself (duplicated work).

The one approach I’ve considered is a bleed query at a coarse tier — each coarse cell computes layouts for centers within its bounds + max structure radius.

It works, but villages near coarse boundaries get computed 2–4x, which is a problem if the layout pass is non-trivial (terrain sampling, constraint checks, iterative placement).

Questions:

  • Is there a PCG-native way for one partition to read data computed by a neighbor partition at the same grid level?
  • For non-trivial layout work that must stay coherent across cell boundaries, what’s the recommended pattern, and what pitfalls (invalidation, streaming, multiplayer determinism) should we watch for?
  • Is there a sample project or Epic example demonstrating this?

[Attachment Removed]

2

Hi Maximilian!

Sorry for the late answer.

Q: Is there a PCG-native way for one partition to read data computed by a neighbor partition at the same grid level?

There isn’t, because it would entail an ordering in generation of things that are ultimately meant to run at the same time.

In this case, I’d suggest you consider at what granularity your things need to exist so you can place them at the right level in the hierarchical generation.

A rule of thumb is that a thing should be in a cell size that’s at least twice as big as the thing itself.

To be clear, this isn’t solving the boundary problems at all, but you can work with abstractions at higher levels so you’re able to take decisions down below and not redo work.

Ex.: you can ‘seed’ your buildings at a very large scale, and give them rough bounds, and then in smaller cells you can reject all points that don’t have their center in the current cell.

Concretely, maybe this is something you could do in your case:

  • Maybe you run neighborhood/lot generation at larger scales (e.g. 512m)
  • Houses (footprints), maybe you can generate at the 128m cell size
  • Spawning houses, etc. maybe you can do at the 32 or 64m cell size.

Q: For non-trivial layout work that must stay coherent across cell boundaries, what’s the recommended pattern, and what pitfalls (invalidation, streaming, multiplayer determinism) should we watch for?

Making sure you work on things that have their center in the current cell is the recommended pattern.

For streaming, there’s a balancing game you need to play to balance generation time vs. runtime performance.

Some things can help though (such as using FastGeo and PCG GPU) to alleviate some of that pressure.

Multiplayer determinism: you might have minor differences based on hardware/platform differences, but nothing that should be significant for static objects of reasonable sizes.

However, for gameplay/dynamic objects, make sure that the actors are properly marked as replicated - note that in this case, the runtime gen will also have to run on the server (though it doesn’t have to generate things you’re not going to need on the server). There are some options to check if you’re on a server as well inside a PCG Graph using the Get Execution Context node.

Q: Is there a sample project or Epic example demonstrating this?

Unfortunately not right now. Hopefully we get there soon!

Let me know if that answers your questions.

Cheers,

Julien

[Attachment Removed]