How can we keep our animators happy? A question we asked ourselves several times as we've gone through the different iterations of how we wanted playblasting and publishing to go. The key point we learned is that simplicity is more important than flexibility. This was our primary goal when we replaced the animators playblaster and set them up with publishing in RV.
The first thing we did was fully replace the built in Maya playblaster. If the user clicks the option box it opens up the below dialog. If the user clicks playblast, it automatically starts and uses either last used settings or project defaults. The main goal of this was to prevent the animators from having to learn anything new, but still be able to do everything we needed to integrate it into the pipeline.
The majority of the playblast settings are stored in preset files. From media settings like resolution and frame rate to scene settings like whether to use a hud or default lights. Preset files can be loaded from any directory, including project preset folders in perforce. Project level presets are always preferred and default, although the ability to choose any preset is allowed.
The playblaster gui is simple and only contains four options to worry about. The first is the camera, which defaults to a production camera if it exists, otherwise it uses the current views camera. Second is the preset to load all the video settings and scene settings from, the user can choose a project preset, or use the settings from their current scene. Third is the frame range, which defaults to the active Maya frame range, but can be switched to use the frame range defined in Shotgun for the shot, or a custom frame range. Lastly, the note that is placed as part of the hud for the bottom of the video.
Once the playblast finishes, it automatically opens up in RV. If the animator were to keep playblasting, it would replace the same instance of RV. Allowing the animator to keep one instance open and going at a time. Once in RV, the animator can verify the video, then choose to publish it by clicking a simple publish button.
Once they click the publish button they are then presented with the shot publisher as seen above. It consists of five options, four of which are filled in automatically and only need to be changed if desired. The revision is the next available version number, skipping numbers is prevented, but publishing over an old one is allowed. The variation is a change in artistic intent, usually from the director, typically main is our default. Representation is the format, typically hidden from the user if it could be calculated. Lastly is a description to be used in perforce and shotgun for the publish.
After the animator publishes their playblast, it is viewable in Shotgun and ready for review. The animator will be notified of any notes and can move on to other work. Once it is published, a Shotgun event daemon listens for the new publish and automatically creates FFmpeg based Qube jobs for the various outputs needed, like jpg's and a wav file.
After developing this workflow, we saw a large increase in the amount of playblasts being published, which was a great sign. We received lots of positive feedback about how much faster the process was and how much easier it was to do. This tool set ended up being a great success.