Rendering
From 2009 48 Hour Film Project
This section is a chunk of notes based on our experiences in last year's event. It's in our best interest to mitigate those problems well in advance. Specifically, anyone dealing with the Render side of things in this project (Bob, Hal, Mark, Jeff, Andy) should really go through this page carefully.
One of the biggest things that kicked us in the teeth last year was insufficient testing on our render pipeline. That hurt us a lot. The good news, though, is that we learned from those mistakes and last year could essentially be considered a test run for this year. So this year, we're a bit more prepared. As it stands, we have 4 render farms at our disposal for use; 2 home-brews and 2 commercial farms. Here's the crux of what we know:
Contents |
Versioning
Blender 2.49 just came out. My preference would be to standardize our pipeline on that version (or whatever the bugfix release for it is) I can almost guarantee that Mark's and Jeff's farms will be running Blender 2.49. I need to shoot an email at ResPower and BlenderFabrik to make sure they'll support that version of Blender when the event comes up. Otherwise, we'll either have to drop those farms or animate in a Blender 2.48-compatible way.
Linked Libraries
It gets a little tricky here because there are three different render managers at work here:
- Animux/FarmerJoe: Mark's and Jeff's farms are controlled via FarmerJoe. A limitation of FarmerJoe is how libraries are linked. Library .blends cannot be more than one directory deep from the shot .blend. So to facilitate this, our directory structure will have to be relatively shallow. The good news is that nested links (shot linking to a mesh library linking to a material library) work just fine. We will use this directory structure as our primary base. Animux comes with a blender 2.48a, which I think can be updated to the latest current version.
- Submitting a job on either Animux farm requires that we SSH to the farm and launch the following command from the root of our project's SVN checkout:
blender -b shot[XXX].blend -P farmerjoe_submit_cli.py
- ResPower: We discovered (way too late) last year that ResPower does not support relative paths when linking to library files. You must use absolute paths linked via a virtual "Y: drive". This means that we'll likely have to have at least one Windows box to get this set up. Perhaps a script could be written to quickly swap paths from relative to absolute Y paths? Nested links also work fine in ResPower.
- BlenderFabrik: Currently BlenderFabrik allows linked libraries with relative paths... but with one caveat: library files have to reside in the same directory as the shot file. As it stands, in order to use BlenderFabrik, we'll have to do something similar to ResPower... but rather than use absolute paths, we'll have to move libraries up a directory and change the paths there. Again, this could probably be automated with a script... but it would need to be done. The folks at BlenderFabrik are trying to allow a directory structure for libraries, but I'm not sure if they'll have that working by the time we need it. Nested links work fine, though.
Farm Management
On this point ResPower and BlenderFabrik have an advantage over the FarmerJoe farms. ResPower and BlenderFabrik have web-based interfaces that allow you to start, stop, and monitor render progress. FarmerJoe offers web-based monitoring, but jobs have to be launched from the master node from within the Blender interface. Last year we played with VNC and nxclient to attempt this, but bandwidth and connection speeds were an issue here. It's a bit ridiculous to load up the whole Blender interface just to launch a render job. Ideally, I'd prefer logging via SSH and launching the job from the command line.
Bassam has hacked the FarmerJoe python submission script to allow submissions to FarmerJoe via the command line. This should drastically improve things for us. We doneed to test it, though. It's currently in SVN in the /misc directory.
Process
Last year we did not get the opportunity to follow through with the process we'd originally planned. That is, block out the animation early with special attention paid to camera movement. With the camera movement for each shot planned out and keyed, we would consider the camera animation "locked down" and frozen... allowing us to send background renders to the farm early on. As those backgrounds are being rendered (perhaps in EXR if we're conservative on which passes we use), we'll be animating the characters in each shot. When the characters are animated, they're sent to the farms separately and rendered as PNGs (possibly with z-buffer) and then composited with the pre-rendered backgrounds. I still think that this is a solid process that will allow us to get good flexibility in storytelling without sacrificing production speed. The final composites should be fast enough that farms won't be necessary for that step and we can cook those locally once the comp is complete.
Andy will be heading things up on the compositing side. However, since we're doing this a bit piecemeal, the final comp rendering needs to be done either locally in Richmond or on one of the Animux farms. The reason for this is that I don't think the commercial farms will let us use their farms for image compositing. This only concern I have here is the upstream bandwidth that Mark and Jeff have. Comments guys?
Animux Farm upload speed is 2Mbps. Download is 15Mbps.
Resolution/Framerate
The deliverable product must be in NTSC SD format (29.97fps, 720x480). Last year we cheated and cut corners by working at 24fps and rendering letterboxed SD video. I think this plan is still viable; it cuts 6fps and 75px off of our render times. Of course, the post-process step of converting back to NTSC is something we had a bit of trouble with at the end of last year's project, so we need to get that process hammered out early. I think we were ultimately able to use an ffmpeg command to do the pullup/pulldown... but this needs to be confirmed.
