[5.7.1] AnimSequence with ACL Bone compression invalid alignment

Development Character & Animation
, ,
1

Hello :slight_smile:

Coming from 5.5, we have animSequence that use the acl bone compression, for some reason, it seems to create an issue in build with the alignment of the acl::compressed_tracks, if i understood correctly in builds we use the acl database which basically store all compressed tracks in the same memory segment, i suspect it might come from that, the packaging is done under a mac and the crash is seen with an IOS build
Here we have the callstack

[Image Removed]

we hit the check

[Image Removed]

2

Forgot to say, i tried to set the compression to the fallback compression, it’s not crashing, and as soon as i put the ACL compression again, it’s crashing, so i doubt it is coming from some leftovers compression of 5.5, but it’s a guess

3

Hello,

That is quite unusual. Looking at the callstack, it appears that this particular animation sequence is using the regular ACL codec (default in UE 5.7), not the Database one. We can also see that the CompressedClipData pointer doesn’t appear to be correctly aligned, just as reported. Its alignment is 1 byte when it should be a minimum of 16 bytes.

On most platforms, the compressed data is allocated within a regular TArray which will maintain the proper alignment.

Could you modify FACLCompressedAnimData::Bind locally?

It currently does:

virtual void Bind(const TArrayView<uint8> BulkData) override { CompressedByteStream = BulkData; }

Try the following:

virtual void Bind(const TArrayView<uint8> BulkData) override
{
    CompressedByteStream = BulkData;
    const acl::compressed_tracks* CompressedClipData = GetCompressedTracks();
    check(CompressedClipData != nullptr && CompressedClipData->is_valid(false).empty());
}

This function is called on load instead of on the first decompression call. That should help narrow down if this is an issue with memory corruption or something else.

On mobile platforms, such as iOS, it is also possible that the compressed data is memory mapped, in which case it isn’t allocated by a TArray. This handling is done in FCompressedAnimSequence::SerializeCompressedData.

Could you confirm the following:

  • Is the animation sequence normal looking or empty (no bone data, pure curves/attributes) (e.g. in editor)?
  • Are you using memory mapping on iOS?
  • Is the check in Bind tripping as well or only on first decompression?

Thanks!

4

Hello :slight_smile:

After modifying the Bind function, i’m actually hitting the check in editor as well, if i try to open the animations

[Image Removed]it could be that mac is using the same memory mapping as the ios device, but starting from the branch 5.7 (up to date with 5.7.1 commits) and very few added commits (nothing related to animations), but since it’s a project from 5.5, maybe it is coming from a configuration, do you know a config i should look for that could potentially mmap in mac / ios ?

As far as i could tell, i don’t see anything weird with the animations itself, they are playing normally, even the apply compression is not reporting any errors

Furthermore, i tried to put all the animation under the default compression fallback settings, and it’s working fine as in 5.5 in build

I also tried to use force the usage of the ansi allocator, in case it could have an impact, but same result

5

Yes that was indeed this memoryMappedFiles configuration, i tried that prior to modify ByteSwapIn (tell me if you still need that input), that was the most promising test, now the question beeing, if this have been done to reduce memory waste, is it for me worth it to change it back to 16k and loose that memory rather than falling back to default compression for the animations, or is there is a way to specify aligments for theses specific datas ?

6

Of course, testing that right away :slight_smile:

7

I can validate 16 is good for fix, thanks for the help :slight_smile:

8

I think the call to Bind(..) might be too early after all.

Could you move the check inside UAnimBoneCompressionCodec_ACLBase::ByteSwapIn ? You might need to implement it in the derived ACL codec as I don’t think the Base will have access to the data

For memory mapping, you can look for: SupportsMemoryMappedAnimation and SupportsMemoryMappedFiles, they should be enabled on android/iOS I believe.

9

Can you try to override the default memory mapped alignment in your engine ini file?

Try this:

[MemoryMappedFiles]

Alignment=16384

That’s the old value, it was apparently changed to 1 to reduce memory waste.

10

16k is quite large, you should be able to set it to 16 bytes instead of the new value of 1 byte

That will be good enough for ACL and everything else

I’ve created a ticket internally to track this and I hope we can land that change in a patch for 5.7 (setting the value to 16)

If you could confirm that it works as intended, that’d be great.

Thank you for reporting and following through, much appreciated!