Hey thanks for the vote of confidence Dennis :) Anything else you'd like to
see?

George


"Dennis Miller" <dhm### [at] attbicom> wrote in message
news:3d83474f@news.povray.org...
> 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