Hello,
We our PCG workflow to allow multiple machines to generate separate regions of the world in parallel. This approach significantly speeds up generation and improves fault isolation: if a machine fails, only its corresponding area is affected.
While testing this setup, we observed an issue with the PCGWorldBuilder commandlet when configured to generate only the local cell. In some cases, the process still creates partitioned PCG actors whose bounds lie partially or entirely outside the cell being processed.Although these actors are created successfully, they do not contain any generated content. They exist as empty containers located outside the expected generation area. This behavior doesn’t appear to cause immediate runtime errors, but it has several negative side effects:
- It breaks the assumption that local-cell generation is fully self-contained.
- In our distributed workflow, it can lead to concurrency conflicts when two machines attempt to create or update the same partitioned actor file.
Our investigation suggests that the issue may stem from how ActorAndComponentMapping and UPCGSubsystem::ForAllOverlappingCells determine which partitioned actors belong to the current cell.
To prevent unwanted side effects in our workflow, we plan to apply the following mitigations:
- Revert out-of-cell actors after generation — Since each machine knows its area of responsibility, we can detect and revert any partitioned actors whose bounds lie outside that region.
- Tighten overlap bounds in ForAllOverlappingCells — By slightly reducing the evaluated bounds, we can restrict the search to strictly local content.
It would likely make sense to adjust the logic so that ActorAndComponentMapping does not return or create a partitioned actor unless the current cell fully contains that actor’s bounds. This would ensure that no partitioned actor is created or modified outside the current cell’s area, which aligns with the expected behavior for local generation and would also prevent the creation of empty, out-of-bounds actors.
We didn’t test it at runtime, but we suspect the same behavior will likely occur.