Animation Debugging & Troubleshooting | MCO

Every game developer has experienced animation bugs — the T-pose of doom, feet sliding across the ground, characters jittering in place, or animations popping between states. These issues are frustrating, but they are also predictable. Most animation bugs fall into a small number of categories with known solutions.

This guide covers the most common animation problems in game development, explains why they happen, and shows you how to fix them. Whether you are working in Unreal Engine, Unity, Godot, or any other engine, these principles apply.

T-Pose and A-Pose Defaults (Skeleton Mismatch)

The most recognizable animation bug is the T-pose — a character standing with arms straight out to the sides, completely ignoring the animation that should be playing. This almost always indicates a skeleton mismatch.

Every animation clip is authored against a specific skeleton hierarchy. If the skeleton in the animation does not match the skeleton on the character mesh, the engine cannot map the bone transforms and falls back to the bind pose (T-pose or A-pose, depending on how the character was rigged).

Common causes include importing an animation meant for one skeleton onto a character with a different skeleton, mismatched bone names (the animation expects "Hips" but the skeleton has "pelvis"), or missing bones in the target skeleton. The fix is to ensure skeleton compatibility — either retarget the animation to the correct skeleton or rename bones to match.

When importing motion capture data, verify that the source skeleton hierarchy matches your project's character skeleton. MoCap data from different studios may use different naming conventions. Most engines provide retargeting tools to handle this mapping automatically.

Foot Sliding Fixes: Root Motion vs. In-Place

Foot sliding — where a character's feet appear to skate across the ground — is one of the most common and most noticeable animation artifacts. It happens when the character's translation speed does not match the animation's implied movement speed.

Root Motion

With root motion, the animation itself drives the character's position. The root bone's translation data moves the character through the world. This eliminates foot sliding because the movement speed is baked into the animation data. However, root motion can feel less responsive since the animation, not the player input, controls movement speed.

In-Place Animation

With in-place animation, the character controller drives movement and the animation plays on top. The animation contains no root translation — the character stays in place while the legs cycle. The game code moves the character independently. Foot sliding occurs when the code-driven movement speed does not match the animation's step frequency and stride length.

To fix foot sliding with in-place animation, calculate the correct movement speed from the animation data. Measure the stride length (distance one foot travels per cycle) and the cycle duration, then set the character's movement speed to match. Alternatively, blend between walk and run animations using a blend space driven by actual movement speed.

Jittering and Micro-Vibration

Characters that vibrate or jitter in place typically suffer from one of two issues: floating point precision or compression artifacts.

Floating point precision problems appear when a character is far from the world origin. At large coordinates (10,000+ units from origin), 32-bit float precision degrades and small bone transforms become noisy. The fix is to keep gameplay areas near the world origin or use origin rebasing.

Compression artifacts appear when animation data is compressed too aggressively. Engines compress animation curves to save memory and disk space, but excessive compression introduces quantization noise that appears as jitter. Reduce the compression error tolerance for affected clips, or mark critical bones (like the hips and spine) to use higher-precision compression.

Motion capture data is particularly susceptible to compression artifacts because MoCap captures subtle micro-movements that aggressive compression strips away, replacing natural stillness with quantized stepping. Use lower compression ratios for MoCap data than for hand-keyed animation.

Animation Popping Between States

When a character snaps abruptly from one pose to another — walking one frame, suddenly in a combat stance the next — the issue is a missing or zero-duration transition in the state machine. Every state transition needs a blend duration that gives the engine time to interpolate between the two poses.

Typical transition durations range from 0.1 to 0.3 seconds depending on context. Idle-to-walk needs a short transition (0.1–0.15s). Walk-to-run can use a slightly longer blend (0.15–0.2s). Combat transitions often use faster blends (0.05–0.1s) for responsiveness.

If popping occurs despite having transitions, check the transition's interrupt settings. If a transition can be interrupted by another transition before it completes, the character may pop as it starts one blend, cancels it, and begins another. Limit interruption to specific high-priority transitions.

Blend Tree Artifacts

Blend trees (or blend spaces) interpolate between multiple animations based on parameters like speed and direction. Common artifacts include limbs passing through the body, feet floating above or below the ground plane, and unnatural poses at parameter values between the source clips.

These artifacts occur when the source animations are not compatible for blending. If one walk cycle has the left foot forward at frame 0 and another has the right foot forward, blending them at 50% produces a pose where both feet are roughly centered — which looks like the character is standing with legs together while moving.

Fix blend tree artifacts by ensuring all source animations are phase-synchronized (same foot forward at the same normalized time), authored at the same height relative to the ground plane, and have compatible poses at the blend boundaries. Well-captured MoCap data from a single session is inherently compatible since the same performer produced all the clips.

Rotation Order Issues (Gimbal Lock)

Gimbal lock causes bones to snap or spin unexpectedly when two rotation axes align. This is an inherent problem with Euler angle representation. When the middle axis rotates to ±90 degrees, the first and third axes become parallel, losing a degree of freedom.

Most modern engines use quaternions internally, which do not suffer from gimbal lock. However, gimbal lock can still appear in the animation data itself if it was authored or exported using Euler angles. FBX files can store rotations as Euler or quaternion — check your export settings. If you see spinning joints in imported MoCap data, the issue is almost always the rotation order in the FBX export. Try changing the rotation order (XYZ vs. ZXY vs. YZX) in your DCC tool before re-exporting.

Scale Inheritance Problems

Non-uniform scale on parent bones causes shearing on child bones. If a character's spine bone has scale (1.0, 1.2, 1.0), all child bones (arms, head, upper body) will be stretched along the Y axis. This compounds through the hierarchy — each child inherits and multiplies the parent's scale.

The fix is simple: never use non-uniform scale on bones. If you need to adjust character proportions, modify the mesh, not the skeleton. If you receive animation data with baked-in scale values, strip them on import or normalize them in your DCC tool before export.

Mesh Penetration During Animation

Arms passing through the torso, fingers clipping through weapons, hair penetrating shoulders — mesh penetration is a constant battle in character animation. It happens because animation data moves bones without awareness of the mesh surface.

Solutions include adjusting the animation to avoid penetration (most reliable), adding collision-driven secondary animation (cloth, hair), and using post-process IK to push limbs away from the body when penetration is detected. For MoCap data, penetration is less common since the motion was performed by a real human whose body naturally avoids self-intersection, but it can still occur when retargeting to characters with different proportions.

FBX Import Issues

FBX is the standard interchange format for animation, but it is full of pitfalls:

• Axis mismatch — Different tools use different up-axes (Y-up vs. Z-up). If your character imports lying on their side or facing the wrong direction, check the axis settings in both the exporter and importer.
• Scale mismatch — Maya works in centimeters, 3ds Max in system units, Blender in meters. A character exported from one tool may import at 100x the correct size in another. Set the import scale factor or standardize your export units.
• Bone naming — If bone names contain special characters, spaces, or non-ASCII characters, some importers will rename or skip them. Use simple alphanumeric names with no spaces.
• FBX version — FBX 2020 handles some features differently than FBX 2014. If import fails, try exporting with a different FBX version.

Debugging Blend Spaces

Blend spaces combine multiple animations based on one or two parameters (usually speed and direction). When the output looks wrong, visualize the blend space in the editor. Most engines show the current sample point and the contributing animations with their weights. Check that the sample point moves as expected when the input parameters change, that the correct animations are placed at the correct positions in the space, and that no position in the space produces a degenerate blend (all weights near zero).

Animation Not Triggering (State Machine Logic)

When an animation refuses to play, the issue is usually in the state machine transition rules, not the animation itself. Check the transition conditions — are the required parameters being set? Are the conditions using the correct comparison operators (greater than vs. greater than or equal)? Is there a valid path from the current state to the target state?

Enable state machine debugging in your engine. Unreal's Animation Blueprint debugger shows the current state, active transitions, and parameter values in real time. Unity's Animator window highlights the current state during play mode. Use these tools before looking at the animation data itself.

Profiling Animation Performance

Animation evaluation can be expensive when hundreds of characters are on screen. Profile using your engine's built-in tools — Unreal's Animation Insights or Stat Anim commands, Unity's Profiler with the Animation module. Look for expensive blend operations, unnecessary bone evaluations, and characters evaluating full skeletal animation when they are off-screen or distant.

Common optimizations include reducing the update rate for distant characters (LOD-based animation), disabling bone evaluation for off-screen meshes, and using simpler animation graphs for background characters.

Common MoCap Cleanup Issues

Raw motion capture data often needs cleanup before it is production-ready:

• Noisy data — High-frequency noise from marker tracking appears as subtle vibration. Apply a low-pass filter to smooth the curves without losing the character of the motion.
• Marker gaps — Occluded markers create gaps in tracking data. Short gaps (1–3 frames) are usually filled automatically by the capture software. Longer gaps may need manual cleanup or interpolation.
• Ground contact — MoCap data may have slight foot penetration or floating above the ground plane. Adjust the vertical offset and use foot IK to lock contacts.

Professional MoCap data, like the packs from MoCap Online, has already been cleaned and processed. Noise is filtered, gaps are filled, ground contacts are adjusted, and the data is exported in standardized formats (FBX, BIP) ready for import into your engine of choice.

FAQ

Why does my character default to T-pose when an animation fails?

The T-pose (or A-pose) is the character's bind pose — the default skeletal configuration before any animation is applied. When the engine cannot evaluate animation data (due to skeleton mismatch, missing clip, or evaluation error), it falls back to this default pose. Fix the root cause (skeleton mapping, missing references) rather than masking it with a fallback animation.

How do I fix foot sliding without using root motion?

Match your character's movement speed to the animation's implied speed. Measure the stride length and cycle time from the animation, then set the character controller's speed accordingly. Use a blend space to smoothly transition between walk and run speeds. Additionally, foot IK can help pin the foot to the ground during contact phases, reducing residual sliding from imperfect speed matching.

What causes animation jitter on mobile devices?

Mobile devices are more susceptible to animation jitter due to lower floating point precision (some mobile GPUs use reduced precision), more aggressive animation compression (to meet memory constraints), and variable frame rates that cause inconsistent delta times for animation evaluation. Use higher compression quality for prominent characters, ensure smooth delta time calculations, and keep characters near the world origin.

How can I debug animation issues in a shipped build?

Build your project with animation debugging features enabled during QA. Unreal supports stat commands and visual logging in Development builds. Unity's Profiler can connect to development builds on-device. For production builds, log animation state transitions and parameter values to a file. Record the state machine state at each frame for the affected character and compare it against the expected sequence of states.

Root motion drift is one of the most common issues encountered when integrating motion capture animations into game engines. This occurs when the character's root bone accumulates small positional offsets over the course of an animation cycle, causing the character to gradually slide away from their expected position. The fix typically involves extracting root motion separately from the body animation and either baking it into the game's movement system or zeroing it out entirely depending on your locomotion approach.

Skeleton mismatches between imported motion capture data and your game character often manifest as twisted limbs or collapsed joints rather than obvious errors. When bone orientations differ between the source and target skeletons, rotations that looked correct on the original rig produce unintended results on yours. Most engines provide retargeting options that compensate for these orientation differences, but you may need to manually adjust specific bone mappings for problem areas like wrists, ankles, and the spine chain.

Frame rate conversion problems can introduce subtle animation artifacts that are difficult to diagnose. Motion capture data recorded at 120 frames per second that gets downsampled to 30 fps may lose the sharp timing of fast movements like punches or direction changes. Preserving keyframes at these critical moments during the resampling process ensures that the animation retains its intended impact even at lower playback rates.