[Bf-committers] The (un)official render daemon discussion
chamaeleon at gmail.com
Tue Nov 18 17:29:27 CET 2008
On Tue, Nov 18, 2008 at 11:00 AM, Timothy Baldridge
<tbaldridge at gmail.com> wrote:
> Right, my idea was to have all data stored on the master node. From
> there information could be retrieved by the blender instance as
> needed. Perhaps a simple "Copy result to directory..." dialog would
> With this setup it would also be possible for more than one blender
> GUI to connect to the master node.
I like the idea of being able to submit and monitor jobs from multiple
locations, by simply firing up whatever program one would use for
interacting with the master node, be it blender or a standalone
program, or a web interface, as long as I can create a proper
As a side-note, I used omniORB CORBA as communication layer in tSNet,
to give me a nice abstraction of both API interface and connectivity
clients and servers, rather than using low-level TCP stuff. Not
necessarily the best choice every time, but I'd really favor a
solution that includes an IDL-equivalent way of describing the data
being passed back and forth when communication takes place, to enforce
type correctness between client and server, so you don't end up making
a small change in one end and not properly updating it in the other.
Just food for thought.
> Ah..another TrueSpace convert. Cool I go my start on TS.
I'd hesitate to call myself a convert from or to anything, regardless
of what it is, as I tend to be rather pragmatic and use what works for
me. Still, I have found blender pleasant enough to work with so far.
More information about the Bf-committers