Faster Animation Playback #68908
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
45 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#68908
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Status: Discussing Designs
Team
Commissioner: @Mets @Hjalti
Project leader: @Jeroen-Bakker
Project members: @Sergey
Description
Big picture: Animators should be able to work in an interactive environment.
Non functional requirements:
?
Motion curves should be update-able in realtimeWork plan
Milestone - Animation Playback/Render Performance
Status: Execution
Time estimate::
Design: #73429 (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 will do the developments)
Changes to the dependency graph can start from the beginning. Most likely they will be executed by @dr.sybren or @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 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 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: #73481 (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.
Added subscriber: @dfelinto
#68909 was marked as duplicate of this issue
Added subscriber: @Phigon
Added subscriber: @WilliamReynish
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.
Added subscriber: @dgsantana
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 expressionnot self.name.endswith(f'{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.
Added subscriber: @item412
Added subscriber: @sozap
Added subscriber: @MarcelLegindi
Added subscriber: @brecht
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.
Added subscribers: @Mets, @Hjalti, @Sergey, @Jeroen-Bakker
Added subscriber: @StanislavOvcharov
Faster animation playbackto Faster Animation PlaybackAdded subscriber: @RedMser
Added subscriber: @LucianoMunoz
Added subscriber: @JorgeBernalMartinez
Added subscriber: @Scaredyfish
Added subscriber: @AditiaA.Pratama
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
Added subscriber: @Pipeliner
Added subscriber: @CobraA
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.
Added subscriber: @LahceneB
Added subscriber: @Coverop
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
@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?
Added subscriber: @YutaroFukagawa
Added subscriber: @seviscache
If its posible integrate Hydra/USD in the viewport to improvement playback animation?
could help a cache per collections?
Added subscriber: @SamGreen
Added subscriber: @electronicpulse
A few notes from the spring scene profiling:
https://wiki.blender.org/wiki/User:Jbakker/projects/FasterAnimationPlayback/Spring_Scene_Analysis
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.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 :)
Removed subscriber: @YutaroFukagawa
Added subscriber: @dr.sybren
Added subscriber: @lrevardel
Added subscriber: @ckohl_art
Added subscriber: @MeshVoid
Added subscriber: @pauanyu_blender
Added subscriber: @2046411367
Added subscriber: @acorn
Reference Maya playback cache code?
Where is Maya playback cache code available for download?
@acorn we don't discuss, mention, refer to non open source solutions in the Blender channel.
I have closed some TODO tasks as "Invalid" and replaced them with a one-liner in this task's description.
See the 2020-11-12 module meeting notes for more information.
Added subscriber: @mysticfall
Added subscriber: @T.R.O.Nunes
Added subscriber: @RelyGFX
So, any updates with this? It seems that the last active work on this was in november last year, which is pretty surprising considering that this is such a significant limitation of blender
See it as an indication of how important other things are as well. This is not the only "significant limitation" of Blender.
I just want to mention that this also affects UPBGE, which is a forked version of former BGE. I know that the project does not directly concern Blender now, but I believe it's a good thing for the community to have a viable game engine that is directly tied to Blender itself.
Thanks to EEVEE, now the engine shows quite impressive visual quality but it chokes when it comes to animating even just a few rigged characters because of this issue.
So, while not intending to argue that Blender should prioritize issues depending on their importance related to UPBGE, I think it'd be still nice to have this problem resolved since it's not just animators but many UPBGE users as well who are affected by it now.
Added subscriber: @chadking
Added subscriber: @JacobMerrill-1
for faster animation in general there are a few ideas that can actually increase the performance and accuracy of the deformations,
however this would need to be done on the GPU, so feedback being required would slow things down unless the feedback was chached.
https://www.youtube.com/watch?v=iZA9bl-t6J4
I think this could work 'inside the stack' with transform feedback (slowing it down)
so this would only be enabled if other modifiers exist after it in the stack, or something marks it to be fedback in py so it's evaluated data is availible.
Added subscriber: @Garek
Added subscriber: @matthewg.3d
Added subscriber: @LethalDumpster
Hopefully it wont be too much longer. I've been popping in to check the status of this for the past 2 years. (somehow not subscribing till now.)
And as a 3D artist and full time gameplay programmer, I have long determined the best tools for the job aren't the ones with the right features. But the ones which work and/or provide the performance to be usable.
As such, built-in game engine animation tools have been the only viable option on a budget. Blender providing sub 24 fps with only a couple AAA characters(in terms of polycounts. 40-100k each) vs having hundreds of frames per second with well over five times the characters in a scene within a game engine.
Personal experience being with Unreal Engine's Control Rig. An objectively worse tool for animating that is horribly limited in terms of features, which has badly sluggish and clunky UI/UX and poor setup time. Yet it having the performance to allow animating in 24 fps or more with several more characters, beats blender as an option quite unfortunately.
I cannot ask for game engines to improve their animation tools to be more intuitive, its bewildering the tools even exist in the first place. But given the software that Blender is, I should think it's understandable to request one of its larger features to be remotely viable for more people.
Though I will recognize that a lot of blender has been improved. Including areas which advance the status of better playback performance. And I assume some partially un-related code that has been improved is actually quite related and might be setting up a better foundation for incoming improvements for animation playback.
But as it stands, I and many others I personally know do not identify Blender as a usable animation tool. Some artists feeling forced to illegally attain other software's to be able to animate at all for their projects is a shame. This sentiment was true for sculpting, but has since recently turned around quite impressively. I hope to see some of the same magic that sculpting received be given to animation playback performance. We love blender, and we want to use it.
Added subscriber: @BClark
I think the the base line speed should be 30fps since film animation isn't the only frame rate, 60 fps ideal but it shouldn't fall below 30
Removed subscriber: @item412
Added subscriber: @AquaticNightmare
Added subscriber: @Cigitia
Added subscriber: @vignette
Added subscriber: @Nika-Kutsniashvili
Would honestly love a frame cache system for blender animation playback. It would especially help cut back on rig evaluation time and big heavy calculations in complex scenes..