Three.js Animation: AnimationMixer, Tweening & GSAP

When GLTFLoader loads a model that includes animations (a walk cycle, an idle loop), they arrive as AnimationClip objects in gltf.animations. AnimationMixer plays them: create one mixer per animated object, get an AnimationAction from a clip, and call .play(). The mixer must be advanced every frame with mixer.update(delta). Forgetting this call is the most common "my imported animation doesn't play" bug.

Multiple actions can cross-fade (action.crossFadeTo(otherAction, duration)) for smooth transitions between animation states (walk to run, idle to jump) rather than an abrupt cut.

For animating a property directly (a camera flying to a new position, an object fading in, a UI-driven rotation) you have two practical options:

• Manual, in the render loop: track progress with clock.getDelta() or a start time, apply an easing function yourself. Full control, but you're reimplementing easing curves, sequencing and interruption handling that a library already solves well.
• GSAP: the de facto standard for this in the Three.js community. gsap.to(mesh.position, { x: 5, duration: 1, ease: 'power2.out' }) handles easing, sequencing (timelines), and interruption (starting a new tween on an object mid-animation) far more robustly than a hand-rolled solution.

The two systems compose fine in the same project: AnimationMixer for imported clips, GSAP for everything else.

Each active AnimationMixer costs CPU time every frame proportional to the number of animated bones/properties. For scenes with many simultaneously animated characters, consider capping how many mixers update per frame for off-screen or distant objects (frustum-based culling of animation updates, not just rendering). GSAP tweens are generally cheap individually, but hundreds of concurrent tweens targeting the same object can conflict. GSAP handles overwrite behavior configurably, which is worth understanding before it causes visually janky fights between competing tweens.