Hi all,

Here are my latest updates of MegapovXRS, the distributed rendering server
and its companion, pyxrsclient.

This update eliminates all "Memory Leak Detected" warnings observed,
increasing the long-term reliability of the Server.

pyxrsclient was updated to version 0.6.10 and is recommended with this
release.


Download:
http://www.gammaburst.net/xrs/

Enjoy,
George


-----

megapov_xrs_server release history:
-----------------------------------


2.1.1 - 9 Sep 2006
------------------

- Solved memory leak issues when changing or aborting scenes.

- Added povray license files to distribution (see doc folder inside build
dir)

- Fixed memory leak issue caused by exiting FrameRender() when doing
  scene init while waiting for tile requests to arrive from client.
  Now, FrameRender simply does the scene init upon receipt of the first
  RenderTile() request from the client. This simplifies initialization and
  cleanup and avoids memory leak problems.

pyxrsclient Release History:
----------------------------

0.6.10 - 9 Sep 2006
-------------------

- Now, when a Render is stopped or aborted (such as when the Render Preview
  Window is closed), the client will force the Servers to stop rendering (by
  calling NewScene() on the Server with an empty command)
  MegapovXRS 1.2.1-2.1.1 was updated to handle this more gracefully.

- Cleaned up logic and error reporting in CreateServerProxies()

- Render threads no longer abort from an xmlrpc fault response.
  Cleaned up error message for exception handlers

- added gtk.threads_leave() in the exception handler of the display thread.
  Now an exception in that thread won't hose the client anymore!

- made queuing more configurable

- Added LightsysIV directory to library paths. Added slashes to library
paths

Post a reply to this message

Woohoo, after much pain working out how to use Cygwin (mostly working out 
which packages I needed installed), I've finally got both server and client 
working on my main PC. Now to remember how I did it so I can get the server 
working on my second PC...

Just one thing that took me ages to work out, I couldn't get it working 
until I stuck all my scene files under /usr/local/share/povray-3.6/scenes 
(Which translates to C:\cygwin\usr\local\share\povray-3.6\scenes under 
Windows). What was the reasoning behind this? All my scene files are 
normally stored on my D: drive (/cygdrive/d/...) where there's more space, 
but XRS seems to complain if it doesn't find a folder named "scenes" in the 
path.

Otherwise, this seems like a very cool addition to pov. Now to eliminate 
those radiosity tiling artifacts...

Ryan


"George Pantazopoulos" <go### [at] tomyaboutpage> wrote in message 
news:web.4503150abd91df05c0bad8570@news.povray.org...
> Hi all,
>
> Here are my latest updates of MegapovXRS, the distributed rendering server
> and its companion, pyxrsclient.
>
> This update eliminates all "Memory Leak Detected" warnings observed,
> increasing the long-term reliability of the Server.
>
> pyxrsclient was updated to version 0.6.10 and is recommended with this
> release.
>
>
> Download:
> http://www.gammaburst.net/xrs/
>
> Enjoy,
> George
>
>
> -----
>
> megapov_xrs_server release history:
> -----------------------------------
>
>
> 2.1.1 - 9 Sep 2006
> ------------------
>
> - Solved memory leak issues when changing or aborting scenes.
>
> - Added povray license files to distribution (see doc folder inside build
> dir)
>
> - Fixed memory leak issue caused by exiting FrameRender() when doing
>  scene init while waiting for tile requests to arrive from client.
>  Now, FrameRender simply does the scene init upon receipt of the first
>  RenderTile() request from the client. This simplifies initialization and
>  cleanup and avoids memory leak problems.
>
> pyxrsclient Release History:
> ----------------------------
>
> 0.6.10 - 9 Sep 2006
> -------------------
>
> - Now, when a Render is stopped or aborted (such as when the Render 
> Preview
>  Window is closed), the client will force the Servers to stop rendering 
> (by
>  calling NewScene() on the Server with an empty command)
>  MegapovXRS 1.2.1-2.1.1 was updated to handle this more gracefully.
>
> - Cleaned up logic and error reporting in CreateServerProxies()
>
> - Render threads no longer abort from an xmlrpc fault response.
>  Cleaned up error message for exception handlers
>
> - added gtk.threads_leave() in the exception handler of the display 
> thread.
>  Now an exception in that thread won't hose the client anymore!
>
> - made queuing more configurable
>
> - Added LightsysIV directory to library paths. Added slashes to library
> paths
>
>
>

Post a reply to this message

"Ryan Bennitt" <rya### [at] lycoscouk> wrote:
> Woohoo, after much pain working out how to use Cygwin (mostly working out
> which packages I needed installed), I've finally got both server and client
> working on my main PC. Now to remember how I did it so I can get the server
> working on my second PC...
>
> Just one thing that took me ages to work out, I couldn't get it working
> until I stuck all my scene files under /usr/local/share/povray-3.6/scenes
> (Which translates to C:cygwinusrlocalsharepovray-3.6scenes under
> Windows). What was the reasoning behind this? All my scene files are
> normally stored on my D: drive (/cygdrive/d/...) where there's more space,
> but XRS seems to complain if it doesn't find a folder named "scenes" in the
> path.
>
> Otherwise, this seems like a very cool addition to pov. Now to eliminate
> those radiosity tiling artifacts...
>
> Ryan
>

Hey thanks for your feedback, Ryan. I agree, my documentation could use more
work. How do you think I could have made things easier? Though I'd prefer to
solve problems in the newsgroup (so others could benefit), feel free to
email me directly.

MegaPOV XRS needs a directory setup that includes a scenes/ folder (the
folder above scenes/ is called the PovBaseDir). My setups also have certain
other folders under PovBaseDir, such as LightSysIV/ include/ imagemaps/ and
fonts/

My reasoning was to allow flexibility in configuring the Servers. They can
have widely varying directory structures, but as long as you had a
PovBaseDir somewhere, you can give that location to pyxrsclient, and any
necessary scenes and includes could easily be found (and the relevant +L
entries automatically added to the command line for each Server when tiles
are rendered). Also, having a unified directory structure makes it much
easier to clone it for multiple servers when one or more scene files are
updated (either manually or using rsync).

Can you tell me more about what kind of systems you're running MegaPOV XRS
on? Also, what kind of renders are you doing?
You may be able to avoid recompiling on cygwin (a slow process) and get away
with copying the binary to the new computer and running it, provided that it
also has cygwin installed. I'm hazy on the details at the moment, but you
probably don't have to install all the libraries on the other machines. I'd
start with a minimal cygwin install on the subsequent machines and see what
happens.

Jaime Vives Piqueres found a way to virtually eliminate radiosity tiling
artifacts in his MegaPOV XRS renders. As I recall, he uses a two-pass
method. With a regular copy of MegaPOV he generates the radiosity data at
lower resolution and scene complexity. Then, he copies the rad data to all
the servers and does a usual XRS distributed render. There's another thread
on here talking about it. If you have trouble finding it, let me know.

Also, how did you hear about MegaPOV XRS? :-)

Best,
George Pantazopoulos
http://www.gammaburst.net

Post a reply to this message

"George Pantazopoulos" <go### [at] tomyaboutpage> wrote in message 
news:web.45592660a65ea229c0bad8570@news.povray.org...
> Hey thanks for your feedback, Ryan. I agree, my documentation could use 
> more
> work. How do you think I could have made things easier?

Well coming from the Windows side with minimal Unix experience, it took a 
lot of getting my head round just setting everything up. I think I'll put 
some notes together for other similarly minded Windows users. Also there 
will probably be more experienced users who can see what I've done and tell 
me how to do it better.

> My reasoning was to allow flexibility in configuring the Servers. They can
> have widely varying directory structures, but as long as you had a
> PovBaseDir somewhere, you can give that location to pyxrsclient, and any
> necessary scenes and includes could easily be found (and the relevant +L
> entries automatically added to the command line for each Server when tiles
> are rendered). Also, having a unified directory structure makes it much
> easier to clone it for multiple servers when one or more scene files are
> updated (either manually or using rsync).

Having got the second PC going, I think I understand now. I hadn't actually 
realised that all the scene files had to be on both PC's before running the 
client. I naively thought that this would all be magically done for me...

> Can you tell me more about what kind of systems you're running MegaPOV XRS
> on? Also, what kind of renders are you doing?

I've got two PC's, both with Windows XP installed and on a local network. My 
main PC is twice as fast as the other POV-Ray wise, so I'm going to get a 
theoretical 50% boost to processing power just using this. Not sure how the 
speed of the Cygwin compiled executable compares to native though, will have 
to benchmark and optimise if possible.

As for renders, I check on the IRTC topics, start making a scene, and if 
it's complete before the deadline, I enter it. This month's "Complexity" is 
probably going to require all the processing power I can get, if I can think 
of a suitable subject...

> Jaime Vives Piqueres found a way to virtually eliminate radiosity tiling
> artifacts in his MegaPOV XRS renders. As I recall, he uses a two-pass
> method. With a regular copy of MegaPOV he generates the radiosity data at
> lower resolution and scene complexity. Then, he copies the rad data to all
> the servers and does a usual XRS distributed render.

Yeah, saw the thread. Makes sense, I'll give it a go.

> Also, how did you hear about MegaPOV XRS? :-)

It was on the main POV-Ray website. Saw it a while ago and thought I'd give 
it a go some time.

Now I've got it working, I'll see if I can make it abit easier for me to 
use, particularly with keeping scene files in sync. I'm certainly hooked on 
its usefulness...

Ryan

Post a reply to this message

"Ryan Bennitt" <rya### [at] lycoscouk> wrote:
> "George Pantazopoulos" <go### [at] tomyaboutpage> wrote in message
> news:web.45592660a65ea229c0bad8570@news.povray.org...
> > Hey thanks for your feedback, Ryan. I agree, my documentation could use
> > more
> > work. How do you think I could have made things easier?
>
> Well coming from the Windows side with minimal Unix experience, it took a
> lot of getting my head round just setting everything up. I think I'll put
> some notes together for other similarly minded Windows users. Also there
> will probably be more experienced users who can see what I've done and tell
> me how to do it better.
>

Thanks, I think you just helped me a lot. I went through that whole phase
myself, but I guess I temporarily forgot what it must be like for others
who haven't been there yet. Feel free to elaborate on that!

> > My reasoning was to allow flexibility in configuring the Servers. They can
> > have widely varying directory structures, but as long as you had a
> > PovBaseDir somewhere, you can give that location to pyxrsclient, and any
> > necessary scenes and includes could easily be found (and the relevant +L
> > entries automatically added to the command line for each Server when tiles
> > are rendered). Also, having a unified directory structure makes it much
> > easier to clone it for multiple servers when one or more scene files are
> > updated (either manually or using rsync).
>
> Having got the second PC going, I think I understand now. I hadn't actually
> realised that all the scene files had to be on both PC's before running the
> client. I naively thought that this would all be magically done for me...
>

I think its perfectly natural to expect that! I wanted to add this
functionality from the get-go, but at the time it was just too complex and
would have held up releasing anything at all, so my solution was to make it
as easy as I could. I've learned a lot since then, though.

> > Can you tell me more about what kind of systems you're running MegaPOV XRS
> > on? Also, what kind of renders are you doing?
>
> I've got two PC's, both with Windows XP installed and on a local network. My
> main PC is twice as fast as the other POV-Ray wise, so I'm going to get a
> theoretical 50% boost to processing power just using this. Not sure how the
> speed of the Cygwin compiled executable compares to native though, will have
> to benchmark and optimise if possible.
>

I'd be interested in seeing that.

My friend Rainer Mucke did some extensive benchmarking of MegaPOV XRS here:
http://www.overclock.at/forum/topic.php?id=247&s=8f6205f2881dc0fc4df8c49f273bcba3

That forum also has some POV-Ray 3.7 benchmarking, I noticed.

> As for renders, I check on the IRTC topics, start making a scene, and if
> it's complete before the deadline, I enter it. This month's "Complexity" is
> probably going to require all the processing power I can get, if I can think
> of a suitable subject...
>

Maybe some ideas: Fractals, dynamical systems, nature, also the simplicity
that is often found in the midst of complexity (think of the Mandlebrot Set
and all the mini-mandlebrot sets found within, or Feigenbaum constants:
http://en.wikipedia.org/wiki/Feigenbaum_constants). The three-body problem.
The Heisenberg Uncertainty Principle, the Butterfly Effect.

> > Jaime Vives Piqueres found a way to virtually eliminate radiosity tiling
> > artifacts in his MegaPOV XRS renders. As I recall, he uses a two-pass
> > method. With a regular copy of MegaPOV he generates the radiosity data at
> > lower resolution and scene complexity. Then, he copies the rad data to all
> > the servers and does a usual XRS distributed render.
>
> Yeah, saw the thread. Makes sense, I'll give it a go.
>
> > Also, how did you hear about MegaPOV XRS? :-)
>
> It was on the main POV-Ray website. Saw it a while ago and thought I'd give
> it a go some time.
>
> Now I've got it working, I'll see if I can make it abit easier for me to
> use, particularly with keeping scene files in sync. I'm certainly hooked on
> its usefulness...
>

Congrats, and I'm glad its useful to you! I'll find it very helpful to hear
how you went about making it easier for you, Ryan, and I could share that
with others too. And feel free to make suggestions. Perhaps I should put up
a forum on the website..

Rock on,
George
http://www.gammaburst.net


> Ryan

Post a reply to this message

>
> Having got the second PC going, I think I understand now. I hadn't actually
> realised that all the scene files had to be on both PC's before running the
> client. I naively thought that this would all be magically done for me...
>

I forgot to mention, you should be able to use Windows Shared drives to
magically do this for you.

George

Post a reply to this message

>> > Jaime Vives Piqueres found a way to virtually eliminate radiosity 
>> > tiling
>> > artifacts in his MegaPOV XRS renders. As I recall, he uses a two-pass
>> > method. With a regular copy of MegaPOV he generates the radiosity data 
>> > at
>> > lower resolution and scene complexity. Then, he copies the rad data to 
>> > all
>> > the servers and does a usual XRS distributed render.
>>
>> Yeah, saw the thread. Makes sense, I'll give it a go.

Well tried it and I've ended up with tiling artefacts everywhere. It wasn't 
exactly a complex scene either. Just a room with box walls and ceiling, 
isosurface carpet, high poly mesh armchair, low poly mesh side table and 
CSG'd cone lamp shade. All I did was add the following lines:

#if( GENERATE_RADIOSITY )
    save_file "Sofa-radiosity.rad"
#else
    load_file "Sofa-radiosity.rad"
    //always_sample off
#end

Then ran the first pass GENERATE_RADIOSITY=1 to generate the radiosity file, 
copy file to both PC's, then rendered the scene with GENERATE_RADIOSITY=0. 
Tried with and without "always_sample off" but it made no difference. Will 
playing with other parameters help to reduce the artefacts? e.g. increase 
count, reduce error_bound, etc. Or is this just a problem with radiosity 
that will likely never go away?

Ryan

Post a reply to this message

"Ryan Bennitt" <rya### [at] lycoscouk> wrote:
> >> > Jaime Vives Piqueres found a way to virtually eliminate radiosity
> >> > tiling
> >> > artifacts in his MegaPOV XRS renders. As I recall, he uses a two-pass
> >> > method. With a regular copy of MegaPOV he generates the radiosity data
> >> > at
> >> > lower resolution and scene complexity. Then, he copies the rad data to
> >> > all
> >> > the servers and does a usual XRS distributed render.
> >>
> >> Yeah, saw the thread. Makes sense, I'll give it a go.
>
> Well tried it and I've ended up with tiling artefacts everywhere. It wasn't
> exactly a complex scene either. Just a room with box walls and ceiling,
> isosurface carpet, high poly mesh armchair, low poly mesh side table and
> CSG'd cone lamp shade. All I did was add the following lines:
>
> #if( GENERATE_RADIOSITY )
>     save_file "Sofa-radiosity.rad"
> #else
>     load_file "Sofa-radiosity.rad"
>     //always_sample off
> #end
>
> Then ran the first pass GENERATE_RADIOSITY=1 to generate the radiosity file,
> copy file to both PC's, then rendered the scene with GENERATE_RADIOSITY=0.
> Tried with and without "always_sample off" but it made no difference. Will
> playing with other parameters help to reduce the artefacts? e.g. increase
> count, reduce error_bound, etc. Or is this just a problem with radiosity
> that will likely never go away?
>

Hi Ryan,

I'm going to look into this one. I'm confident it can be solved. Have you
seen Jaime's room scenes? I believe he's rendered some of them using
MegaPOV XRS: http://www.ignorancia.org/

In the meantime, did you remember to copy the new scene file to the other PC
too?

When I was rendering with MegaPOV XRS, I found it easy to forget to do that
sometimes, so I wrote a script that uses rsync to do it automatically.

If youre using Windows PC's on a local network then the solution is simpler
than that. You could set up a shared folder and then you shouldn't have to
manually copy any files when you make a change to your scene.

HTH,
George
http://www.gammaburst.net

> Ryan

Post a reply to this message

Ryan Bennitt wrote:
> Well tried it and I've ended up with tiling artefacts everywhere. It wasn't 
> exactly a complex scene either. Just a room with box walls and ceiling, 
> isosurface carpet, high poly mesh armchair, low poly mesh side table and 
> CSG'd cone lamp shade. All I did was add the following lines:
> 
> #if( GENERATE_RADIOSITY )
>     save_file "Sofa-radiosity.rad"
> #else
>     load_file "Sofa-radiosity.rad"
>     //always_sample off
> #end
> 
> Then ran the first pass GENERATE_RADIOSITY=1 to generate the radiosity file, 
> copy file to both PC's, then rendered the scene with GENERATE_RADIOSITY=0. 
> Tried with and without "always_sample off" but it made no difference. Will 
> playing with other parameters help to reduce the artefacts? e.g. increase 
> count, reduce error_bound, etc. Or is this just a problem with radiosity 
> that will likely never go away?

   For the second pass, you must use "always_sample off" and the same 
"error_bound" and "recursion_limit" as on the first pass. Also don't 
forget to set "pretrace_start" and "pretrace_end" to 1. This setup works 
for me in every scene I tried.

--
Jaime

Post a reply to this message

>   For the second pass, you must use "always_sample off" and the same 
> "error_bound" and "recursion_limit" as on the first pass. Also don't 
> forget to set "pretrace_start" and "pretrace_end" to 1. This setup works 
> for me in every scene I tried.

That's the biscuit, all my troubles disappeared as soon as I set
pretrace_start/end to 1. I guess this show how much of a radiosity noob I
am. Thanks for the help Jaime :D

Ryan

Post a reply to this message