diff and version manage blender work

Question

Are there solutions / best practices for dealing with the Version Management Problem when working on larger blender Projects?

Explanation: Version management means to keep track of who did what, when and why. Blender is a huge GUI driven application, but the work done in blender is typically comparable in complexity with the task of developing software. In such a setup, it is no longer possible to keep track of changes just by looking into the GUI. To be able to work effectively, we need tool support to answer the mentioned questions on a daily basis.

• are there better solutions available than just checking in the blend file as a binary blob into some SCM system (Git, Mercurial, SVN, ...)?
• maybe there are specific filters or exporters available which allow to transform the blend files into something which can be version managed with the tools known from software development?
• branching and merging: are there tools or known methods to integrate changes done by different people working in a team on a common project, but possibly on different branches or development lines?

Of course binary diffs in images and video footage are also relevant, but there isn't much to be done with these, beyond just noting that you're using a new version of some externally linked binary media.

Answer 1

For best practices I would recommend to learn from larger projects done with blender. You could look how Big Bug Bunny was organized.

• First don't have a team editing one large .blend file, have different folders for textures, material libraries, scenes, characters and so on. Each of these file can be versioned in a Version Control System (VCS).

• Have different scenes which only reference all the used models (link instead of append). This makes it versionable. When someone decides that a model of a character looked better a week earlier, you could restore this character from the VCS.

• To track the changes made on an individual item the VCS comment / history should be used.

• Unlike in software development you wouldn't be able to create branches and merge them back into a head revision. Technically this is because the files are binary and no meaningful difference can be extracted for merging. You usually need a branch when your software is deployed to a production environment and develop new features in a branch and fix bugs in the production version or vice versa. When the new features are scheduled for release you would merge features and bug fixes. But this doesn't happen when creating an animation, when a movie is out it can't be bug fixed nor would new features be added. Having that said it is probably not as painful as in the field software development not to have the ability to merge.

• In order to debug settings that were unintentionally changed and lead to undesired effects. The settings could be compared between two revisions of a file as described here: Get a diff between two .blend files

Which VCS should be used?

This basically depends on the support of your platform used, the experience the team members for details see:

• SVN, Git, Mercurial, and CVS – Comparison of Version Control Software
• Using Mercurial Version Control with Blender Projects ^{from iKlsR's comment}

Answer 2

I've been using Blender's Python API to develop Blender models as Python scripts in text files. I can write comments into my code, version control using git, and generally write "Blender programs".

I start with baseline.blend, which is a completely empty Blender scene. The default cube/camera/lamp have all been deleted, and I've set the windows up the way I want them. Specifically, a top perspective 3D view on the left, a timeline below it (I do a lot of physics and animation) and a Python Console on the right (yes, I use it a lot too).

Then, I create a UNIX script with the following header:

#!/bin/bash
"exec" "blender" "baseline.blend" "--python" "$0"

import bpy

This is a published method to start a script in Python, followed by the import command required to bring in the Blender library.

Now I can start doing things like this:

# THE CAMERA

bpy.ops.object.camera_add()
camera = bpy.context.active_object
camera.location = (0,0,30)
camera.rotation_euler = (0,0,0)

When I run the script, it starts a fresh instance of Blender, loads baseline.blend, runs the entire script, then leaves me staring at my model on the left and Python ready to go on the right.

So far, about the only thing I've found that I can't do is modify the user interface, since the script seems to run before the GUI has been initialized. That's why I have a simple .blend file to start with.

Remember the Dominos tutorial? I redid it in my workflow. Here's how I created the dominos:

for y in range(5):
   bpy.ops.mesh.primitive_cube_add()
   bpy.ops.rigidbody.object_add()
   domino = bpy.context.active_object
   domino.location = (0,y,1)
   domino.scale = (.5,.2,1)

Here's a little more advanced code snippet. I'm animating electrons orbiting a nucleus, and I want my fcurve interpolation to be linear. So I do this:

for obj in orbit1, orbit2:
  for fcurve in obj.animation_data.action.fcurves:
    for kfpoint in fcurve.keyframe_points:
      kfpoint.interpolation = 'LINEAR'

I'm pretty happy with it.