Render Farm Possible in Premiere?

Question

I multi-machine render in in AE all the time.  (For those who don't know, that's using several different computers to render the same project faster.)
Can you do this in Premiere?  The closest solution I've come up with is rendering out and assiging frames to TIFF sequences on 3 computers like this:
Computer 1:  Frames 1-2000
Computer 2:  Frames 2001-4000
Computer 3:  Frames 4001-6000
But if computer 1 finishes first, it doesn't go on and help out its buddies, it just sits there like the last intern I had waiting to get fired and not looking around for anything to do, like move the 30 c-stands and sandbags to the grip truck instead of drinking pop and watching all of us work...
Oh yeah, render farming.
In AE you can click it to "skip existing files" (or somethign to that effect) so that if AE sees that frame 1001 is done already, it automatically skips to frame 1002, and on and on until every last frame is processed.
Anything like this in Premiere that I've HOPEFULLY just been overlooking ?

Answer 1

Here's the straight poop,
I don't know if they'll ever get render farming up and running for anything outside of 3d effects, but the reason it hasn't been built yet is the same reason render farming took so long to develop in the first place: the workflow.
Render farming doesn't output a single file.  Why?
It uses the FRAMES and outputs a number of them from each machine in the farm, all to the same location (on any chosen machine).  However, these FRAMES are simply picture files.  That's right guys, just single picture files.  The same is true for video files really, that they are made up of nothing but picture files being rendered to the screen at super fast speeds, but they are all bundled together.  In compressed video, you lose some of the quality of the images in favor of saving speed and space, but with lossless codecs you are actually processing every frame (or every single picture).  This means that you'd have to add that processing step to the workflow for render farming.
Steps originally:
Comp A process these files as images from frame x to frame y and store in folder z
Comp B process these files as images from frame v to frame w and store in folder z
and so on for every machine
Added steps for video rendering:
comp A frames x to y scan and compress to file a
comp B frames v to w scan and compress to file b
and so on through each machine until all are finished
finally: selected comp combine files a to (whatever)
However, with this function you may get extra I-frames or B-frames, and you'll end up with jitter in the final product.  For this reason, the logic holds that instead of processing the video compression on multiple machines and combining files at the end, full video render farming should use a DATA PROCESSING BALANCE algorithm, allowing one machine to pass data between the processors of other machines while handling the file build on it's own.  Separating the file on the fly (as it is being processed) is a more useful tactic.  Start with I-frame A and I-Frame B and send the processing to Machine a, take I-Frame B and I-Frame C and send to machine B and so on and so forth.  This allows there to be I-frame overlap, and all the writing is still done with a single machine, while the processing is done across several.
Of course, if you use the first set and change it so that the i, b and m frames over lap, then match them when putting the files together into one, you could, in theory, process it much the same as standard render farming.  The second method is only faster due to the fact that all the processing would happen on the fly, and the file would be all one file right away, removing the step of putting several files together, and it wouldn't matter which sections were finished first, how many machines there were, or how many frames overlapped, as the overlapping frames would simply overlap and all the others would fall into place.  The only bottleneck would be drive speed and fragmentation of the file, which could be a last step in finalization or an intermediate step along the way.  If you use a dedicated and allocated space for the storage, on the fly is the way to go; it also works if you simply run a defrag pass over the file when a section overlaps, thereby moving other sections forward or backward in storage so they line up properly; however, this could just as easily work at the end of the whole process.
From a logical standpoint, it works.  From a programming standpoint, it's a lot of work, and it's hard on a system.  Personally, farming out a few effects and then wrapping them in a lossless file for use while editing is easy enough.  And the quality of the preview is amazing.  Rendering out to a single full video file is saved for last or for the end of the day when go home to my family; that way I don't have to ***** about how slow everything was.  I can just relax and let the PMS'ing wife yell about how nothing is going right, let the kids yell "he did this" and "she did that", and enjoy the fact that my computers are more obedient.  They do what I say without slamming doors and pouting.