Hello,
this is a follow-up for [Content removed] where I asked how to handle characters with modular clothes that include physically simulated parts (dangling attachments like belts, sword scabbards etc.). We have investigated the solutions mentioned in https://dev.epicgames.com/documentation/en\-us/unreal\-engine/working\-with\-modular\-characters\-in\-unreal\-engine\#modularcharacterset\-upmethods and came up with a couple more questions:
The “skeletal mesh merge” method looks very similar to what we used in one of our previous titles (on a different engine though) and were not happy with the solution, since it prevents instancing of the clothes meshes on multiple characters as you need to create a unique mesh for each character. This in our experience leads to prohibitively large memory consumption. Or is the Unreal implementation somehow circumventing this? Also, are we right to assume this approach is essentially what the Mutable plugin uses?
If we use the “Copy Pose from Mesh” approach for assets with physics simulation, we need an animation blueprint for each such attachment on our character which according to the documentation has large performance costs.
So instead the “leader pose component” method is something we would favour. Problem is, the physics simulation of the “child” meshes is not supported with it. What if we merge physics assets from each attachment into the physics asset of the “leader pose component”? I.e. all constraints and body setups would be copied to the main component (this assumes the skeletons of the leader component and the attachments are compatible, but that’s OK, let’s say the lead skeleton contains all needed bones). We could then use RigidBody inside the main character’s animation blueprint to simulate all the attachments. Could that work? And can we expect noticeable performance improvements over the “copy pose” method? Because yes, this way we have only one animation update, but on the other hand it has multiple physics constraints to resolve anyway…
Questions for this approach (leader pose + merged physics asset):
1) Mutable already has physics asset merging implemented, is it viable to use Mutable just for the physics assets merge? I think we would need to do that in C code rather then blueprints: setup a Mutable pipeline with all our skeletal meshes on input and merged physics asset on output. We would call this when clothes on the character would change and assign the output as the physics asset of our character. Or would it be easier to implement it on our own? I suppose we could take some inspiration from GetOrBuildMainPhysicsAsset in CustomizableObjectInstance.cpp.
2) Could pose assets used by nodes like PoseDriver/RigLogic (e.g. created in the Pose Editor in Maya https://dev.epicgames.com/documentation/en\-us/metahuman/authoring\-rbf\-in\-maya) be merged as well so that we can use RBF pose modifiers for the clothing assets and have a single post-process animation blueprint?
Then if I may 2 less concrete, more of a “what’s your opinion” type of questions:
3) This way we would have just one RigidBody node for the entire character -> cannot have specific settings per asset. Currently we use the same settings for everything, but we haven’t yet really done anything “production ready”, can you maybe envision that there some parameters of RigidBody that would have to be different for different types of attachments, e.g. belts vs. braided hair?
4) Characters will be changing their clothes -> we will need to change the physical assets while the game plays. Do you see any obvious pitfalls? I suppose we will have to de-physicalize the character, change clothes, merge physics asset and physicalize again. What if the newly created asset is immediately in some collision, won’t it shoot our character into space? Maybe just remove the added parts of physics assets and append new ones without turning physics off will actually work better?
I understand there is a lot of questions, but I suppose it can be boiled down to: we would like to use the “leader pose component” method but also with physics and RBF pose modifiers for the “child” components. I understand we might need to implement some parts ourselves, but do you see some fundamental problems with it?