Scene Performance On Sprite Fright

One of Sprite Fright’s earliest goals was to improve viewport playback speed within Blender. This desire can be traced way back, even before pre-production.

Developer Jeroen Bakker and others have introduced many optimizations on the playback speed front, including overrides (developed by Bastien Montagne, a significant improvement on the old proxy system). Purely for your curiosity, here are some very rudimentary performance tests from Sprite Fright’s production environment.

The tables below show frames-per-second for two separate computers running two scenes, and show how frame rate is affected as more and more characters and elements in the scene are enabled. Note that usually you don't need to see everything while working on any given shot, but of course the less you have to juggle the visibility of various elements to gain the desired performance, the smoother your workflow will be.

Shot file (Rex, 13 Snails + Set)

Previz file (Rex, Victoria, 8 Sprites + Set)

About the scenes:

• The frame rate is capped at 24. We can always hit that number as long as there is only one character on-screen.
• There is no baking or caching of any kind involved here. We tried to keep life simple for this project, by keeping character rigs reasonably optimized so there isn't a major need for caching.
• Simplify is turned on, so there is no Subdivision Surface, but some "medium-heavy" modifiers like Corrective Smooth and Shrinkwrap are enabled.

About the rigs:

• The amount of shape keys on these rigs is insignificant (can be counted on two hands).

It’s hard to make a dent in Blender's playback speed with drivers and bones. By far the most important thing here is the number of vertices being deformed by Armature, Corrective Smooth, Shrinkwrap and Lattice modifiers. The characters on this project are reasonably simple, so we can use the same model for animation and render, and we don't necessarily have to use a mesh proxy system (so far at least). This also has the benefit of letting animators work with something that is very close to the final result, which is a high priority for us.

Conclusion

I think today's viewport playback performance is very impressive compared to previous versions of Blender, and while I still look forward to more advanced features like caching systems or a faster Armature modifier, these aren’t vital for Sprite Fright. Not having the viewport run at two fps was vital, and that goal has already been achieved!

P.S. Pablo Fournier's computer just got an upgrade, thanks to these performance tests and the generous support of Blender Cloud subscribers!

For more Demeter, see this post on what he's learned from the production so far. And be sure to check out the weekly logs for rigging-related goings-on.