K-3D

> Hello, I'm the main developer of DrQueue.
>
> Is there anything I could do to help you out regarding DrQueue ?
>


Man, we should jump on this! It would be great to have Dr Queue integration...

Sincerely,

Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com

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?

Cheers,
Tim

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.


Sincerely,

Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com

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

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.

Cheers,
Tim

> 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.

>From a integration standpoint it could mean a lot, because Dr Queue
manages tasks for s many other 3D apps/renders. Its nice if people can
use the same tool they use to mange their other renders.

Also, k3d would be a feature for the Dr Queue community too.

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
>
> 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?

On 12/29/06, Daniel Matthews <dsmatthews@...> wrote:
>
> 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.
>
>
The long term plans for Aqsis most definitely include multi-threading and
parallelisation. The primary new feature post 1.2 release will be
raytracing, and part of this work is making the shading engine re-entrant
and multi-thread capable. This in itself will enable at least the shading
part to be shared between processors, of course it's not that simple, but
it's a step in the right direction.

Beyond that, I have some longer term ideas for an interesting business
proposal based aroung Aqsis and massive multi-processing, so there will
definitely be multi-processing capabilities on the roadmap.

Cheers

-- 
Paul Gregory
http://www.aqsis.org
ICQ: 156088409

On Fri, 2006-12-29 at 00:10 -0800, Joe Crawford wrote:
> > 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.
> 
> >From a integration standpoint it could mean a lot, because Dr Queue
> manages tasks for s many other 3D apps/renders. Its nice if people can
> use the same tool they use to mange their other renders.
> 
> Also, k3d would be a feature for the Dr Queue community too.

As I outlined in the Wiki, I want to have a unified system for local and
remote rendering, including good integration with the UI.  We also have
to continue support for zero-setup out-of-the-box local rendering.  If
that can be implemented in terms of DrQueue so much the better, but it
implies writing - at a minimum - a K-3D DrQueue client.  So far, I
haven't heard back from the DrQueue author on my requests for
information about the DrQueue protocol, which isn't encouraging.  This
isn't a priority, it only came up now because he contacted us, so we'll
see what happens.

Cheers,
Tim

> As I outlined in the Wiki, I want to have a unified system for local and
> remote rendering, including good integration with the UI.  We also have
> to continue support for zero-setup out-of-the-box local rendering.  If
> that can be implemented in terms of DrQueue so much the better, but it
> implies writing - at a minimum - a K-3D DrQueue client.  So far, I
> haven't heard back from the DrQueue author on my requests for
> information about the DrQueue protocol, which isn't encouraging.  This
> isn't a priority, it only came up now because he contacted us, so we'll
> see what happens.

That all makes sense. Basically, what I was saying was that if he's
offering to write one (it sounded like he was), then we should try to
assist him with any info he needs. Also, I think we should contact
him.

Also, if rendering from the command line is possible via k3d, I (or
someones else) could write a script. Writing Dr Queue scripts is
fairly easy from what I understand.

Sincerely,

Joe Crawford
___________________________________
Owner - Joetainment Enterprises
Cell: 604-866-3050
Email: joe@...
Messenger: joetainment@...
ICQ: 103730379
Web: http://www.joetainment.com