Page MenuHome

Faster Animation Playback
Confirmed, NormalPublicTO DO

"Love" token, awarded by gintszilbalodis."Love" token, awarded by LahceneB."Love" token, awarded by bintang."Love" token, awarded by Bit."Love" token, awarded by aditiapratama."Love" token, awarded by RedMser."Love" token, awarded by nunoconceicao."Love" token, awarded by CobraA."Love" token, awarded by xrg."Like" token, awarded by Biaru."Love" token, awarded by spawn_x."Like" token, awarded by szap."Love" token, awarded by Dspazio."Love" token, awarded by herbert123."Love" token, awarded by Ronald."Like" token, awarded by Kubo_Wu."Love" token, awarded by cruelandunusual."Love" token, awarded by Alumx."Mountain of Wealth" token, awarded by Brandon777."100" token, awarded by Zino."Love" token, awarded by bnzs."Like" token, awarded by Schamph.
Assigned To
Authored By


Status: Discussing Designs


Commissioner: @Demeter Dzadik (Mets) @Hjalti Hjálmarsson (hjalti)
Project leader: @Jeroen Bakker (jbakker)
Project members: @Sergey Sharybin (sergey)


Big picture: Animators should be able to work in an interactive environment.

Non functional requirements:

  • Animation playback in the viewport should play at constant framerate at 24fps.
  • ? Motion curves should be update-able in realtime
  • Playblast shouldn't take much more than regular viewport playback.
Work plan

Milestone 1 - Animation Cache

Status: Needs Design and engineering plan to proceed
Time estimate:: To be determined after Design/EngineeringPlan
Design: T73481: Design: Animation Caching
Engineer plan: Not started

Animation Caching Mechanism: RAM/Disk cache mechanism that can cache the output of an animation. During the animation the cache is invalidated.
This cache can also be used for viewport playback and viewport animation rendering.

Milestone 2 - Animation Playback/Render Performance

Status: Approach described, not started
Time estimate:: Not clear as this milestone uses an iterative approach
Design: T73429: Approach Faster Animation Playback
Engineer plan: Will be created per improvement.

Find ways how to optimize the current implementation. This will improve the update speed of the animation cache and when no animation cache is desired.

Event Timeline

Dalai Felinto (dfelinto) lowered the priority of this task from 90 to Normal.Aug 20 2019, 9:05 PM
Dalai Felinto (dfelinto) created this task.

One somewhat obvious method is to use geometry caching, so we only have to re-evaluate the current character or deformed mesh, rather than having to re-evaluate everything always.

One somewhat obvious method is to use geometry caching, so we only have to re-evaluate the current character or deformed mesh, rather than having to re-evaluate everything always.

I tested performance on a character, without decimating it in hopes of faster playback (like usual), and the fps was up to 18 fps,

I wrote a script to "test" how I believe a cache system could increase fps.
I basically "applied" the visual geometry on every frame, to new objects, with a driver on their hide_viewport property with the expression not'{bpy.context.scene.frame_current:03}')
All the objects' names ended with the intended frame number.

Performance went up to 60 fps (Blender can't play faster than this, so I can't measure the actual increase)

The point I'm making is that if you store geometry with the modifiers applied, it will drastically improve playback.

Caching can be limited to Timeline range (or reduced to Preview range if that's enabled)
Cache would only bake meshes with animation data or are linked to animated objects (such as armatures)
Their individual caches only get recalculated when the animation data of one of the objects in that chain are altered.

It doesn't have to be on always or by default. It could also be manually set on objects, whether or not they'll be cached.
Outside of the cached frames (like subframes) or on the active frame (when playback isn't running), the raw (non-cached) mesh would be displayed, and on the cached frames the raw mesh (and modifiers) would be hidden and the cached mesh would be displayed.

That's how I imagine a cache system working, with the goal being to view the animation in viewport AFAP with the ability to still edit it.

ML (spawn_x) added a subscriber: ML (spawn_x).

This task is too vague to be tagged with any specific Blender release version, so leaving it just as a task on the module page as a reminder to work in this area in general.

Jeroen Bakker (jbakker) renamed this task from Faster animation playback to Faster Animation Playback.Mon, Jan 27, 2:13 PM


Great to hear that you guys are going to work on this in 2020 its to me one of the most important things now a days, i've compared working with rigs that run at 40fps in feature vfx animation, and working with rigs at 2fps and the difference is massive in terms of productivity, frustration and so many other things you can do just because rigs run this fast (at a company i worked they made it so that skin deformation would run in the GPU so this would add a punch of smoothness in the viewport wich made tthings like onion skin becomes possible because you have this level of interactivity)

Anyways here are some of my thoughts:

It should start caching the moment you refresh anything, say you move the hand and the moment you confirm where it goes (maybe wait a third or a fourth of a second) and start caching right away whatever part of the cache was invalidated according to that change.

Caching feel seamless and run in the background like caching video on a video editor (not vse XP) while editing.

Definitelly it should have a "play/pause" button mode easily accessible because it will probably consume more ram than anything else so there is always a case where maybe you dont want it running in the background.

We should have a small bar in the timeline l(ike with simulation)s that expands forwards and backwards filling whatever has been affected by the change, (example if i move a hand in frame 10, but it has a keyframe in frame 5 and 15, then assuming that it only c)hanges the interpolation between those frames it should update from frame 5 to 15 no more no less.)

To the user I dont think it should be any more visible than that, a loading bar, play/pause caching and purge, and more advanced options in the preferences like: caching forwards and backwards or caching just forwards from the playhead or caching forward from the startframe (wether its preview range or normal range)

Also whatever thing is visible should be cached, if there is hair, cloth, it should all be able to be part of this cache.

And that's it regarding features and the user side as I see it, should be simple and fast to turn on and off ad easy to spot what its doing when.

UPDATE: so the playback should be the target playback, meaning if we're working on a project that's at 30 or 60 fps also should be considered, mostly now with newer platforms like vr where you need stuff to play at 120fps.
Starting with target 24 is good for film advertising and most media but everything new mediums is further than that now days so we do need to think long term.

Also playblast should become something just used to render previous to send to clients, or to publish in systems like attract, they will become pretty much irrelevant for the animation process itself.

Thats i think it.
any time you need testing or whatever let me know, id be happy to

(at a company i worked they made it so that skin deformation would run in the GPU so this would add a punch of smoothness in the viewport wich made tthings like onion skin becomes possible because you have this level of interactivity)

I run into this too when i tried to make my own rig, I posted my conclusion on the code blog hoping the Devs might see it.
It's not far off from what you're saying.

or Faster Animation Playback i want to mention one thing related, the Armature modifier seems extremely slow, not sure if it’s doing it on the GPU or CPU, i have a rig typcial game model that’s less than 50k polys and a very basic rig steup but runs slow, so u can imagine if it was feature or vfx rig with more high poly count and complex setup of multipe modifiers..etc

There must be a better way to do fast skinning and maybe move it away from the stack or something so it doesn’t bugged down, of course cashing the geo also help but i think the underlying problem is with the Armature modifer

I want to inform you, that you need to disable the "Auto Smooth" option from the character in order to increase performance for the viewport while previewing the animation.

Here's an example:

@Adrian Lipiec (Coverop) Auto Smooth isn’t on by default. This is why. The fact that it is slower is well known.

Perhaps an option to globally disable auto smooth in the viewport could be added to the "Simplify" settings?