On 29/12/06, Timothy M. Shead <tshead@...> wrote:
> On Thu, 2006-12-28 at 14:16 -0800, Joe Crawford wrote:
> > On 12/21/06, Timothy M. Shead <tshead@...> 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
> 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
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
Does/will Dr Queue offer post production functionality, such as
passing output to GIMP/Python imaging pipelines?