Page MenuHome

Faster Animation Playback
Confirmed, NormalPublicTO DO

Tokens
"Mountain of Wealth" token, awarded by candre."100" token, awarded by weasel."100" token, awarded by Dir-Surya."Love" token, awarded by Krayzmond."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
None
Authored By
Dalai Felinto (dfelinto)
Aug 20 2019, 9:05 PM

Description

Status: Discussing Designs


Team

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

Description

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 - Animation Playback/Render Performance

Status: Execution
Time estimate::
Design: T73429: Approach Faster Animation Playback
Engineer plan: Will be created per improvement.
Related Tasks

These tasks are ordered in priority. The changes to the task scheduler has most technical impact so we should execute that task with highest priority so we have more time to fix any related issue. The Draw Manager changes rely on features that will be realized by the task scheduler. (@Jeroen Bakker (jbakker) will do the developments)

Changes to the dependency graph can start from the beginning. Most likely they will be executed by @Sybren A. Stüvel (sybren) or @Sergey Sharybin (sergey).

The rest (modifiers, action editor) can be executed afterwards. This is also the time to look at improving motion curves (if this is still needed). (@Jeroen Bakker (jbakker) will do the developments)

Milestone - GPU Subdivision

Status: Initial
Time estimate::
Design: To be completed
Engineer plan: To be completed
Related Tasks

The final design for subdivision (part of the modifiers optimization) needs more collaboration between the GPU/Viewport team and @Sergey Sharybin (sergey) to come with an realistic approach.

Milestone - 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.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jeroen Bakker (jbakker) renamed this task from Faster animation playback to Faster Animation Playback.Jan 27 2020, 2:13 PM

Hi!,

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

Hi!,

(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:
https://streamable.com/6gkf8

@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?

If its posible integrate Hydra/USD in the viewport to improvement playback animation?

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

could help a cache per collections?

Jeroen Bakker (jbakker) changed the status of subtask T75120: DrawManager: Improved Task Scheduler from Needs Triage to Confirmed.Mar 27 2020, 11:48 AM

A few notes from the spring scene profiling:
https://wiki.blender.org/wiki/User:Jbakker/projects/FasterAnimationPlayback/Spring_Scene_Analysis

  • UV layer subdivision happens for every frame, while it is static here. We should be able to detect when it actually changes and only re-evaluate when needed (also related to the mesh editing optimization project).
  • We should profile OpenSubdiv CPU evaluation and refinement itself, to see if we are hitting unexpected slow paths or if there are optimizations we could make there. OpenSubdiv GPU acceleration would still be most important of course.
  • Some modifiers like armature, mesh deform, corrective smooth, lattice also show up in the profiles. Optimizations for those are probably case by case. Often such modifiers only are used for part of the mesh with vertex group masking, there may be ways to more quickly skip any vertices not affected by them.
  • RNA_path_resolve takes significant time for driver / f-curve / action constraint evaluation. I believe this path could be resolved and the pointer cached during dependency graph build.
  • One scene has significant time copying multires displacement. I don't think this is really representative of a typical scene used by animators, but at some point I think it will make sense to look at referencing custom data layers rather than copying them in the dependency graph.

If its posible integrate Hydra/USD in the viewport to improvement playback animation?

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

could help a cache per collections?

Hydra & USD integration require huge changes to Blender including bumping the OpenGL version to 4 & up or
Moving to Vulkan which might speed the process , but still takes years of developement to reach a good result, that if the Devs decide to do it...Hydra is probably out of the question since we have Eevee but USD might come after 10 years or so :)

Jeroen Bakker (jbakker) changed the status of subtask T75208: Dependency Graph Evaluation Optimizations from Needs Triage to Confirmed.Mar 30 2020, 9:15 AM
Jeroen Bakker (jbakker) updated the task description. (Show Details)