Request for Mirror Animation Feature in ACL about acl HOT 3 CLOSED

Hello,

Thank you for the feedback!

I am not sure if I understand how mirroring in ACL would fit within your workflow. Would you care to elaborate? Are you not using the built in Animation Blueprint technology?

Generally speaking, ACL is primarily focused on the compression aspect of an animation runtime. It isn't meant to include other pieces generally provided by such a runtime (e.g. graph state, state machines, blending, etc).

Looking at the UE workflow, a compression codec (such as ACL) is assigned at the animation sequence level. This means that if ACL mirrors during compression, that sequence will always be mirrored. If you wish to use it in mirrored and non-mirrored contexts, you'll need to explicitly duplicate the sequence, doubling memory usage for it in the process. Alternatively, ACL could duplicate the compressed data for you and store both mirrored/non-mirrores versions but the footprint would double regardless (and you would need some mechanism to pick which one of the two to use during decompression).

Mirroring is often used to save on the runtime memory footprint with animations being used both ways. Encoding the mirroring during compression would run counter to that goal.

ACL could perform mirroring during decompression at runtime. That would allow you to pay the memory price only once and toggle the behavior at runtime. However, the current data driven setup in UE will not allow you to do this without engine changes. You will need some higher level piece of code (part of the animation graph) to decide when to mirror and forward that information to ACL prior to decompression (somewhat similar to how additive animations are currently handled in UE). While this would work, it isn't clear what benefit it would have over using the existing mirroring solution in UE. Have you tried the built in mirror table/anim node solution? Practically speaking, ACL won't be able to perform a much better job than UE does for this due to the nature of the mirroring operation.

Mirroring is typically implemented as follow:

• First, a mirroring plane is defined (often in object/model/world space) and provided by the user.
• Each joint then needs to be brought into the same space (frame of reference) as the mirroring plane in order to perform the reflection operation (or the plane is brought into the frame of reference of each joint). For example, a spine joint leaning left, would lean right instead.
• This is not sufficient for all joints. Things like arms and legs need additional work: remapping. A mapping table is required and provided by the user to swap things like right/left arms.
• Remapping is performed

As such, in order to mirror an animation, we need several pieces of information from the user (mirror plane, remap table) and we need the full animation pose (to convert to/from object space). Because we need to know the full pose in order to convert from/to object space, it leaves no room for ACL to be 'clever' with how it treats mirroring. It would leave us no choice but to fully decompress the pose before performing the mirror operation. This would have near identical performance to the existing UE solution.

It is also very common to mirror intermediary poses that are the result of a blend (or other) operation. ACL has no knowledge of how intermediary poses are stored (engine dependent). Adding mirroring to ACL would also require us to support that workflow otherwise you would have to re-implement the behavior in your animation runtime. Practically speaking, it isn't possible for ACL to be optimal when working with a full pose without knowledge of how the host animation runtime stores it. Some runtimes will use non-uniform 3D scale while others use uniform scalar scale. Some store joints as an array of structures (transform[]) but other formats are also used such as structure of arrays (rotations[], translations[], scales[]) or a full SIMD format (rotations_x[], rotations_y[], ...). Some engines don't use quaternions to encode rotations opting instead to use quaternion logarithms, euler angles, 3x3, 3x4, or 4x4 matrices. To be optimal, ACL would have to support all common transform types and all common memory layouts. It would also need to provide a 'safe' fallback for non-optimal code paths for exotic engines to use or perhaps a hatch for them to provide an optimal implementation. Supporting this, although possible, would require very careful consideration to ensure a clean API and optimal performance. All of this complexity around pose management is why ACL tries to make as few assumptions as possible and has so far avoided pose manipulation features.

Cheers!

from acl.

Hello,

I am writing to retract the issue I had previously raised regarding animation mirroring with ACL. After further consideration and understanding the core policies and principles of ACL, I realize that it was out of place for me to suggest implementing such a feature directly into the ACL.

Upon reflection, it is clear that ACL is primarily focused on animation compression and it would not be in line with its objectives to incorporate a mirroring feature directly. In hindsight, it makes more sense for such a feature to be handled on our end, utilizing the existing capabilities of Unreal Engine, rather than expecting ACL to accommodate this specific case.

I apologize for any confusion caused and appreciate your detailed and thoughtful responses which led me to this understanding. Your patience and expertise have been greatly appreciated and I thank you for your time spent addressing my issue.

Best Regards,

from acl.

No worries :)

There is also another quirk of mirroring that I haven't mentioned that further complicates handling within ACL: mirroring additive animations.

Additive poses have their joints not in the local space of their parent joint like ordinary poses do, but instead they are in the local space of the joints themselves. As such, it is not possible to convert the mirror plane and joints into the same space without an intermediary pose in parent local space. I would have to double check the math but I don't know if the bind pose could be used for this or whether we would require the base pose the additive will later be applied onto. AFAIK, that is the primary reason why UE doesn't currently support mirroring additive poses.

I have wider ambitions for open source animation technology beyond just ACL but I no longer have the spare time/bandwidth required (for now anyway). I've thus narrowed my focus purely on ACL for now. Perhaps someday I'll get there :)

from acl.