In a perfect world all software would work in all situations and all Scripting languages share the same syntax. In the real world my love for shake erodes at the command line and I need to learn Python (on top of Javascript, MEL, PHP and Perl).
The Probelm:
While Apples Shake as in Version 4.1 supports command line rendering through
shake -exec shakeScript.shk
and employs methods for adding a sFileIn node and adding a fileOut node it lacks in an important area. There is no way to do the following from the command line:
a) change an existing sFileIn node or change an existing fileOut node
b) change the inPoint and outPoint to be rendered to reflect a sFileIn's node frameRange
So any serious batch processing from the command line that takes different input movies with variable length, processes them and outputs them to different output movies with a descriptive name (like a version of the input movies name) is not possible in Shake at the moment.
But Shake is such a Unix beauty of a program and the shake script documents are easily readable text documents. So I set out to make a small Python script that adds exactly that functionality to the command line: a simple batch renderer.
After trying with a normal shell script that in the very early stages got scrapped because I got some kind of permission error while reading out the movie length information. Then I had a brief try in Perl but realized that my Perl is not sufficent and that if I learn a new script language it should be Python because - well - god and the world swears on Python these days. Especially the recent inclusion of Python into Autodesk Maya 8.5, Python beeing included into Blender 3D and about any and all cool new program in the visual FX area putting the python in the tamers basket it is quite clear that I should get familiar with it rather sooner then later.
So eight hours later I can release my first Python script which is a bit crude but does what its meant to do simply and well. I have not figured out why out of all the languages it must be Python that seems to win the script wars and some of the Python logic is not absolutely clear to me yet but coding was indeed almost fun at points (those where things worked as expected).
Preperations:
1.) make a Shake Script that does what you want to do.
2.) The Shake Script should have exactly ONE sFileIn (preferably you want to use one of the movies out of the batch so everything is set up right (pixel size, aspect ratio etc etc)
3.) and also the Script should have exactly ONE fileOut. While it doesn´t matter what path or name the FileOut is referencing too (it will be replaced in batch)
4.) it DOES matter that you make the fileOut a Quicktime Movie with your desired compression settings - otherwise the script will fail.
5.) save the Shake Script with a descriptive name
How the batch works:
1.) make a folder
2.) put the Python Script into the folder
3.) put your Shake Script into the folder
4.) put all the movies you want to have processed by the Shake Script into the folder
5.) navigate to the folder in the command line and make the folder current
cd drag`n`drop folder
(for the non terminal users)
6.) execute the script by
'./ShakeBatchRender.py'
7.) Watch your movies being rendered
Features:
1.) The script creates a Shake Script for every input movie. So f.e. you make a bluescreen key and it works on 9 out of ten 10 shots you can just open the one shot it didn´t work and adjust settings and render from within shake. So the sFileIn and the sFileOut and the frameRange is set correctly when you open the script for the problematic scene. The Shake Scripts are named
MasterShakeScriptName_InputMovieFileName.shk
2.) The scripts makes descriptive filenames for the output movie
InputMovieFileName_ShakeScriptName.mov
Caveats:
1.) the script only supports .mov for sFileIn
2.) the script only supports .mov for sFileOut
3.) the script should only be run ones. If you need to run it multiple times (to correct a problem) make sure you delete all the newly created ShakeScripts and Movies, otherwise you end up with multiple versions and duplications and a general mess.
4.) if the script does not run make sure the permissions are set correctly. Do this by typing the following in the command line:
chmod 744 ShakeBatchRender.py
Conclusion:
Its crude but I might develop it into something more interesting if Apple is making future versions of Shake (which I really really hope). If not then this is a crude hack to learn Python.
License:
Script is under GNU General Public License v2.0. See enclosed document called "COPYING_LICENSE.txt" for more information.
Download:
Download the Script with documentation and a tutorial folder here. (700kb)
Technorati Tags:
Python, Shake, CommandLineRendering, VFX
Rarely have I seen such an indepth discussion of the VFX pipeline for a film/short/trailer. While I really like medieval settings but not so much the war side and while I probably never will have the time in my life to play a MMPRPG (massively multiplayer role playing game or whatever they are called these days) I quite enjoy the the all 3d trailer with a huge amount of attention to detail. This must be one of those project that revieved a lot of personal love (you can tell from the little stories inside the bigger stories - the off the main focus details) and most of the stuff is very much handiwork - no automated scripts like Massive for the battle scenes (that means you have to place 7.000+ 3d orks by hand battling it out against each other). The crew talking is funny and engaging and even if you do not have a vested interest in 3d and vfx stuff this (2+ hours) talk is very mind opening and much of it is digestible for the non techie crowd - even if it is just to see the amount of work being put into a 4 minute trailer. 
Well everyone ever comlaining about the lack of development on the 3D tracking market can rejoice. Autodesk just bought out Realviz - known mostly for their Matchmover 3D tracking software but recently also for their 
