We have some locomotion data that calculates the authored speed of the animations by extracting the root motion and dividing by the duration of the animation. It does this during the PostLoad() of the LocomotionUserData object.
After upgrading to 5.7, our calls to ExtractRootMotionFromRange is indicating there is no movement in the animation. I did some debugging and the CompressedData currently has no entries in the ComrpessedTrackToSkeletonMapTable, so the bContainsRootBoneTrack ends up being false in ExtractRootTrackTransform_Lockless.
If I run the code later on, it’s extracts the root motion as expected.
It looks like the animsequence is currently in AsyncLoadingPhase2, so it appears to not be fully loaded. Is it not safe to assume that objects we’re referencing to be fully loaded anymore during PostLoad? Is there another function we should use to fetch and calculate these numbers, or is there a different phase in the loading that we can use to calculate them? Or can I attach a callback for the animsequence loading to do it?
We were previously on 5.5 and this code was working fine, it only started breaking after upgrading to 5.7.
As an update:
I’ve been able to attach a callback to the FAssetCompilingManager’s OnAssetPostCompileEvent. Once the callback triggers, I’m able to load and calculate the data correctly, however I’m unsure if that’s the expected solution or if there’s a simpler solution available I haven’t found.
One step I forgot to mention is the data we’re accessing are anim sequences that are part of a blend space. So we have a reference to the blend space, but we’re loading and calculating data based on the individual sequences in the blend space. I’m unsure if that’s needed or not.
[Attachment Removed]
Steps to Reproduce[Attachment Removed]
Hi, can you confirm for me that you have the change that was introduced to UAnimSequence::ExtractRootTrackTransform_Lockless at 44083221? The code should look like this:
bValidCompressedData = PlatformCompressedData.IsValid(this);
if (RequiredBones)
{
bUseRawDataForPoseExtraction = RequiredBones->ShouldUseRawData();
}
else
{
// Allow reading raw data in editor, as long as we don't explcitly request compressed data
bUseRawDataForPoseExtraction = !bValidCompressedData && !ExtractionContext.bEnforceCompressedDataSampling;
}
The bug that you’re describing was introduced in the 5.6 release, and the CL I listed was intended to resolve it. But your codepath is different since you’re extracting the root motion from PostLoad and not via an animation modifier, so it may be that you’re still hitting the issue.
[Attachment Removed]
Assuming you have the change I mentioned, it’d also be worth checking that bEnforceCompressedDataSampling isn’t set on your FAnimExtractContext when you call ExtractRootMotionFromRange.
[Attachment Removed]
I can confirm that we have that code in place.
bValidCompressedData is true(Bone data is valid - bHasValidCompressedBoneData is true because the CompressedTrackToSkeletonMapTable.Num is 0.
We end up returning false because the PlatformCompressedData.CompressedTrackToSkeletonMapTable is empty, so we don’t pass the check near the end of the bContainsRootBoneTrack lambda in ExtractRootTrackTransform_Lockless.
I’ve tried with bEnforceCompressedDataSampling both true and false, neither work since the CompressedTrackToSkeletonMapTable is empty.
Another oddity - while the callback on the AssetPostCompileEvent does fix it, the animations that are updated aren’t in the list of compiled animations, which make me think the animations we’re loading aren’t the ones being compiled, and it’s just that it’s late enough that the data is loaded.
I also tried using the OnEndLoadPackage, but I think I did that on the blend space and not on the anim sequences we’re actually checking, so that might have been happening at the wrong time. I’m going to try that option again, see if that will trigger for the right results.
[Attachment Removed]
Quick update, added checks for if the animation’s package has been end loaded, and some of them enter that path, while others end up getting queued against the AssetPostCompileEvent, so that’s not the right location either.
[Attachment Removed]
> bValidCompressedData is true(Bone data is valid - bHasValidCompressedBoneData is true because the CompressedTrackToSkeletonMapTable.Num is 0.
That sounds very similar to the issue that was discussed on [this [Content removed] Can you try making the change that was mentioned there to see if it resolves the issue for you? It’s changing the following line in FCompressedAnimSequence::IsBoneDataValid:
const bool bHasValidCompressedBoneData = CompressedDataStructure != nullptr || CompressedTrackToSkeletonMapTable.Num() == 0;becomes:
const bool bHasValidCompressedBoneData = CompressedDataStructure != nullptr;I think this makes sense since in your case you don’t have valid compressed data so you should be using the raw data, but that line is preventing that from happening.
I see that this change hasn’t made it into the engine yet so I’ll double check with the dev team about it.
[Attachment Removed]
Thanks for confirming. Yeah, that makes sense. The changes that went into 5.6 mean that we can’t assume that the compressed data always exists in the editor, which is why we should fallback to the raw data in this situation.
I’m just waiting to hear back from the dev team to confirm whether we’ll go with that change or not. I’ll follow up once I’ve heard back.
[Attachment Removed]
Hi, the dev team want to go in a slightly different direction with this. I have the proposed full fix shelved at 52939780 if you want to try integrating that, rather than the change I sent over previously
[Attachment Removed]
Great, thanks for confirming. We’ll get this submitted for 5.8, so I’ll close out this thread.
[Attachment Removed]
That does fix it.
I’ll also add one note, the reason why the data isn’t loaded at this point is it will be loaded from ddc later.
[Attachment Removed]
Just tested it and it works as well!
[Attachment Removed]