Render Farms 2005-04-08 - By Andy Jones
Back At PLF we use BatchServe and are semi-content with it, in that we are usually able to render 2K frames for film jobs. The big issues we still run into are caused by poor memory management in Windows leading to XSI crashes which BatchServe handles very ungracefully (machines freeze and stop rendering until someone intervenes). I agree with the jist of what everyone is saying -- BatchServe isn't a good idea unless you want to use it as a starting point for some extended development. And if you choose to go with a Windows farm, go ahead and kick yourself now so you won't have do it later while you're scrambling to get your frames to render. I think the underlying concepts in BatchServe are really good, but it's not a finished product. We've been talking to Softimage about ways to get the product moving forward again, and I think we're nearing a resolution.
Ultimately, I think the only lasting solution to the render pipeline is to have a completely open source project that we can all contribute to and benefit from. Facilities will always need to have the power to customize their pipeline on a moment's notice, but in most cases, for every last-second hacky fix that has to be made in the middle of a production, there is a more robust feature that could be incorporated into an official release. I think there are a lot of small to mid-size facilities right now that have the ability to make those types of fixes to a render pipeline, so I think the talent base is there. We're just missing a central authority that can supervise the collection, refinement and incorporation of the improved code.
That's why I'm sort of excited about drqueue, despite not really knowing much about it. Unfortunately, their website doesn't seem to be working right now (not a good sign). Maybe the guy who made it is just hosting it out of his house or something. You can still see the cached version of the site on google if you search for drqueue. I sent an email to the drqueue guy, so hopefully he'll get it going again. In the meantime, you can download some files at <http://projects.blender.org/projects/drqueue>. I think maybe that's a slightly old version, though.
-Andy
kim aldis wrote:
> > > > >>-- --Original Message-- -- >>From: owner-xsi@(protected) >>[mailto:owner-xsi@(protected)] On Behalf Of Bernard Lebel >>Sent: 08 April 2005 16:29 >>To: XSI@(protected) >>Subject: Re: Render Farms >> >>See [Bernard] below... >> >> >> >> >>>It does only XSI >>> >>>It won't render Fxtrees. >>> >>>It won't run scripts. >>> >>> >>[Bernard] Well, one thing though it that at Action Synthese >>it did FxTrees and scripts, and could do mr standalone if we >>had the licenses. >> >> > >Does it? Didn't know that. > > >>[Bernard] Well, one of my full-time dutie, with my co-td >>there, was to look in that specific aspect of render farming. >>For example, there was a version of XSIBATCH that had a bug >>with skip rendered frame, so we had to disable altogether on the farm. >> >> > >I've never used anything other than skip rendered frame and I've not seen a >bug there since way back in version 1. But then Batchserve doesn't use skip >rendered frames, does it? > > > > >>There were a lot of weird things going on. For example, I had >>a scene with a reference model containing instances that when >>rendered on my machine, either in XSI or XSIBATCH, would >>render fine. But on the farm it would render "invisible". I >>had the same XSI installed on my machine as on the farm.... >>go figure. Things like that occured on a dayly basis. >> >> > > There have been for a long time issues with reference models and it's only >in recent versions - 4.2, not 4.0 - that they've become even remotely >reliable. I also know that for years there's been problems with Xsi messing >with UNC paths, converting them back to mapped drives at random. Anything in >Xsi that deals with external files is prone to problems but I'd say these >are more general XSI problems rather than specific XSIbatch problems. > > > > > > >>Cheers >>Bernard >>--- >>Unsubscribe? Mail Majordomo@(protected) with the following >>text in body: >>unsubscribe xsi >> >> >> >> > >--- >Unsubscribe? Mail Majordomo@(protected) with the following text in body: >unsubscribe xsi > > >
--- Unsubscribe? Mail Majordomo@(protected) with the following text in body: unsubscribe xsi
|
|