5.7 PCG Rendering Questions

Development Pipeline & Plugins
, ,
1

Hi, we have a number of questions related to PCG & Rendering as it applies to Unreal 5.7 and are looking to get some clarity.

---------------------

PCG Landscape Cache – intent and future direction

What are the intended use cases for the different PCG Landscape Cache modes?

  • Does Never Serialize imply the cache is expected to be generated on the fly?
  • With Serialize, the cache does not appear to be built automatically unless Build Landscape Cache is explicitly called — is that expected?
  • Is the cache ever built implicitly during PCG execution?

More generally, how is the landscape cache intended to fit into PCG workflows, and is it something teams should rely on long term? We recall prior discussion about potentially reworking or removing it. Given that RVTs are often already available for landscape data, is relying on RVTs the preferred direction going forward?

---------------------

HiGen grid sizes hard-coded at the top-level graph

HiGen grid sizes appear to be defined at the top-level PCG graph.

We have multiple world scales and would like to reuse the same graphs, but currently need duplicate top-level graphs with different grid sizes that call the same subgraphs.

  • Is there a recommended workflow for reusing graphs across different scales?
  • Can grid size be controlled at the component or instance level rather than being baked into the graph?
  • Or is duplicating top-level graphs currently the intended approach?

---------------------

PCG execution model – synchronous execution

Is it possible to execute a PCG graph synchronously (blocking until completion)?

  • If so, what APIs or patterns are recommended?
  • Are there limitations compared to normal asynchronous execution?

---------------------

PCG components and volume requirements

Does a PCG component fundamentally require a volume to execute?

  • Can a PCG graph designed to operate in an unbounded or global way run without any volume?
  • If not, what is the intended pattern for non-spatial or effectively infinite PCG logic?

---------------------

Standalone PCG graphs and code-driven execution

Can Standalone PCG Graphs be executed purely via code (e.g. during a build step) to operate on content in a loaded map, without requiring a PCG actor placed in the level?

  • Are they suitable for “fire-and-forget” generation in a map?
  • Or are they primarily intended for workflows where no map is loaded?

---------------------

GPU PCG nodes executing with empty inputs

CPU PCG nodes typically auto-cull when no data is connected to their main input pin. GPU nodes, however, seem to execute regardless, and will error when expected attributes or buffers are missing.

  • Is this difference in behavior intentional?
  • Is there a way to early-out GPU node execution when input data is empty?
  • Are there plans to make GPU and CPU node execution semantics more consistent?

---------------------

WaitForLandscape node stalling in PCG commandlets

Using the WaitForLandscape node appears to stall PCG execution when running via PCGWorldBuilderCommandlet (observed in 5.6, not tested in 5.7 yet).

  • Is WaitForLandscape expected to function in commandlet contexts?
  • If not, is there guidance on which PCG nodes are safe to use in commandlets versus editor/runtime-only workflows?

[Attachment Removed]

2

Hi Tim!

Thanks for reaching out, appreciate the curiosity here!

We’ll answer in a few messages as I might pull in other people from the team.

[Attachment Removed]

3

PCG Landscape Cache – intent and future direction

Preamble:

The PCG landscape cache is a bit of a crutch we have done early during development because landscape does not keep the layer data in cooked runtime data.

It replicates the stored layer data of the landscape so we can use it at runtime.

Ergo:

  • it is not super efficient storage wise
  • if you don’t need it, you shouldn’t use it (hence why the default is ‘Never Serialize’)

Interesting tidbits:

  • Projecting on the PCG landscape data requires the cache (e.g. using the landscape on a surface sampler), even if there’s no layer data because we still use the position + normal information. We probably could do a special case that doesn’t rely on it if it’s not available, but it’s not been a request so far.
  • Testing for existence (“sampling” in pcg parlance) uses the physics only and doesn’t rely on the cache

Question*: What are the intended use cases for the different PCG Landscape Cache modes?*

  • Does Never Serialize imply the cache is expected to be generated on the fly?
  • With Serialize, the cache does not appear to be built automatically unless Build Landscape Cache is explicitly called — is that expected?
  • Is the cache ever built implicitly during PCG execution?

More generally, how is the landscape cache intended to fit into PCG workflows, and is it something teams should rely on long term? We recall prior discussion about potentially reworking or removing it. Given that RVTs are often already available for landscape data, is relying on RVTs the preferred direction going forward?

The landscape cache modes are the following, and reflect on the behavior of the serialization of the cache, which is a lot more important for a cooked use case than in the editor:

  • Serialize Only At Cook
    • Builds the full cache when cooking the landscape on a per-proxy basis, which is good if you’re using it.
    • No overhead in the editor (doesn’t bloat the PCG world actor)
  • Never Serialize
    • Default setting
    • Disallows projecting on landscape data at runtime (except through RVT)
    • Does not copy anything
  • Always Serialize
    • Allows some amount of control on what’s serialized to the cache (and that would be cooked too).
    • Automatically populated entries (because of generation) will be serialized.
    • Not a very common use case, but can be helpful to debug cache things.

In practice, if you’re using landscape data as-is in editor use cases only, you never need to change from the default value of Never Serialize - basically we’ll populate the landscape cache as it’s needed, but it can be done only in the editor.

It’s a bit more subtle when you do generation at runtime:

  • Either you serialize the landscape cache OR
  • You use another sampling method (such as world ray hit or world raycast) which won’t have the landscape layer data OR
  • You use RVT on the landscape data (gpu) OR
  • You get the height & grass maps (gpu).

There are some issues with RVT (namely making sure it’s properly loaded) that aren’t trivial per se, so we’re currently more pushing towards use of grass maps, but the gist is that we are moving away from the landscape cache as much as we can and will ultimately deprecate its usage.

[Attachment Removed]

4

PCG execution model – synchronous execution

Is it possible to execute a PCG graph synchronously (blocking until completion)?

  • If so, what APIs or patterns are recommended?
  • Are there limitations compared to normal asynchronous execution?

Unfortunately, there are some cases where we might rely on other engine systems (loading, landscape, …) that might require us to either push events/wait for things to happen so it’s not always possible.

However, you can do something “close enough” in most cases by bumping the PCG frame time to semi-infinite values (e.g. pcg.FrameTime 99999999 or pcg.EditorFrameTime 999999999) that could help in some cases.

[Attachment Removed]

5

PCG components and volume requirements

Does a PCG component fundamentally require a volume to execute?

  • Can a PCG graph designed to operate in an unbounded or global way run without any volume?
  • If not, what is the intended pattern for non-spatial or effectively infinite PCG logic?

No, a PCG component doesn’t need a volume to execute, though it generally is convenient as a good way to provide bounds.

Bounds are also convenient to be spatially-loaded at the right places so you are more likely to be loaded/ the data you depend on to be loaded at the same time.

The PCG component is fully stand-alone and we’ll often use them on an actor with just a spline component, for example - but again, the presence on data on the same actor is convenient, and not any kind of hard requirement. You can always get data from anywhere in the world.

So yes, you can easily do actor + pcg component and run in a global way easily - however, if you want to partition your processing, you need bounds.

Also, “infinite” might not always be super convenient because for larger projects, it’s unlikely that you’d load the whole world in memory, so any kind of large scale processing will be a bit more complicated.

Let me know if this isn’t clear, I understand it’s a bit vague!

[Attachment Removed]

6

Standalone PCG graphs and code-driven execution

Can Standalone PCG Graphs be executed purely via code (e.g. during a build step) to operate on content in a loaded map, without requiring a PCG actor placed in the level?

  • Are they suitable for “fire-and-forget” generation in a map?
  • Or are they primarily intended for workflows where no map is loaded?

Standalone PCG Graphs were added to support non-world related workflows. Ex: Generating assets.

I would suggest using Editor only actors to do some in map generation while outputting the result on a different target if it needs to persist outside of editor worlds (Create Target Actor node)

[Attachment Removed]

7

WaitForLandscape node stalling in PCG commandlets

Using the WaitForLandscape node appears to stall PCG execution when running via PCGWorldBuilderCommandlet (observed in 5.6, not tested in 5.7 yet).

  • Is WaitForLandscape expected to function in commandlet contexts?
  • If not, is there guidance on which PCG nodes are safe to use in commandlets versus editor/runtime-only workflows?

I will comeback to you on this one. Will need to repro first.

[Attachment Removed]