Play slot animation causes T-POSE

Hello

I am developing a fighter. For my combo’s I have an udataasset tree (so a move can have list with moves, this is for combos). For example square => triangle combo looks different than square => square. To go from movement to combo I toggle a bool to select a slot in the animation and do playslotanimation. Everyting works great, besides the end of this slot animation. At the end couple milliseconds before I toggle the bool the game show a t-pose.

So when the animation ends on the slot a t-pose is shown. Is there a way to make the slot animation pause on the last frame instead?

Review your error log.
From how you describe it I would expect one animation is for another skeleton or invalid, thrown an error and causing the t pose.

The obvious: are you sure the animations don’t end in a t pose? If so, just cut the frames.

The nasty: you can use a pose snapshot but you have to trigger it on/off accurately in BP.

You may want to review some of the topics in here with much more complex situations and explanations about combos.

The animation is from the asset store. And I am using the mesh/skeleten that came with the animation.
But also the animation plays out until the end. When the animation ends it becomes a T-POSE

I am fairly certain the animations don’t end on a T pose. I am using the following animation pack.

There aren’t any combo system’s that are deterministic (for use in p2p games) made public (via forum posts or tutorials)

There’s plenty of explanations on how to do it right using buffers.

Idk about the t-pose.
If you reviewed the specific animation and it doesn’t end back in a t-pose itself, then you need to look up the log as there’s bound to be a bad animation in the mix.

Ever use debug animation?
Turn that on.
And do a slowmo .5

Maybe even film it so you can review it several times to read the animation names as they transition.

The newer engine also has a “film and scrub” debugging feature (never used it, because the new engines suck and are completely worthless, but if you are on .26 or greater you should have a look at it. It’s a great feature to debug animations)…

I’m running into this same t-pose issue - curious if you were you able to fix it at all and what the solution might be?

Always check your output log.
99% of the times you used an animation thats for a different skeleton and you are getting the error printed out but forgot to revise the log.

The other 1% of cases usually has to do with corrupt files .99% of times. So reviweing the animation and making sure it can play when dragged to a level directly would usually help.

I checked the animations individually and they looped just fine. Turns out my fix was to just to play the anims then chop off the last few frames (I am playing them in blueprint via a Play Montage and took the anim length of the current anim, then subtracted 0.1)

Also, should be good to note that this issue only happened on certain animation packs from the Epic Store. Other anims worked just fine.

Well in my experience when the player model defaults to the T-pose, which is the pose the the bind pose was added to, then that indicates that there is no valid animation key frames at that position with in the animation stream. Your fix is valid as a fix as you are removing the null frames. To confirm I’ve run across the issue from time to time and one cause is when imported more frames than animation is imported so if no offset animation keys are available then the default T/A pose,or the bind pose, will trigger.

Not an uncommon issue that Epic purchased packages would contain these issues if on the authoring side the number of frames are exported above the total number of transformation frames.

Thats really off.
Improting any amount of frames from a blender edited/made animation preserves the last pose used regardless of what is actually keyed.
Granted, I literally never use either maya or 3dmax to import animations, you should probably list what you are using that generates invalid/null frames…

Well it is a rather unique issue but is not a bug or error on the part of Unreal 4/5. Sticking to a possible reason with in context.

My animation weapon of choice is Motionbuilder as it’s designed to handle animation data in bulk takes rather then individual time lines in say a 3ds Max or Maya. As an app it’s design to handle animation more on the data level rather on the use of tools available for individual animation keyframeing.

I mentioned the above as unlike “do every thing well” applications MB by comparison handles a mountain of animation takes that could be hundreds contained within in a single file. Kubold for examples supplies all of his animation includes the MB source file in which he used to compile and export all of his animations to FBX format.

OK so how an invalid or null frame could be included, as the OP mentioned seems to occurred with purchased assets on all of the animations, is the process for export requires all of the keyframes applied to the control rig needs to be plotted down to the base Epic rig. As mentioned this could be hundreds of takes so a batch process is used to plot the frames based on the visible timeline so if the number of keyed frames is 10 but the timeline is 12 then the additional 2 frames are still plotted as part of the process. In Motionbuilder speak these would be consider null or invalid as they should not be considered as part of the intended batch process but rather over looked as part of the batch processing with out consideration as to individual requirements.

Once plotted down the take set is ready for export to FBX as the take can be exported based on it naming convention so is batched process with out individual verification as part of the process required by such programs like Maya 3ds Max or even Blender.

Since the OP did state it does seem to happen with purchased assets, and knowing how a lot of the packages were consolidated, I’m “assuming” the error originated in the original process and not a bug in UE4 as animation once imported is absolute data.

Motionbuilder does have the habit of small details being overlooked but due to the shear amount of data it’s easy to overlook small details as I’ve done so more that on one occasion