PlayGo Area in World Partition

Development Pipeline & Plugins
, ,
1

This question was created in reference to: [Any solution for PlayGo initial play area with World [Content removed]

After implementing the solution proposed by Matt Peters in the original question, we now face an issue regarding dependency chains.

Some of our assets reference the WorldPartition map directly, implying that when they are (recursively) assigned a Chunk Id via a Primary Asset Label, they also apply it to the World asset, that applies it to its cells, and then to its actors. We then end up with most of our game content inside the PlayGo chunk, which becomes too big. LevelSequences are a notable offender.

I believe most of these dependencies are legit and required, and I don’t see yet how we could circumvent this. What do you think?

Note that this is not the first time we have trouble with LevelSequences referencing the world, and I don’t know yet if there are many other types of assets referencing the world. If they are few, maybe a manual cleanup is doable, but I’m not convinced.

For example (using `AssetRegistry.ManagementPathsPackageDebugName`) :

SetManageReferences is printing out the reference chain that caused ‘/Game/Mesh/SomeMesh’ to be managed

/Game/__ExternalActors__/Map/LVL_World/7/DY/N4E0EJK3UNV8TCVMQQBCG3

/Game/Map/LVL_World

/Game/Sequence/LevelSequenceAsset

[…]

/Game/AssetDirectlyReferencedByMapActor

PrimaryAssetLabel:DA_PlayGo_Initial

[Attachment Removed]

2

Hello!

Do you have data that you can share regarding the composition of the initial chunk and the types\sizes of the contained assets? It would be helpful to have a better understanding of what data you have in there.

The usual way to break an asset dependency chain is to use soft references but that doesn’t help with placed instances. It might be possible to “push” some data from later stages of the game to standalone Levelnstances . This might be simpler than using External Data Layers as discussed in the previous thread. We added a feature called Editor Paths to allow for referencing of LI actor instances from the Persistent world. This feature works with soft references so can help build system that won’t crash when the soft referenced data is not there.

As far of LevelSequence references, I would recommend opening another ticket that would be discussed directly with the owning team. They would have a better idea of what are those references toward the level. I have a feeling they are related to Bindings but I’m unsure if those can be soft refs. I do believe that Dynamic bindings are soft references but I’m not a 100% on this.

Regards,

Martin

[Attachment Removed]

3

I’ll invoke our AssetRegisty and chunking expert here. He should be able to clarify what’s missing.

Martin

[Attachment Removed]

4

Your hackery to block the PlayGo manager from propagating its references to the world’s assets sounds okay. A similar effect is available by the existing priorities feature. Each PrimaryAsset can specify its priority. When propagating the manager reference from a primary asset, we stop the propagation through a secondary asset if that secondary asset has a manager of a higher priority. Setting the PlayGo PrimaryAsset’s priority to a value smaller than the LVL_World’s priority would then block it from picking up the LVL_World. The problem with that solution is that assets referenced by LVL_World that are also referenced through some other chain by the PlayGo primaryasset will then be removed from the PlayGo chunk even though it has a reference to them that you want to keep. Maybe there’s a way we can add a per-manager assets-to-ignore feature that will encapsulate what your hack accomplishes in a more general way.

For the two collections, I believe you are encountering this behavior from the propagation of primary asset references: When a PrimaryAsset has a direct reference to an asset, that asset is marked as managed by the PrimaryAsset (and is therefore put into its chunk) even if there is another manager with a higher priority. Direct references are the assets included in a SetBundleAssets call for the primaryasset, such as ExplicitAssets field on a PrimaryAssetLabel, or any field on a PrimaryAsset that is marked with a UPROPERTY field `meta = (AssetBundles = <NameOfBundle>)`.

The behavior of always marking direct assets as referenced is implemented in UAssetManager::ShouldSetManager.

Are you two collections PrimaryAssets, that directly reference their listed assets? If not then something else is going on. You should be able to debug it by setting instrumented breakpoints on the assets of interest in ShouldSetManager.

Two options to override that behavior:

You could override UAsetManager::ShouldSetManager in your own AssetManager and remove it.

You could remove the PrimaryAsset status from your Collection assets, and instead create a manager PrimaryAsset of each of them that has a single explicit asset - the Collection. All of the Collection’s package references would then be secondary assets of the owning PrimaryAsset, and will respect the priority rules.

[Attachment Removed]

5

Hi Martin,

I don’t know of a useful way to represent and share this data, sadly. What I can tell you however is that I tried the following hack to advance my understanding of the issue:

In `FAssetRegistryImpl::SetManageReferences`, in the definition of the `IterateFunction` lambda, I added a condition that checks wether the ManagerNode is my “initial PlayGo” PrimaryAssetLabel, and the TargetNode is my LVL_World. In which case, simply add TargetNode to VisitedNodes and early exit.

My intention is to bypass all explicit dependencies on the world for this PrimaryAssetLabel/Chunk, knowing for sure that I have other PrimaryAssetLabel/Chunks configured to reference it.

My preliminary testing shows that the resulting packaged game works and the dispatch of assets between my Chunks now looks pretty much like I expected. So, gross hackery apart, do you see a major problem with this ?

Regarding LevelSequences, the references are from bindings indeed. I asked around and we are not using Dynamic Bindings, which might very well be the issue here (unfortunately it’s not feasible to change all our assets at this point).

---

I was also surprised by the following behavior, hopefully you can shed some light on it.

Mainly, I have 2 Collections, produced by the commandlet mentionned in the previous question. One lists assets directly referenced by actors from the “initial zone”, and lists assets directly referenced by actors outside the “initial zone”. Each collection is used by a PrimaryAssetLabel to assign their content to a specific Chunk, with different priorities.

Some of these assets are listed in both Collections since it’s legit to have the assets used at multiple places in the game world.

What I don’t understand after reading https://dev.epicgames.com/documentation/en\-us/unreal\-engine/cooking\-content\-and\-creating\-chunks\-in\-unreal\-engine is that assets present in both Collections end up in both Chunks, seemingly ignoring the priority thing.

I can see that’s what `UAssetManager::BuildChunkMap` accomplishes, so, what am I not understanding correctly here ?

[Attachment Removed]

6

AFAIK the assetmanager totally skips the priority for chunk assignment, it only checks that for cook rule. Or am i wrong?

I also am finding creating an initial chunk for PlayGo using a world partition map VERY hard. I expected this to be easier.

In my case i use data layers to cut different chapters of my game. I have made a tool that gets every asset referenced by the data layers i need and puts them into a Primary Asset Label with “apply recursively” set to true. But i still encounter crashes and issue because the chunks are missing stuff.

Is there any update to the JIRA UE-175885 mentioned in Any solution for PlayGo initial play area with World Partition? i cannot find it in the issue tracker