Faster Animation Playback #68908

Open
opened 2019-08-20 21:05:25 +02:00 by Dalai Felinto · 68 comments

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:

  • 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: #73429 (Approach Faster Animation Playback)
Engineer plan: Will be created per improvement.
Related Tasks

  • {icon circle color=red} #75134 (TaskScheduler Improvements)
  • {icon circle color=red} #75120 (DrawManager: Improved Task Scheduler)
  • {icon circle color=red} #75208 (Dependency Graph Evaluation Optimizations)
  • {icon circle color=yellow} F-Curve Evaluation Optimizations
  • {icon circle color=yellow} Profile and optimize modifiers (some suggestions are archived in #75207)
  • {icon circle color=yellow} Motion Path Performance
  • {icon circle color=yellow} Optimize VSE Playback for Animators
  • {icon circle color=green} #75124 (ActionEditor: Keyframes Drawing)
  • {icon circle color=green} #75127 (ActionEditor: Add callback function to ANIM_animdata_filter)

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

  • #68996 (OpenSubdiv GPU acceleration)

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.

**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:** * 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:** #73429 (Approach Faster Animation Playback) **Engineer plan:** Will be created per improvement. **Related Tasks** * {icon circle color=red} #75134 (TaskScheduler Improvements) * {icon circle color=red} #75120 (DrawManager: Improved Task Scheduler) * {icon circle color=red} #75208 (Dependency Graph Evaluation Optimizations) * {icon circle color=yellow} F-Curve Evaluation Optimizations * {icon circle color=yellow} Profile and optimize modifiers (some suggestions are archived in #75207) * {icon circle color=yellow} Motion Path Performance * {icon circle color=yellow} Optimize VSE Playback for Animators * {icon circle color=green} #75124 (ActionEditor: Keyframes Drawing) * {icon circle color=green} #75127 (ActionEditor: Add callback function to ANIM_animdata_filter) 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** * #68996 (OpenSubdiv GPU acceleration) 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.
Author
Owner

Added subscriber: @dfelinto

Added subscriber: @dfelinto

#68909 was marked as duplicate of this issue

#68909 was marked as duplicate of this issue

Added subscriber: @Phigon

Added subscriber: @Phigon

Added subscriber: @WilliamReynish

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.

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

Added subscriber: @dgsantana

In #68908#805145, @WilliamReynish wrote:
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 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.

> In #68908#805145, @WilliamReynish wrote: > 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 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: @item412

Added subscriber: @sozap

Added subscriber: @sozap

Added subscriber: @MarcelLegindi

Added subscriber: @MarcelLegindi

Added subscriber: @brecht

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.

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.
Author
Owner

Added subscribers: @Mets, @Hjalti, @Sergey, @Jeroen-Bakker

Added subscribers: @Mets, @Hjalti, @Sergey, @Jeroen-Bakker

Added subscriber: @StanislavOvcharov

Added subscriber: @StanislavOvcharov
Jeroen Bakker changed title from Faster animation playback to Faster Animation Playback 2020-01-27 14:13:24 +01:00
Contributor

Added subscriber: @RedMser

Added subscriber: @RedMser

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz
Member

Added subscriber: @JorgeBernalMartinez

Added subscriber: @JorgeBernalMartinez

Added subscriber: @Scaredyfish

Added subscriber: @Scaredyfish

Added subscriber: @AditiaA.Pratama

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

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: @Pipeliner

Added subscriber: @CobraA

Added subscriber: @CobraA

In #68908#860797, @LucianoMunoz wrote:
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

> In #68908#860797, @LucianoMunoz wrote: > 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

Added subscriber: @LahceneB

Added subscriber: @LahceneB

Added subscriber: @Coverop

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

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.

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

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

Added subscriber: @YutaroFukagawa

Added subscriber: @YutaroFukagawa

Added subscriber: @seviscache

Added subscriber: @seviscache

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

In #68908#860797, @LucianoMunoz wrote:

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?

If its posible integrate Hydra/USD in the viewport to improvement playback animation? > In #68908#860797, @LucianoMunoz wrote: > > 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?

Added subscriber: @SamGreen

Added subscriber: @SamGreen

Added subscriber: @electronicpulse

Added subscriber: @electronicpulse

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

In #68908#878240, @seviscache wrote:
If its posible integrate Hydra/USD in the viewport to improvement playback animation?

In #68908#860797, @LucianoMunoz wrote:

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 :)

> In #68908#878240, @seviscache wrote: > If its posible integrate Hydra/USD in the viewport to improvement playback animation? > >> In #68908#860797, @LucianoMunoz wrote: >> >> 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 :)

Removed subscriber: @YutaroFukagawa

Removed subscriber: @YutaroFukagawa
Member

Added subscriber: @dr.sybren

Added subscriber: @dr.sybren

Added subscriber: @lrevardel

Added subscriber: @lrevardel

Added subscriber: @ckohl_art

Added subscriber: @ckohl_art

Added subscriber: @MeshVoid

Added subscriber: @MeshVoid

Added subscriber: @pauanyu_blender

Added subscriber: @pauanyu_blender

Added subscriber: @2046411367

Added subscriber: @2046411367

Added subscriber: @acorn

Added subscriber: @acorn

Reference Maya playback cache code?

Reference Maya playback cache code?

In #68908#1054417, @acorn wrote:
Reference Maya playback cache code?

Where is Maya playback cache code available for download?

> In #68908#1054417, @acorn wrote: > Reference Maya playback cache code? Where is Maya playback cache code available for download?
Author
Owner

@acorn we don't discuss, mention, refer to non open source solutions in the Blender channel.

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

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](https://devtalk.blender.org/t/2020-11-12-animation-rigging-module-meeting/16092) for more information.

Added subscriber: @mysticfall

Added subscriber: @mysticfall

Added subscriber: @T.R.O.Nunes

Added subscriber: @T.R.O.Nunes

Added subscriber: @RelyGFX

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

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.

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.

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: @chadking

Added subscriber: @JacobMerrill-1

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.

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: @Garek

Added subscriber: @matthewg.3d

Added subscriber: @matthewg.3d

Added subscriber: @LethalDumpster

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.

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

Added subscriber: @BClark

Added subscriber: @BClark
Member

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

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

Removed subscriber: @item412

Added subscriber: @AquaticNightmare

Added subscriber: @AquaticNightmare

Added subscriber: @Cigitia

Added subscriber: @Cigitia

Added subscriber: @vignette

Added subscriber: @vignette
Contributor

Added subscriber: @Nika-Kutsniashvili

Added subscriber: @Nika-Kutsniashvili
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:36:39 +01:00

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

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..
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
Interest: X11
Legacy
Asset Browser Project
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
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#68908
No description provided.