Hi Robert,
Last question first:
> Also on the size map, Is the disk size reading correct at least? Or is there a Editor/Build distinction there as well?
Unfortunately, this is still more complicated than you would hope. For disk size in Size Map we rely on the package size directly, rather than running the serialize method for each of the objects. And that should include the compressed data when you’re looking at the editor asset size. But this size will also include the data model, which is misleading if you’re interested in the cooked data size. (You’ll also get a different result if you look at the size of the cooked asset in Size Map as in the cooked data, we serialize the compressed bone transforms out to bulk data instead of including them in the anim sequence package.)
This is all pretty unintuitive and not very helpful, so I’m going to raise this with the dev team to see if we can do something to better support displaying the actual values for editor vs cooked, both in terms of memory and disk usage.
> I have some questions about memory on the editor side. Is that something worth paying attention to?
Will everything become more unstable if we start to have hundreds or thousands of curve animations?
Can anything be done to mitigate if this could become an issue?
Yes, it’s possibly something to be concerned about on large projects. Both memory usage and processing times are affected when loading all the animation data. The usual way to avoid those kinds of issues within the editor is to avoid hard references that load all your animations when you load the editor and/or a level. If nothing within the level has a hard reference to the animations, then they won’t be loaded by default, and you won’t pay the cost for loading them. Something to look out for with this is that if you use Motion Matching, the normalization databases tend to end up loading all the animations that are used by a mesh when the mesh is loaded. That shouldn’t be an issue for facial animations, they would only need to be loaded when they are referenced by an anim bp, level sequence, etc, that’s loaded. But you could end up in a situation where you load a mesh because it’s placed in a level, which in turn references an anim bp that uses all your facial animations, so they are all loaded when the level is loaded. Using soft references whenever possible avoids this.
There are some cvars you can also look at related to memory usage. We have a.StripFramesOnCompression & a.StripOddFramesWhenFrameStripping which we use on Fortnite to reduce the memory usage of anim sequences by stripping out frames when generating the compressed data.
There’s also a.AnimSequencer.LazyRigHierarchyInitMode. This won’t improve memory usage, but it’ll affect processing times when loading anim sequences. By default, when sequences are loaded, a FK Control Rig is created under the hood for each sequence (the idea being that you’ll eventually be able to modify the animations using that rig directly in-engine). But this is expensive when you load a lot of animations at once. This cvar skips that on load. This option is experimental however, and there have been issues with it causing deadlocks on cook in some more complex projects. We’ve made some improvements in 5.8, which we hope have resolved that, but we haven’t tested it on Fortnite yet.
> Are there any other stats to pay attention to in general?
I think Obj List Class=AnimSequence and AnimSeqStats are going to be the most useful for tracking anim sequence memory usage. And memory insights. There is also memreport -full, which will dump out a file to your project’s /Saved/Profiling/ folder, but that seems to mostly just be generated via Obj List Classfor various types.
[Attachment Removed]