Re: [K3d-development] DrQueue wiki talk page
Brought to you by:
barche
From: Daniel M. <dsm...@gm...> - 2006-12-29 21:46:03
|
On 29/12/06, Timothy M. Shead <ts...@k-...> wrote: > On Thu, 2006-12-28 at 14:16 -0800, Joe Crawford wrote: > > On 12/21/06, Timothy M. Shead <ts...@k-...> wrote: > > > On Thu, 2006-12-21 at 00:04 -0800, Joe Crawford wrote: > > > > > > > Man, we should jump on this! It would be great to have Dr Queue integration... > > > > > > You never mentioned this before, Joe ... care to elaborate > > > > Dr Queue is a program that handles rendering by multiple computers > > over the network. Basically, it splits the job into tasks (usually > > frames) and then tells each computer to render frames of the animation > > separately. > > > > Its very valuable to anyone in real production environments, where the > > complexity of scenes usually requires that more than one computer be > > used to render them. > > > > If the guy is volunteering to help, it would be great if we could make > > k3d dr. queue compatible. > > For a complete list of K-3D use cases and requirements, see > > http://www.k-3d.org/wiki/Network_Rendering > > My question was whether drqueue actually sees any use - because the > current rendering code is already has about 80% of the required > functionality, drqueue integration may-or-may-not be worth the effort. > Does anyone know what the longer term plans for Aqsis, r.e. multi-threading/parallelization are? I ask because the right rendering code and a mosix cluster would mean that a different tool may be better. Every man and his dog seems to be offering renders these days so an abstraction layer/process of one form or another seems like a good idea. Does/will Dr Queue offer post production functionality, such as passing output to GIMP/Python imaging pipelines? |