Christoph,
    My original goal was to make an ultra-user friendly program with a
realtime render display, 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