Mutable Memory Management: Prevent Loading All Sub-Objects

Development Platform & Builds
, ,
1

We are using the Mutable plugin to customize and dress a character. The setup follows the example project structure — each piece of clothing (shirt, pants, etc.) is its own Customizable Object, linked to the corresponding object in the main CO_Body (e.g., shirts linked to Torso, pants to Legs, and so on).

The system works as intended functionally, but we’re running into a significant memory issue:

When CO_Body is loaded, it appears to also load all meshes from every connected clothing object into memory, even if only one clothing item is active.

In Unreal’s Asset Manager, assets can be registered but only loaded on demand, giving full control over when resources are streamed in.

Is there an equivalent mechanism or recommended best practice for controlling when Mutable data is loaded or unloaded?

Specifically:

  • How can we prevent Mutable from loading all meshes/textures from linked clothing COs at once?
  • Is there a streaming or on-demand loading system in Mutable similar to Unreal’s asset streaming or soft references?
  • What is the intended approach to manage memory efficiently in large-scale setups with many clothing options?

Any insights or official recommendations on structuring Mutable projects for optimal memory usage would be greatly appreciated.

2

Hey there,

I’ll say this, Mutable is a memory-hungry system, both during creation and at runtime with the assets it generates. There are two answers to this, and it’s dependent on the context.

In the editor: When the CO loads, we load all of the assets that are necessary for it to generate the asset. We don’t really have any soft reference approaches for anything embedded in the customizable objects. If you use data tables, which can use soft references, you might be able to mitigate that. Graphs are editor-only, though, when you package the game, you will not hit this type of result.

In the runtime:

Non-Passthrough resource: At cook time, Mutable converts Unreal assets to its format and embeds them as bulk files in the CO. Bulk files are streamed on demand when updating a COI. Notice that the original UObject is not present in the package, only the Mutable version.

Passthrough resource: At cook time, Passthrough UObjects are moved from the Graph to the CO. These are kept as FSoftObjectPaths and loaded on demand when updating a COI. Notice that the original UObjects are present in the package.

How can we prevent Mutable from loading all meshes/textures from linked clothing COs at once?

For the runtime, this is automatically handled, noted above.

Is there astreaming or on-demand loading systemin Mutable similar to Unreal’s asset streaming or soft references?

Currently, we handle this depending on whether the object is a pass-through or not.

What is the intended approach to manage memory efficiently in large-scale setups with many clothing options?

Only assets for the requested customization will be loaded. It may happen that the customization is expensive (requires many assets) and it has a high memory peak. In this case we recommend enabling Mutable streaming (both Texture and Mesh). This way the customization peak will be reduced since it will only generate the LODs requested by the streamer. The memory required will be distributed over time since the steamer rarely requests all LODs at once.

Dustin

3

Yep you got it, Passthrough is defined in a couple of spots.

First for textures: https://github.com/anticto/Mutable-Documentation/wiki/Node-Mesh-Section#node-properties

And we have an experimental node for passthrough meshes:

https://github.com/anticto/Mutable-Documentation/wiki/Node-Passthrough-Mesh-Component

4

[mention removed]​ how will “Dataless” come into play here in 5.7, won’t it fix these issues?

https://dev.epicgames.com/documentation/en\-us/unreal\-engine/unreal\-engine\-5\-7\-release\-notes\#datalessmutable(experimental)

5

Hello Dustin, thanks for the reply.

Am I understanding this correctly:

  • in editor, we can use data tables but it won’t have any effect on the packaged build
  • in the packaged build, the data is always streamed on demand when updating the COI, not when loading the CO (for both passthrough and non-passthrough resources)
  • if the updating of the mesh takes too long, we should enable mutable streaming

And another question: how do I know/determine which resources are passthrough or non-passthrough?

6

Hey there,

Possibly, I didn’t mention dataless assets before because it doesn’t change how Mutable functions in terms of output, so it could help you with some memory while compiling assets, but you will still use quite a bit of memory as you load them. Again, this is primarily an editor time issue. If you are having memory issues at runtime, then you won’t see much difference.

Dataless, Mutable assets were developed with workflow streamlining and encryption in mind.

Another thing to keep in mind is that Dataless assets are experimental, so you may encounter other issues with them that could be a detriment to your project.