Since we’ve begun integrating Mutable as a replacement for a previous modular mesh system, we’ve encountered some workflow issues, including unexpected ensures like the one this question details in its repro steps. Currently, we’re not sure how best to resolve this RegisterComponent ensure, other than perhaps patching the RegisterComponent to pre-check if the actor has a world before trying to register the groom component? I’m not very clued in on how movie scenes and level sequences function to understand quite what’s going wrong here, so advice on how to fix this would be most appreciated.
This problem extends beyond the naive, minimal, repro steps since our project has just converted a large quantity of level sequences from our previous modular mesh system to using a new system built around Mutable appearances. We’ve replaced the previous actors in these level sequences with actors which follow the general structure of ACustomizableSkeletalMeshActor, with some additional supporting components and functionality which combine the skeletal mesh components managed by a COI and Usages, with additional Posing/Driver skeletal mesh components as part of our CopyPose/RetargetFromMesh-based animation system. Now we’re hitting this ensure whenever people open a level with a level sequence in it with an actor using the new Mutable appearances.
We have concerns we have gone about something incorrectly with setting up this new Mutable-based system. It’s hard to judge whether we’re pushing Mutable into areas it was not designed for, or if we’re just uncovering gaps that haven’t been tested yet. This game’s cinematics rely on allowing the player and companion NPCs to appear in cinematics with the same equipment they have during play, with both the Player and NPCs using these new Mutable appearances, combining a variety of curated character COIs and runtime parameter adjustments to apply inventories of items on top.
We quickly learned that COIs should be cloned during gameplay to avoid parameters being shared between actors in the world and those runtime parameters leaking back into the editor and potentially being saved by accident.
We’ve also had great fun finding a reliable flow to ensure a CO is compiled when going into game in PIE. While not an issue in a packaged game, COs don’t automatically compile unless they are found to be in use by a component, but we don’t know how many components a CO can output until it is compiled. Catch 22. To work around this, we currently have Editor-Only code in our appearance component (which manages the creation of components for a COI) that calls SetIsBeingUsedByComponentInPlay(true) on the COI, similar to how a Usage does in UpdateDistFromComponentToPlayer, triggering the auto-compile behaviour via TickUpdateCloseCustomizableObjects. The above is working fine, generally, for spawnable characters.
The slimmed-down actors we use for cinematics present another challenge, since they more closely resemble CustomizableSkeletalMeshActors which when placed with a compiled CO, include Usage objects which are enough to trigger the auto-compile when the actor is loaded. This is great, except as our CustomizableObjects grow in complexity and referenced assets, compilation time has grown too. These stalls on loading into levels with level sequences have impacted developer iteration time significantly. We suspect we could reduce this compilation time if we were able to better leverage Tables and Parameterised inputs, but since our assets were developed for another system with different constraints they are not easily converted to table rows due to a variance in materials per part and complex modularity. Another factor here has been our design and layout of CustomizableObjects. Since we are not able to create reusable, modular COs we opted for a more generic structure of sub-COs which encapsulates all NPC variations, split only on gender (i.e. CO_Male and CO_Female), with more bespoke COs for hero characters. This avoids duplication, but leads to long stalls when a CO is first encountered, compiles, and streams in all the associated meshes. Often, when first opening a map, you’ll stall for multiple minutes as it processes multiple COs. We’ve also noticed COs do not appear to cache to the DDC in editor, so these stalls repeat every time you boot. UE-222775, from the looks of it?
[Attachment Removed]