We’ve found a small issue with ‘MovieScene.RemoveMutedTracksOnCook’ being on, we have found that muted Control Rig Parameter Tracks still are cooked and included in the build. They do however get immediately garbage collected post loading, but during loading they can increase our memory usage significantly due to it doing a ReconstructControlRig on the track. This creates a rig hierarchy, which in our case requires ~1MB per track. In our worst case scenario this can mean requiring 1GB of runtime memory during load before it deallocates.
We are currently not sure what is causing these tracks to still be cooked and loaded at runtime considering they are immediately garbaged collected. For now we are invalidating the ControlRig in RemoveAllAnimationData, to prevent the memory bloat, but in theory these tracks should never load to begin with, are there any ideas as to why this is the case?
Control Rig Parameter Tracks use GetCookOptimizationFlags just as other tracks do and are not overridden, one thing to check during cook is that your tracks are actually being stripped via UMovieSceneTrack::GetCookOptimizationFlags() and subsequently, UMovieSceneTrack::RemoveForCook().
I can confirm that the tracks are being labelled for being stripped and in the cook log it says they are as well, but in Insights we can see they are loaded and after streaming has finished, garbage collected. We’ve decided to rename the tracks to move them to the transient package when RemoveForCook is called, this also seems to work our end.
From what we can tell the objects are cooked when the sequence is saved as the object is saved directly after OptimizeForCook is called, meaning the tracks do no get garbage collected during the cook.