13th Aug 2021 | Open Movie | Sprite Fright
The different production steps of a CG production pipeline are usually spread out over individual files. In order to bring the animation of a character to the lighting file you need an efficient workflow.
In this article you will learn how we arrived at this workflow for Sprite Fright.
There are different approaches to consider to find the caching workflow that fits your pipeline best.
Blender has a great system that lets you link any datablock from another .blend file. Blender Studio makes use of that feature in the lighting file by linking in a collection from the animation file that contains all animated assets.
Blender Studio uses Subversion to manage all production files. Classical versioning of files (file_v001.blend, file_v002.blend) can be omitted that way. Everyone works with a local copy of the SVN repository and any changes are committed which results in a new revision.
Because there is only one animation file per shot that is under version control by Subversion, the lighting file always has the latest animation linked in. This link only needs to be setup once, which is timesaving and does not require a lot of tooling. By committing a new revision of the animation in the SVN repository you also update the animation in the ligthting file.
This dynamic link also brings risks. If for some reason an animation file is corrupt or wrong in any way, all the other files that link to it will fail or contain wrong data. A renderfarm that also constantly accesses these files makes it even more problematic. For this workflow it's quite useful to have Subversion so you have a local copy of the repository and jump between different revisions.
The alternative to a dynamic link is to cache the animations to disk. You could for instance create an Alembic cache for each asset in the animation file and load this cache on the asset in the lighting file. This workflow has the advantage that you can get rid of a lot of overhead that is not necessarily needed for lighting, like the rig and have an optimized rendering version of the asset. By storing the Alembic caches outside of the SVN repository you can introduce versioning and have the option to jump between different cache versions in the lighting file. Usually these caches are also quite fast to playback.
On the other hand this workflow requires a lot more management and tooling. Caches need to be constantly updated and creating them can take up quite some time. Also Blender does not support all features of Alembic yet. You need to find a workaround to handle things like animated object visibilities. Importing a cache on an asset with lots of objects is almost impossible to do by hand and requires some extra tooling.
Because the Blender Studio was not quite sure which route to take, I developed the cache-manager add-on that streamlines the export and import of Alembic caches on a collection basis.
The goal of this add-on was:
This video showcases the whole process of exporting and importing caches with the cache-manager add-on:
As you can see the cache-manager streamlines this process by automating many steps which would be very cumbersome to do by hand.
Working on a Collection basis gives you a lot of flexibility on what you want to include in the cache. Usually you only want to cache assets that are animated. You can also export or update caches of specific collections by using the export button in the UI list.
The cache manager saves a lot of time on import by adding a Mesh Sequence Cache Modifier and a Transform Cache Constraint on every single object and assigns the right object paths. On top of that it saves object visibilities, driven values and animated custom properties in the cacheconfig.json, which is something that is currently not supported by Blenders implementation of Alembic. On import all this information is applied by keying the properties with their corresponding values.
Another cool feature is the interactive version switching that you can see in the video at 01:50. On version change it actually changes the loaded Alembic caches to the specified version and also re-keys all properties that are defined in the cacheconfig.json.
Without additional tooling it's very hard manage disk caches properly. Fortunately there were many improvements happening for the library-override-project, which enabled the Blender Studio to use complex linking setups of many .blend files and enabled us to take the Linking approach which was explained earlier.
The cache-manger add-on is part of the Blender Studio Tools repository. If you are interested in the add-on you can download the code here.