/ by Matt
I’ve had a few questions about how we’re organising our work here, so I thought I might give a little run-down on it. It’s been interesting figuring out ways that we can collaborate together easily, while also being able to re-use models, sets and characters.
Blender offers a pretty wide range of options for managing assets with its library linking system, and we’re using it a lot. As well as appending things straight into a local file, you can link any blender datablocks like objects, object data, actions, or entire sets from an external library .blend file. Blender also allows multiple Scenes in each file, which can be completely independent, or have various datablocks linked between them. The trick for us was in deciding what features would suit us best (and what should be coded :).
As mentioned in this post from September, we’re using Subversion on a server in the studio to manage the files and revisions. Among other nice features like being able to roll back to past versions of files, one of the greatest advantages for us that we weren’t really anticipating, is that with the subversion commit and update workflow, everyone keeps a copy of the project’s entire folder structure synced locally on their workstation’s hard disk. This means that we can use relative paths in Blender (eg.
//../lib/machine/blah/file.blend ) to reference the same .blend files, textures, sounds, etc, no matter what sort of folder structure the subversion tree is situated underneath, and without having to work off a (comparatively slow) network share.
After some discussion, we settled on a system: We have a production folder, with a lib folder inside that containing all our libraries that we link, with subfolders for set and prop .blend files, subfolders for emo and proog, a subfolder for textures, one for audio, and so on. Also underneath production is a folder for each scene, with a number and short descriptive name. Inside the folders for each scene, we have separate .blend files for each shot, named as SCENENUMBER_SHOTNUMBER.blend . See the screenshot on the left for the production folder structure (with names blurred to prevent spoilers ;).
We decided on this for a few reasons. While making the animatic, we were generally working on a scene each, using single .blend files per scene, with a python script to change camera angles for each shot. This was nice and fast and flexible at the time, but it had drawbacks such as not being renderfarm safe. We could have also done one scene per .blend file, with separate Blender Scenes (that we call ‘Beans’ to differentiate between those and those in the movie) for each shot, but we decided against that too, since it’s far easier to collaborate with one .blend file per shot. This allows us to easily tweak things such as lighting setups per shot, but most importantly, it splits things up to allow us to collaborate. Unlike the animatic, we’re dividing up the shots between us as we progress, and need separate .blend files to work on and commit updates to SVN individually.
Blender has a feature where you can link Blender Scenes into another Scene as a Set, meaning that the objects show up ghosted and un-selectable and un-modifiable. This may be convenient for some purposes, but we’ve decided not to use it, as it doesn’t give up enough flexibility to make little adjustments to the shots, to tweak compositions, or cut away parts that don’t need to be there. Instead, we’re using a great new feature that Ton coded for us in the Orange development branch of Blender: Groups.
Groups are abstract names, that you can assign Blender Objects to. You can add and remove objects to and from groups at will, and you can also link the Group from another file, just as you would an Object. Grouped objects display with green wireframes in the 3D View. The advantage of groups is that since you’re only linking the Group name, you can make any adjustments in the library file, adding or removing objects, editing materials, whatever, and it all gets linked through to the other files dynamically. To instantiate these groups within the scene, you can use the ‘dupligroup’ feature of objects, which creates an instance of that group on that object (generally an empty). There’s even a nice little menu in the ‘Add’ menu, containing the available groups, which will add an empty with the specified group attached to it. We’re using these a lot for set and prop items, so we can have the convenience of being able to move things around, but without keeping local data.
It gets even better though. If the group contains an Armature, you can also assign pre-made actions to that group’s instance in the NLA, even if it’s just being instanced on an Empty. Type in the name of the Armature in the group that you want to assign the actions to in the ‘target’ field of a strip’s properties in the NLA. Since you’re really only dealing with an Empty, you can’t actually pose the armature, so unfortunately it’s not useful for main characters, but it’s still extremely useful for lots of secondary characters that we can assign little actions to, to give life to the scene. You’ll see what I’m talking about when you watch the movie ;).