利用者:Hessiess/file management

How to manage your blender project files

When you begin with Blender, your projects are simple and consist only of single files. But should you so much as link to a texture file, an inter-file dependency is created. When dependencies exist, it is important to store files in an organised file tree to avoid future problems.

This article describes a simple directory system template that can be applied to your own blender projects. It allows assets to be built independently, then composed together into larger projects with ease. All while allowing the project in its entity to be moved from one machine to another and to different locations within the file system as a whole.

Please note that there are many different ways to achieve these goals, all of which have there advantages and disadvantages. The method described here was developed through years of trial and error, it is defiantly not sortable for every situation. Adapt and adjust as need be.

note to complete beginners

Unlike a lot of desktop applications, such as word processors, when you use an external media file like a texture image, blender does not(by default) store the image in the blend file. This creates a dependancy between the blend and any external files, such that if anything is moved, blender may not be able to find the images.

In a lot of ways, this is actually preferable. Should you edit the texture, blender will automatically load the latest version. However it does it does mean you need a strict file system.

The structure of an asset

The basic component of this system is an asset. An asset is simply a single blend file and any associated texture images. An asset could be a character, an environment or a component of an environment.

Within the file system, an asset is a directory. The main blend file lives in the root of this tree and all of the dependencies are stored in subdirectories. For example, if you were designing a character called Fred, you could have something like the following:

fred/
    | fred.blend
    | textures/
        | diffuse.png
        | bump.png
        | spec.png
    | refs/
        | front.jpg
        | side.jpg
    | fred/renders/
        | render_0001.jpg
        | bump.png

So long as the fred.blend file links to its assets using relative paths, this tree is an atomic unit. Unfortunately, Blender uses absolute paths by default. To fix that, select the 'Make all paths relative' option in the File->External Data menu and enable the 'Relative Paths Default' option in the preferences.

assets can be used simply by linking the blend file

Composing assets (assets with dependencies)

When developing larger projects, it is normal to have each object in its own blend file. This can be done easily using the system described above, each file becomes its own asset directory. However, where one file links to another, it is tricky to maintain re-usability.

A simple example of this is a house scene. A house contains rooms, rooms contain tables, chairs and cups. One way to do this is to create a directory structure like this:

my animation/
    | scenes/
        | house/
        | other scenes ...
    | props/
        | sofa/
        | table/
        | cup/
        | other props ...

But doing that makes the house scene dependent on the structure of that specific project, it would be difficult to then re-use it in a different project. A better way is to nest the asset directories, so that copying the top level directory always copies all the dependencies. For example:

house/
    house.blend
    | assets/ 
        | sofa/
        | table/
        | cup/

The house directory becomes an asset in its own right, it just happens to be composed of other assets.

The bigger picture

Up to this point, the main focus has been on producing file structures which permit easy reuse. But in some cases the reuse ability of a file does not matter, like in the scene files of an animated film. The environments, characters and props are all linked in from external files, only the animation data is local.

This is reflected in the structure of a projects root directory which is there to logically organise the assets and scene files. For an animated film project, the root could look something like this:

characters/
  | fred
  | joe
environments/
  | house
scenes/
  | scene_1/
      | scene_1.blend
      | refs/
          | walk.avi
      | render/
  | scene_2/
      | scene_2.blend
global/
  | assets/

Using version control

Humans are not perfect, we have a tendency to mess up. Imagine the situation, you have just spent several hours working on something, but you realise that it would have been better to do it in a completely different way. You want to go back to the file before you changed it, but the original file has already been overwritten.

Manual versioning

At some point or another, most computer users come across manual versioning. If you haven't it is simply storing versions of a file by incrementing a number in the file name i.e. charicter_1.blend, charicter_2.blend etc. While this appears to work at first glance, it completely disintegrates in practice. An outline of some of the problems follow:

Linking does not work

When you link to data from a different blend file, blender references that file using its exact file name. It does not check to see if there is another copy with a higher revision number. So, for example if you are working on a character saved as character_1.blend then link it from a different file to do some animation. If you then go back and change the character, saving it as character_2.blend, the linked file will still point at the older version of the file.

Clutters the file system

By storing each version as its own file, the file system gets cluttered up with copies of the same file. This can be a huge problem for organisation as it can be difficult to find the file you want to change.

No indication of what was changed where

If you leave a project for a week or two in order to work on something else, then come back to it later, there is absolutely no indication of what was changed in which version. If at this point you want to go back to a previous version, you must go through all of the files manually to find the one you want.

Space inefficient

Because each version is stored as a complete copy of the file, a lot of disk space gets wasted storing redundant data.

Working collaboratively is impossible

If a project is being worked on collaboratively, or even by one person from more than one computer, it is essential that there is some way to merge the changes back together. This can be done manually to some degree, but as the number of files and artists goes up, it becomes a royal pain in the ass.

Version Control Systems

Version Control Systems(VCS) are programs designed to solve these problems. Effectively they work by adding another dimension to the traditional file system: time. The state of a file tree may be snapshotted at different points in time. Then if you want to go back, you just revert to one of the snapshots.

Until recently, version control systems had a high barrier to entry. The traditional systems like Subversion and CVS all require a central server to operate, something most people do not have. Thankfully, the modern trend for decentralised VCS's has removed this barrier.

Versioning blender projects with Git

There are a number of decentralised version control systems including Bazaar, Mercurial and Git. With regards to functionality, they are almost identical; which you choose to use is mainly a matter of personal preference. I have chosen to use Git for this tutorial as it is what I use myself, however it is easily applicable to the other systems as well.

This will be described twice, demonstrating how to use the software with the command line interface and a GUI front end.

Installing git

[Describe how to install git]

Git from the command line

If you are creating a new project, start by setting up a file tree as described in the first section of this article. Then create your various asset blend files.

Next open a terminal and cd-ing into the root directory of your project, then run:

$ git init

This command creates a new repository in the current directory. Repositories store the different versions of the files and are stored in the '.git' directory. Now run 'git status', you should see something like the following:

$ git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	characters/
#	scenes/
# nothing added to commit but untracked files present (use "git add" to track)

The Git status command tells Git to look at the current directory tree and see what files have changed. Git only tracks the files that you tell it to, so it currently reports the project files as untracked. To make Git track a file, it must be added using the 'git add' command, running 'git status' again shows they have been added.

$ git add .

$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#	new file:   characters/charicter/charicter.blend
#	new file:   characters/charicter/textures/bump.png
#	new file:   characters/charicter/textures/diffuse.png
#	new file:   scenes/scene_1.blend

All that is left do do is store the first snapshot of these files, which is simply a matter of running 'git commit'. Ignore the '-m' for now.

$ git commit -m "Started a new blender project"

Congratulations, you have created your first commit, now you can make any changes you want without worrying. Git has safely stored a copy of all of your files. Before continuing, make some changes to your files.

Going backwards

The next thing to demonstrate is how to go back to an older version. However before that can be done you need to commit your current changes. Run the 'git status' command and take note how git has tracked what files have been changed. Next run 'git add .' to add the changes and git commit -m "" to save them. The part in quotes after git commit is called a commit message. Commit messages are there to tell you what was changed from one revision to another. Write a commit message which explains what you have done.

Now run 'git log':

$ git log
commit d84a5dfd4c249c9a479baab2631bfb7edf3c405d
Date:   Sun Nov 7 19:41:10 2010 +0000

    blocked animation for scene 1

commit 7ff679f2efb2bc5f80c5e1c7465fb0fb033926a7
Date:   Sun Nov 7 19:39:54 2010 +0000

    created new blender project

Git log shows a list of all the commits that have been completed, you can see when a commit was created and the corresponding commit message. The apparently random sequence next to the word 'commit' is that commits unique identifier. If you want to go back to the first commit you made, just check it out. Note that the commit identifier will be different, copy it from git log.

git checkout 7ff679f2efb2bc5f80c5e1c7465fb0fb033926a7

And thats it, You have created a new repository, told Git to track the files, created your first commit and learned to undo changes.

These are the most important aspects of the Git version control system, however this tutorial has left a lot of things out, such as how to work collaboratively. You can find more information on Git usage at the following URL.

http://hoth.entp.com/output/git_for_designers.html

Git from the gui

[to be written]