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

Also, thanks Peter for the link!


Thanks,
George Pantazopoulos

Post a reply to this message

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

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

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

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

I find very interesting all the work in progress on the use of POVray in
distributed rendering.
There is really good work already done, by the people of pvmpov and
pvmmegapov for example,
but it looks like this can be the field for an important development for the
future.
I wish to thank all the people involved in the development of distributed
rendering solutions for POV.

Post a reply to this message

I would also prefer a Version that works with a standard POV 3.5, as I would
like to be able to exchange
my pic's etc. with the community and have the same results..

After reading above I have doubt if there is even a theoretical
chance to make radiosity work on "tiled rendering" without modifying the 3.5
code.
What do the experts say ?

Did I hear some subtones saying that  the calculation diffrences on
mathematics/CPU's/OS'es
may eventually influence the result in (only/not only ?) radiosity so that
the tiles would not fit perfectly together IF they are not rendered on the
same platform ?

I'd prefer if there would be something "builtin" in the next POV-version
that would enable to
make "tiling" possible and maybe some support from the normal POV-Shell ?
In the easiest form that would be the possibility to start two processes,
telling each which part of the pic to render. (= simple SMP Support).

--Theo

----------------------------------------------------------------------------
---------------------------------
Distributed Network-Rendering or Local SMP-Rendering on all CPU's you have.
With SMPOV und POV-Ray 3.5. Download free at:
http://www.it-berater.org/smpov.htm

Post a reply to this message

In article <3d8af25f@news.povray.org>,
 "Theo Gottwald *" <The### [at] t-onlinede> wrote:

> Did I hear some subtones saying that  the calculation diffrences on 
> mathematics/CPU's/OS'es may eventually influence the result in 
> (only/not only ?) radiosity so that the tiles would not fit perfectly 
> together IF they are not rendered on the same platform ?

The platform doesn't really matter...the tiles won't match up even if 
you render them on identical machines. A different portion of the scene 
is rendered for each tile, so the pseudo-random samples will be 
different, giving slightly different shading for each tile. It is likely 
that the only way to avoid artifacts is to ensure that enough data is 
computed before the render starts...but then, I don't know how POV 
handles adding additional data during rendering in the current 
single-threaded version. Radiosity is the only thing that causes this 
problem, but there are other things that could cause similar problems in 
the future...some kind of optimized reflection blur, for example. Maybe 
photons with jitter would also be a problem.

You could overlap the tile edges and interpolate to smooth out the 
transitions, "over-rendering" the image. This would probably make the 
artifacts invisible in most cases without processing to find them, but 
is less efficient. However, it could be done with the current version + 
some clever scripts and a program to merge the tiles together.


> I'd prefer if there would be something "builtin" in the next 
> POV-version that would enable to make "tiling" possible and maybe 
> some support from the normal POV-Shell ?
> In the easiest form that would be the possibility to start two processes,
> telling each which part of the pic to render. (= simple SMP Support).

If it was that easy, don't you think it would have been done already?

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message