Hi,
I’ve recently had to dive into animation performance and had a couple of questions. Animation is sadly not my specialty so I probably am missing a lot of context on all of those; hopefully, someone will be able to provide some of the missing information.
First, I have recently found that bTickAnimationOnSkeletalMeshInit has a comment saying that when activated, it will use a pre-4.19 behavior (see bTickAnimationOnSkeletalMeshInit in AnimationSettings.h).
Looking at all the sample, they seem to use the default value which would be bTickAnimationOnSkeletalMeshInit=true. Is there a reason beyond convenience that no sample seems to be using this for UE5?
What would be the expected fixes that would need to be done to properly use the post-4.19 version of those?
Second, is there a reason why PostProcessAnimInstance are not included in that animation deferral? (see PostProcessAnimInstance->InitializeAnimation in USkeletalMeshComponent::InitializeAnimScriptInstance in SkeletalMeshComponent.cpp)
Last but not least, we’ve also seen that both SetAnimInstanceClass and SetSkeletalMesh being done before the component is registered seems to request animation initialization that is subsequently dropped when the actual OnRegister is called. Is there a reason those anim are initialized early or could it be postponed when the component is not registered?
Thank you for considering those questions.
Have a nice day!
Hi, the main reason for the implementation of bTickAnimationOnSkeletalMeshInit is to prevent the game thread update and evaluation of the anim graph. So most of the performance improvement should come from not calling this branch:
if (bTickAnimationNow)
{
TickAnimation(0.f, false);
RefreshBoneTransforms();
}
Our various samples don’t disable this because when disabled, meshes will display the ref pose on the frame they are initialized. You then have to do extra work to hide the mesh until the next frame, at which point the regular threaded update and evaluate will generate a pose. But doing that would add extra complexity to the samples, so we’ve erred on the side of not doing that. That’s the same reason we have the flag enabled by default. But we recommend it’s disabled in production, as we do in Fortnite.
> Second, is there a reason why PostProcessAnimInstance are not included in that animation deferral? (see PostProcessAnimInstance->InitializeAnimation in USkeletalMeshComponent::InitializeAnimScriptInstance in SkeletalMeshComponent.cpp)
I’m not sure that there is a particular reason for this, I’ll need to double check and follow up.
> Last but not least, we’ve also seen that both SetAnimInstanceClass and SetSkeletalMesh being done before the component is registered seems to request animation initialization that is subsequently dropped when the actual OnRegister is called. Is there a reason those anim are initialized early or could it be postponed when the component is not registered?
USkeletalMeshComponent::InitAnim should early out when the component isn’t registered, so we shouldn’t be doing any of the anim graph initialization in that case. Can you give me more information about what you’re seeing here?
Thank you for the quick reply.
Although I understand that this would be extra work to hide the mesh until the next frame, it would still be nice to have at least one sample that shows the proper value to use.
Fantastic, I’ll wait on your follow-up!
For the SetAnimInstanceClass and SetSkeletalMesh, you are right, seems I missed that important part. I’ll need to better understand what is happening in our code; I imply something went wrong on my side and I just missed it. Thank you for pointing the registration checks.
Have a nice day!
> it would still be nice to have at least one sample that shows the proper value to use.
Yeah, I agree, particularly since, although we recommend it, I think the only place we talk about it publicly is in this tips and tricks doc. As the Gameplay Animation Sample expands, we may be able to include something in there that shows it.
> Fantastic, I’ll wait on your follow-up!
Talking to the dev team, it sounds like this was just an oversight/not part of the original requirements when the deferral functionality was originally added. It doesn’t seem like there is any reason not to also do the same with the post process anim instance so I’ve added a task for that.
Let me know if there’s any other questions.