Hi,
I have noticed that, when using the Set Leader Pose Component node to make skeletal mesh A follow skeletal mesh B in the Construction Script of the blueprint, the time to compute the skinning is significantly lower than when instead those two meshes have been imported as as single skeletal mesh and Set Leader Pose Component is not used.
The slot I’ve been looking at to ■■■■■ this in Unreal Insights is GPUSkinCache_UpdateSkinningBatches.
I would have expected that the merged skeletal mesh would be more performant than using Set Leader Pose Component. Is there something I’m missing (like some other extra cost not related to skinning) or is it Set Leader Pose Component the recommended way of handling skeletal meshes that have different parts (even if they won’t ever change at runtime)?
Thanks for your time 
Best,
Victor
[Attachment Removed]
Hi Victor,
Just to clarify, you’re seeing that the time spent on skinning is less for two meshes running Leader Pose Component than for a single mesh? How many total materials and sections are there across the two different setups?
In general, Leader Pose Component is designed as a performance optimization for animation processing rather than skinning. It saves time by skipping the animation graph update and evaluation for the non-lead components and instead just sends the shared bones for the non-lead meshes directly to the renderer. It also often means that you can turn off tick on the non-lead meshes, which can be another significant saving.
Thanks,
Euan
[Attachment Removed]
Hi, what you describe definitely isn’t expected, particularly not something like a 4x-perf increase with the single mesh setup.
Along with the material slots, how many sections do the different meshes have? If the single mesh has many more sections on the merged mesh, that could cause a perf difference.
Also, how many verts do the different meshes have? It might be that the single mesh is particularly complex and that’s causing some issue related to batching which you don’t hit when dealing with the two mesh setup.
Lastly, do you see this in all builds (editor vs packaged) and on different devices/workstations? Or does it seem to vary based on hardware?
If you wanted to share the assets, I can also take a look at this directly to see what’s going on.
[Attachment Removed]
Hi, I don’t think that morphs should affect the complexity with the setup that you’ve described. Whether the morph buffer data is used is determined on a per-section basis. So if the sections are the same in terms of which are affected by morphs vs which aren’t, as it sounds like would be the case in your setup, I wouldn’t expect to see a difference. (Although the morph buffer itself will be larger for the single mesh setup so maybe that could have an impact).
Looking at the code, one thing that would have an impact is the number of bone influences of the different meshes. Say you have a face mesh which has 12 bone influences per-vertex and a body mesh which is 4. When you merge them, the entire merged mesh is going to run at 12 influences per-vertex, which will be more expensive. You can check this with the separate meshes in the editor. Open each mesh in the mesh editor, go to the eye icon drop down and select: Mesh > Mesh Info > Detailed. That’ll display the influences per section of each mesh.
If that doesn’t help, then the only way to say for sure would be to look at the asset. I can convert this case to confidential if you’d like, just let me know.
Generally, however, I wouldn’t get too focused on the cost of GPUSkinCache_UpdateSkinningBatches. You’re just looking at one part of the animation and rendering pipeline, and other areas may vary depending on your setup.
Like I said before, leader pose component wasn’t designed as a rendering optimization, it’s an animation optimization which means you don’t need to run animation blueprints on each mesh when running multiple mesh part setups. I wouldn’t expect that much thought was given to the cost of skin cache calculations for a single-mesh setup vs multi-mesh setups when it was implemented, since Fortnite was already committed to a multi-mesh part setup at that point.
[Attachment Removed]
If you want to test the whole pipeline, a better setup would be to just add ~50 characters to an empty level. Then you can profile the whole frame at a better scale. You can then look at:
- 50 single mesh component characters
- 50 multi-part mesh component characters w/ leader pose component set
- 50 multi-part mesh component characters w/out leader pose component set
Note that to see much of a difference between the two leader pose component setups, you’ll need to have anim blueprints running on each of the mesh components in the multi-part setup.
[Attachment Removed]
Hi Euan,
Thanks for the quick reply.
The skeletal mesh I’m testing consists of 2 skinned meshes, let’s called them A and B. Where A is the main one and B the secondary one.
The two cases I’ve tested are:
- Importing the asset as a single skeletal mesh into Unreal. In this case I don’t use any Set Leader Pose Component node since the two meshes parts are together.
- The same skeletal mesh but imported as 2 separated skeletal meshes into Unreal (one for each mesh part, A and B). And then using Set Leader Pose Component node to make B follow A in animation.
What I’m seeing in Unreal Insights is that GPUSkinCache_UpdateSkinningBatches takes x4 times more on case 1 than on case 2. So that’s why I was wondering if there was any advantage in skinning performance for case 2. I’ll have a look at turning off the the tick on mesh B, thanks for the tip on that
Regarding the materials for each case:
- 2 material slots (one per each mesh part, A and B). Each slot has assigned 1 material instance.
- Skeletal mesh A has 1 material slot with 1 material instance assigned to it. And the same for skeletal mesh B.
Best,
Víctor
[Attachment Removed]
Hi Euan,
That’s good to know, those were also my thoughts.
For context, I’ll paste the initial info again so it’s easier to refer to:
- The skeletal mesh I’m testing consists of 2 skinned meshes, let’s called them A and B. Where A is the main one and B the secondary one.
- I have tested 2 cases:
- Case 1: Importing the asset as a single skeletal mesh into Unreal. In this case I don’t use any Set Leader Pose Component node since the two meshes parts are together.
- Case 2: The same skeletal mesh but imported as 2 separated skeletal meshes into Unreal (one for each mesh part, A and B). And then using Set Leader Pose Component node to make B follow A in animation.
Material slots and sections:
- For Case 1, there’s 2 material slots (one per each mesh part, A and B). Each slot has assigned 1 material instance. And also 2 sections, one per each of those materials.
- For Case 2, skeletal mesh A has 1 material slot with 1 material instance assigned to it, and only 1 section for that material. And the same for skeletal mesh B.
Verts count:
- Skeletal mesh A: 46220.
- Skeletal mesh B: 105848.
Regarding the tests, I have only tested performance on the editor and in one workstation. But I can check on builds and other workstations if you think it’s still worth it after seeing the data above.
If we cannot figure out the reason, I can check if it would be possible to share the assets on a private thread.
Thanks for your time
Best,
Victor
[Attachment Removed]
Hi,
we saw a similar behavior while implementing body/head variants, keeping the head separated with a leader pose component was cheaper than merging because the heads SKM used morphers that made merging head+body far more expensive to update.
Mesh A being far smaller than B in your use case that may be related.
Cø
[Attachment Removed]
Hi Colas,
Thanks for the information, that’s good to know.
So, performance-wise, is it recommended to separate your more complex part of the mesh (e.g., because it has morph targets or a high poly count) into a separate mesh and use the Set Leader Pose Component node to make it follow the animation of the other mesh part?
From what I understood, the Set Leader Pose Component node would send the more complex part of the mesh to the render by skipping the animation graph/eval. And that would somehow be faster skinning-wise than having both meshes merged. But I don’t understand how this is more optimal for skinning. Is there any specific reason why this kind of setup is cheaper skinning-wise?
Best,
Victor
[Attachment Removed]
Hi Euan,
Thanks for the info.
I’ve just checked and both meshes have the same number of max bone influences per-vertex, this is true for both cases (meshes separated or merged).
I cannot share assets at the moment, even if the case is converted confidential. But I’ll keep it in mind if this changes, thanks!
If GPUSkinCache_UpdateSkinningBatches does not represent the whole picture regarding the overall animation/rendering cost, I will assume for now that merging these two meshes (for this case at least) is more performant than having them separated and using the Set Pose Leader Component node. I will profile it more precisely first just to be sure that the whole cost of the mesh is not greater than before the mesh merging. If I find any new findings I’ll report them back here.
Best,
Victor
[Attachment Removed]