Confusion about async loading assets

Development Programming & Scripting C++
, ,
1

This is a really badly formed question but reading up on asset management has caused a lot of confusion.

The immediate aim is to get async load to work for static meshes and other assets using C++. At first it looked like TSoftObjectPtr was all that is needed: have a reference to the asset and load it in at begin play.

But it seems there is a whole ecosystem to this including: Asset registry, asset bundles, object libraries, primary/secondary assets, asset managers and streamable managers.

Does anyone have some resources to explain:

  1. What are primary and secondary assets and how do they relate to async loading actor assets?
  2. What are the required steps of creating an actor class which loads its assets asynchronously?
  3. Is using TSoftObjectPtr to a static mesh the correct way of defining an asset to be loaded asynchronously when required?
2

That’s exactly how it works (at least that’s what I did). When you want to delay (spread out) the loading of a heavy actor, make all references to meshes, sounds, and anything else heavy soft, and then load them as needed, or simply asynchronously at the start of the game (but you’ll still likely experience minor freezes).

3

  • Primary Assets: Assets tracked explicitly by the Asset Manager with a unique FPrimaryAssetId (Type:Name). Examples: Levels (UWorld), Data Assets, Blueprint classes marked primary. The Asset Manager can query, load, and unload these assets in an optimized, chunk-aware way.

  • Secondary Assets: Assets referenced by primary assets but not tracked directly by Asset Manager. They load automatically when referenced. Static meshes, textures, sound cues are usually secondary assets unless explicitly designated primary.

  • Relation to async loading: For explicit loading/unloading control and chunk management, use Primary Assets and the Asset Manager. For simple references like static meshes, use soft pointers (TSoftObjectPtr) and the StreamableManager to load asynchronously on demand.

  1. For meshes and typical assets, TSoftObjectPtr<UStaticMesh> (or similar) is the standard pattern

  2. This depends on your preference but you can technically not use any async loading inside the actor as long as that actor itself is soft referenced, so when the actor is loaded from a soft reference it will also load its decencies (static mesh, materials etc)

Let me give you an example of an actor loading its stuff async. One way I can go about it is make a data table or data asset and specify static mesh (Soft), materials (soft) and maybe other soft referenced assets. Inside the actor I would give it a variable ID so it can fetch those soft assets in begin play to update itself asynchronously.

  1. Yes as mentioned above that’s the correct way to soft reference assets like, static mesh, skeletal mesh etc. You also have TSoftClassPtr to soft reference classes, like actor class.
1 Like
4

Thank you for the reply!

I find that it recreates the same confusion as before. Surely meshes are the main assets that a game is hoping to load asynchronously.

Why is there a distinction between “Use asset manager for primary assets” and “use soft object pointers for things like meshes”?

Why isn’t everything a primary asset?
Why isn’t everything a soft object pointer?

It seems at the moment that both primary assets and soft object pointers are doing the same thing: letting you refer to assets to be loaded later when needed.

5

Because there is overhead to being a primary asset type that isn’t useful for most types.

Because not everything should be loaded piecemeal like that.

No, that’s not what primary assets are doing. The soft references held by a primary asset are letting it do that. But the primary asset is an asset in its own right with information beyond just the assets it references.

For example, let’s say I have an asset that is for an some ability. That ability has lots of content associated with it, and we don’t need that content loaded all the time. But it would be helpful if we had the ability asset itself loaded all the time (so that we can list it places and know that it exists). The content references would be soft and the ability may or may not be a primary asset (though as a primary asset loading it and loading the content through bundles would be nice, but it’s not required).

On the other hand, let’s say we have a vehicle asset of some kind. And let’s say that asset is only loaded when we’re going to have instances of it in the game (so like with a blueprint). In that case it makes a lot of sense for that asset to have hard references to it’s content so that we only have to load a single asset and all it’s dependencies load at the same time. So that when it’s done, we can place one in the level. We don’t have to then also wait on the dependencies by loading all the soft references.

If you needed information about the vehicle all the time, maybe you make a primary asset with a soft reference to that vehicle asset which has the information you need all the time like cost or display names. But then when you need to create one, you do one load of the vehicle asset and you know that when that finishes you can successfully instance it in your game.

2 Likes
6

So would it be correct to view primary assets as structures, tracked by the asset manager and which can hold arbitrary data?

Something like:

PrimaryAsset A{
  - Hard pointer to B
  - Soft pointer to C
  - some other ints and strings
}

Where B and C are secondary assets?

So when we set the level or some actor to own A:

  • we need to always explicitly load it? Or can we have soft and hard references to primary assets?
  • when we load A then B will be loaded automatically
  • if we want C to be loaded we would have to do an explicit load (sync or async) on A.C?
7

All assets are structures which can hold arbitrary data. They ultimately all derive from UObject, though UDataAsset and UPrimaryDataAsset are subtypes that make creating new asset types easier.

Primary Assets are still Assets, so any rules for secondary assets are still applicable to primary assets. You can have soft and hard references to primary assets.

Yes.

Yes.

1 Like