Alrighty! I am back . . . back with some awesome moves that arrived in the post, the early post . . . the post that hurts the most! Actually, today we are going to have a quick look at getting organised before you start your project. Exciting? Possibly not. Essential? Definitely.
Now, at this stage in your career you have probably been working on projects by yourself or with a couple of friends or classmates. If it’s the latter you would have noticed how quickly things can spiral out of control when you don’t organise things, especially if you have multiple people working on scenes.
Today I am going to focus on naming and setting up files as opposed to organise particular processes for modeling, rigging, rendering etc. As I have stated before, what I suggest here is not the only way (or the best way), it’s just to get you thinking about some of this issues.
In terms of file structure you might need to take into account the kinds of files that will be output from different software, where they should be rendered to, where are the temp directories, what is the approval process, will you publish versions that are reviewed so they can’t be changed etc.
I am not going to go into details about how you should name files as it might vary every case is different, but keep in mind things like using things like “lowercaseUppercase” (also known as camel case), “using_underscores_instead_of_spaces” and “not_using_reserved_characters!!”. A lot of this stuff just makes for consistency but some of it is crucial for scripting purposes. Your IT people or data wranglers may need to run batch scripts on files and, for example, the script might look at the number of underscores in a filename to decide what to do with it. If you name the file incorrectly, the whole things comes undone.
Once you have figured this out, work out your naming conventions for your scene files and your objects. Naming things sphere001, sphere002 and not parenting objects correctly etc is a sure way to get stabbed in the ear with a pencil! Why? Because somebody opening your file will have no idea what is going on. You have to assume that someone else is going to need to look at your files at some point and will need to figure out what is going on. See also the tips on scripting. It may be the case that your TD will need to run a script on, say, every current Maya file changing the name or attributes of a common object. If you haven’t kept with the naming conventions, it will screw everything up.
The same goes with work in progress scripts and renders. A method I have used before with good results is to name files as majorVersion_wipVersion, sooooo, something like:
comp_v01_01.shk
comp_v01_02.shk
etc
The first number is the major version, the second number are your WIP’s. When you submit for review, cut off the last two number so you are left with comp_v01. Not only does this cut down on having massive numbers of versions, but it also avoids your director having a heart attack! (”Version 78?!? What they hell are you doing?!”).
Same goes for your renders. This way you will always know where you are up to. When you submit version 01, move it to a published folder and copy it and immediately rename to v02_01 when you need to make changes. This way you will always know what the latest version is. *NEVER* go back versions and *NEVER* name anything with the word “Final” in it!
As always, comments or suggestions are welcomed!
ETA: Damnit, why won’t wordpress and Firefox add proper line breaks? You would think this would be a basic feature.
