Assets management
The main goal of a good asset management is to reduce clicking and searching time and to give a good structure and hierarchy to the "assets".
In a perfect world you would always save the "assets" in the right place so that you always find them. Therefore others are able to find your files because there are in the "right place".
Fixed "Digital asset management" Solutions
There are several solutions which try to handle everything for you. This "digital asset managment" (DAM) solutions like Alienbrain from Softimage/Avid are filesystems with a special file explorer which handles meta data like revisions and comments, approves etc.
Special plugins for your applications handle the save of assets to the right space with the right metadata while a special file explorer handles the files and metadata.
While this is a very powerful solution there are certain drawbacks. First of all the intern structure is predefined by the developers, and who says that this is right. If you pipeline does not match or has difficulties or you would like to have things for ergonomic reasons different you are bound to the level of customization the developers of such a DAM have given you though preferences, plugin APIs etc.
Also the price is a big drawback. Often you have to license a server and clients which can be a lot in bigger facility. And you have to learn a new application with all it's features and drawbacks. If an application is not supported by the DAM you have to create your own solution to bind it to the DAM.
Sometimes, especially when you deal with DAM which simulate or have their own file system you get into the situation where you just need to do something "dirty" like copying a file somewhere it does not belong to save you some time just.
While it is fully legitimate to prevent dirty moves often this fixed solution can be frustrating because instead of saving time you use valuable time to set metadata etc. or not being able to test things out dirty.
The poor mans "digital asset management"
The poor mans "digital asset management" is based on the fact, that you trust your employees and colleagues. It is in their responsibility and interest to keep the digital assets organized. While this is quite easy for small teams or single projects it may be a problem for bigger teams. Everyone has his own solutions for handling data. Some save files with numbers, some just name them in a logical fashion or you put a revision number like
Code:
dog01.ma
dog02.ma
dogFinal.ma
dogFINALFINAL.ma
dogLastCheck.ma
dogNEW.ma
dogVeryFinal.ma
(Example 1.1)
And here is the problem. Which is the last file? Which is the real "final" approval? And where to store it? It may be obvious to name the files only with serial numbers to be able to tell which file is the last one, but there is much more a "convention" can do.
Convention based "digital asset management"
(Credits goes to the people at capture-mm who established this conventions. In using them for my personal projects I developed them further and established some more conventions around them)
When someone or more people decide to do something in a particular fashion what they establish are "conventions".
So the idea is to use the normal windows / linux / mac file system but use conventions in the area of file placement and directory structure as well as file naming and metadata.
File naming conventions
As we saw in example 1.1 it is seductive to combine not only the revision or version of a file to the filename, but also a kind of metadata like in the example the comment "Final". To be able to do this in a controlled fashion we have to agree on a way how to do this so that the alphabetical order of files does not get disturbed.
In all file systems one way to show your files is not in the order of creation or (random looking) place where it was stored as data on the hard drive / hard drive index but to show them alphabetically. This only takes into account the alphabetical order while the sorting by creation date may be tempting to use to look for the "last" and therefore most advanced and "final" file. But creation time does not implicit priority or progress. So there are scenarios where you have worked on something but you are said to use the revision before this which obviously was created before that time. And in some cases you want to try out different branch from a file with the same level of development but small differences like for example try out a model with big eyes, small eyes and no eyes.
Each of this branch can be seen as a prototype which can be further developed.
To make the files more readable it would be nice to be able to comment the revision or branch so you have a human readable way of showing what the prototype is:
big eyes
small eyes
no eyes
And also in some cases you need a outstanding priority of a file to be able to mark special files in your way.
So to sum up we want to be able to have following information in our filename:
Own priority sorting (optional) e.g. Important, Not important, test/dump
File name e.g. dog
Prototype e.g. big eyes, small eyes, no eyes
Revision e.g. 01, 02, 03 ...
Comment (optional) e.g. prototype or user defined
Here's a way of doing this:
Code:
dog_p01_v11_headModeling.ma
dog_p01_v12_bigEyes.ma
dog_p02_v01_smallEyes.ma
dog_p03_v01_noEyes.ma
dog_p04_v01_freakyEyes.ma
(Example 1.2 - Convention file list in alphabetic order)
While this looks very complicated and long at the first glance it makes perfectly sense if you look at the details:
'dog' is the filename and should be of course short and descriptive
'p01' is the prototype, a branch or major change
'v11' is the version or revision, the number of state or change the asset is in
'headModeling' is a comment which can describe the prototype or revision or just left out.
Since we are sorting alphabetically the results are sorted by file name, prototype and then version.
Since these should be unique there SHOULD BE NO sorting by comment.
There will be no:
Code:
dog_p01_v12_bigEyes.ma
dog_p01_v12_biggerEyes.ma
But:
Code:
dog_p01_v12_biggerEyes.ma
dog_p01_v13_bigEyes.ma
(Example 1.3)
The difference is that the version shows the level of progression and therefore which file is most mature in the progress while sorting by comment is arbitrary.
Of course the comment is optional. Which means that if you just have enough information in you file name you don't need a comment. Here a real life example:
Code:
dog_p01_v01_modeling.ma
dog_p01_v02.ma
dog_p01_v03_uvs.ma
dog_p01_v04.ma
dog_p01_v05_shader.ma
dog_p01_v06_texturing.ma
dog_p01_v07_textureBlue.ma
dog_p02_v01_textureRed.ma
dog_p03_v01_textureGreen.ma
dog_p04_v01_textureRed_approve.ma
dog_p04_v02_rig.ma
dog_p04_v03.ma
dog_p04_v04_poses.ma
dog_p04_v05_cleanUp.ma
dog_p04_v06_rendering.ma
(Example 1.4)
This example shows a process of getting a character modeled, rigged and animated.
We follow each step to see what happened:
dog_p01_v01_modeling.ma
We started the file for modeling and wrote this to the comment tag.
dog_p01_v02.ma
Still modeling. Because we didn't use a comment it is obvious that we are still modeling. It is recommended to save in many steps so that when a file becomes corrupt or we did some irrepealable damage in the process we still can come back.
dog_p01_v03_uvs.ma
Modeling done. We are setting up the uvs.
dog_p01_v04.ma
Still setting uvs.
dog_p01_v05_shader.ma
We are about to give the model a shader.
dog_p01_v06_texturing.ma
We asign a texture to the model.
dog_p01_v07_textureBlue.ma
Some changes in the texturing process. Having a blue texture.
dog_p02_v01_textureRed.ma
Now it is getting interesting. We want to get approval for different prototypes:
dog_p01_v07_textureBlue.ma
dog_p02_v01_textureRed.ma
dog_p02_v01_textureGreen.ma
dog_p04_v01_textureRed_approve.ma
We got an approve for textureRed. Notive that we changed the prototype to 04 just to make this file the lowest and therefor most advanced in our process. We also could work on each of the branches seperatly if needed.
dog_p04_v02_rig.ma
We keep on working on the approved model by rigging it.
dog_p04_v03.ma
More rigging process.
dog_p04_v04_poses.ma
Starting the animation by posing
dog_p04_v05_cleanUp.ma
Cleaning up the animation
dog_p04_v06_rendering.ma
Setting everything up for rendering.
All this information could be easily extracted by only looking at the filenames following the convention. Every user could easily navigate through the state of the file even if it is not his own asset.
Like stated above, on assets which are not disk space intensive it is recommended to save as many revision as possible to be able to revert to a older file. The good thing about the comment is that it is optional. So we only need to comment if we need to or think a major step has been done.
Prototypes can revision separately which means that you can work on them simultaneously but you won't be able to see the most advanced progress by looking at the last file.
It is recommended to start on v01 on new prototypes to make more room for new versions. You still keep the order because revisions are in front of the versions.
To handle this it would make sense to split the prototypes into subfolders or like in the example above to decide on one and use it as a new prototype.
What if you have more versions than 99? Either you establish p01_v001 from the very beginning but I'd rather recommend just to start a new prototype (with v01) which maintains the order.
To establish this convention it is necessary to always add a prototypes and a version suffix to your files. Just make it a good habit to add "_p01_v01" to the file name of each new file. It makes perfect sense to use this not only in digital assets.
This document also is called cbdam_p01_v08.txt ;-)
But what about priority?
Sometimes it is good to override the order of filename, prototype and versions to give the files your own priority.
This can be done by using two digits at the beginning of the file.
Code:
01_dog_p01_v02.ma
02_dog_p01_v01_modeling.ma
(Example 1.5)
Although dog_p01_v02 would normally go after p01_v01 the priority tag at the begging reversed this order.
This can be very confusing but there are situations where you can use this wise. Just imagine that you have a certain process like in our 3D example:
1. Modeling
2. Shader/Texture
3. Rigging
4. Animating
5. Rendering
Knowing this you can establish instead of using dog as filename dog as directory and have this files there:
Code:
/dog/
01_modeling_p01_v01.ma
01_modeling_p01_v03.ma
01_modeling_p01_v04.ma
02_shading_p01_v01.ma
02_shading_p01_v02_texture.ma
03_rigging_p01_v01.ma
03_rigging_p01_v02.ma
03_rigging_p01_v03.ma
04_animating_p01_v01.ma
04_animating_p01_v02_poses.ma
04_animating_p01_v03_cleanup.ma
05_rendering_p01_v01_approved.ma
(Example 1.6)
Now we broke the process steps into priorities which saved us from using valuable comment space for the task.
Also we can use priorities to change the order of assets in a folder:
Code:
01_dog_p01_v01.ma
02_billy_p01_v01.ma
03_ant_p01_v01.ma
(Example 1.7)
Instead of the alphabetical ant, billy, dog order we forced the order dog, billy, ant by priorities. This way we have similar effects like using subfolders:
[CODE]
/01/dog_p01_v01.ma
/02/billy_p01_v01.ma
/03/ant_p01_v01.ma
[CODE]
(Example 1.8)
But within the same folder.
An useful way of using this is for the folder structure described later on.
Organizing
One drawback of this methods is that depending on your process you end up with a folder which contains a huge collection of files. Although it is obvious that the last progress is at the bottom of the alphabetical ordered list it may be frustrating to scroll down and look for the file from a file list pattern. A good way to avoid this is to keep folders for your process.
If your process is small just name it "progress". When you use other subfolders for your file like textures, shaders etc. it may be inappropriate to mix this folders with your progress folder. But you can use a prefix to get you folder at the beginning of the list. So use "_progress" instead of "progress" and then you get:
Code:
_progress/ (containing the old progress files of dog)
textures/
shaders/
dog_p02_v13.ma
(Example 1.9)
(On Unix based systems _ has a lower priority than the alphabet so that the folder "_progress" would come after shaders/)
You can also name it "_dog_progress" if you work on different files in the same folder. Or even better make folders for your progress:
Code:
01_modeling/
02_shading/
03_rigging/
04_animating/
05_rendering/
textures/
shaders/
05_rendering_p01_v01_toRenderFarm.ma
(Example 1.10)
This could be the content of our dog folder where the 01-05 folders keep the progress structured.
The final test
In practice you often end up with tests. "test" like the word "final" should be illegal in your file space.
First of all there is nothing "final" until it is final. And that is the reason why you shouldn't name it final. Understood?
From our convention system it is obvious that the last file in the order is the most advanced in progression. And this is what we use. When you have to change things on the (not so) final file you would end up with
Code:
dog_p02_v02_final.ma
dog_p02_v03.ma
or
Code:
dog_p02_v02_final.ma
dog_p02_v03_last.ma
or
Code:
dog_p02_v02_final.ma
dog_p02_v03_finalFinal.ma
dog_p02_v04_final.ma
(Example 1.11)
It is not obvious what has more priority. The word final or the order? Or the word last or finalfinal? Just avoid final and use comments like forRendering, approved or complete just to give a sense what this file implies but not what last state it is in. There is no final as there always might be changes.
George Lucas once said: "Movies are not released; they escape."
And Test? Test does not give any information about what you actually test. Often they are stored in arbitrary places because we "just want to test something out quickly". You end up with having tests everywhere and since they are tests some of them break some of them just nest in our file list and we don't know what they do.
A good alternative is to use the last priority tag on a subfolder to store these tests in. Because I don't like the word test I call it dump.
Code:
01_modeling/
02_shading/
03_rigging/
04_animating/
05_rendering/
99_dump/
textures/
shaders/
05_rendering_p01_v01_toRenderFarm.ma
(Example 1.12)
So we have a directory which is called 99_dump which makes it the last of the process folders and here we can store tests and files or progresses that we want to delete but we might have use for later on or as reference. You can as you see create more of there from the back like:
Code:
97_references/
98_toDelte/
99_dump/
(Example 1.13)
...if needed. It makes perfect sense to create this miscellaneous folders for each folder so you have no chance to create arbitrary test files in arbitrary folders. We get more details about these folders in the folder structure chapter.
Summing up our conventions
We use following components in our file name convention:
Priority: (optional)
To give a user defined sorting priority to the files and folders. We can use this for steps in a process
File name:
A short descrition of the file content or process
Prototype:
The branch or prototype of a files progress
Version:
the version or revision of the file
Comment: (optional)
A description of the step or state, user etc. of the file.
Example:
Code:
01_dog_p01_v01_moddelingByGeorge.ma
(Example 1.14)
We use "_" as seperators as they are supported by most file systems. To make whitespaces in filename or comments we use capitals:
will be:
(Example 1.15)
This helps readability while preventing whitespaces which can mess up some applications or older file systems.
Make it a good habit to at least add _p01_v01 to every file you store and (if file sizes allow it) to save often to new versions.
Assets, Workflows & Projectmanagement
