I vote for the

"ultra-user friendly program with a  realtime render display"

Look forward to seeing that.
D.




, and also to learn MFC , hence the GUI. :) However,
> now that you mentioned it, it would not be hard at all to also make a
> commandline-only version of the Master as well. All the render control
code
> will be encapsulated into a RenderController class, so it wont matter
> whether a GUI or a command-line is feeding it. Also, thanks for the cygwin
> suggestion, as I do not use unix or have any unix/linux machines handy. As
> far as radiosity goes, I will be looking into the PVMegaPov approach.
> However is it really necessary to modify POV-Ray? What if the radiosity
file
> (from save_file) generated by each slave is harvested by the Master after
> each tile is done and appended to the master copy of the octree (with
> updates sent to each slave whenever a change to the octree is made) ?
>
> Thanks for the insight, keep it coming :)
> George Pantazopoulos
>
>
>
>
> >
> > George Pantazopoulos wrote:
> > >
> > > Hey Cristoph,
> > >     Yes, I've taken your previous comments to heart. While the Master
is
> a
> > > GUI Windows program, the slaves could be ported to any platform, since
> they
> > > are command-line programs and communicate with the Master via a TCP
> > > protocol. That way, you would only need one Windows machine for the
> entire
> > > render farm, and it wouldn't need to be a particularly powerful or
> expensive
> > > machine.
> >
> > If you make the communication program platform independent i don't
> > understand why you need a platform specific master.  The GUI should be
> > purely optional anyway.  And if you want the system to be universally
> > usable you should probably test it on different machines during
> > development - especially network communication is a critical part in
that
> > concern.
> >
> > If you don't have access to a unix machine to test simply try compiling
it
> > with cygwin. - if it works there is a good chance it will do so on other
> > systems as well (assuming you are taking care of things like byte order
> > etc.).
> >
> > > Also I am coding in 48-bit support from the start :) And yes,
> > > automating a 2-pass render is definitely a goal of mine. I know that
if
> you
> > > use always_sample off that you need higher quality settings and other
> > > techniques to make up for the loss, but how do scenes *rely* on data
> > > gathered during the final trace?
> >
> > Changing the settings does not compensate the lack of possibility to
take
> > samples during final trace.  If you use a minimum pretrace_end this will
> > help a lot but there are still samples taken during the final trace in
> > many cases.
> >
> > After all radiosity simply isn't possible to be distributed on many
> > computers perfectly, but the best solution will be to share the data
> > gathered on the individual nodes like it is done in PVMegapov.  This
will
> > of course create extra network traffic and will not work without
modifying
> > POV-Ray.
> >
> > Christoph
> >
> > --
> > POV-Ray tutorials, IsoWood include,
> > TransSkin and more: http://www.tu-bs.de/~y0013390/
> > Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______
>
>

Post a reply to this message