POV-Ray : Newsgroups : povray.binaries.animations : render farm : Re: render farm Server Time
19 Jul 2024 09:15:45 EDT (-0400)
  Re: render farm  
From: gimi
Date: 25 Feb 2003 13:22:46
Message: <3E5BB466.7000405@psico.ch>
hi Ian!

Ian wrote:
> [...] I have been playing with the idea of doing a
> render farm. My current thinking is to use cgi (perl) and a central server 
> that keeps track of some basic state information. The POV scene uses this 
> state information to render it's animation. So far I have two state 
> schema's. One is a simple TIME variable that is incremented on each request 
> to the server. 
> The second is a sequence/duration thing. The state is maintained in a .inc 
> file that looks like this. 
 > [...]
> Anyway, to get to the point. I have spent a lot of time looking here and 
> thought I would post to see if anyone knows of any good render farm projects 
> or links. Also, has anyone here approaced the problem themselves and if so, 
> can you tell me a little about your project? Can you elaborate on the  
> ---> What do YOU do? < --- section?

i did something like that using perl, the "povray render server";
see http://www.psico.ch/index.php?page=prs .

it runs its own protocol on top of tcp/ip, works directly
with the supplied .ini file, parses it and builds a new one
for any client requesting a render job.  single frames
(from .pov files) are not split, however, as i basically
only used prs to render animations with a lot of frames.
then, the full set of files needed to render part of an
animation are sent to the client (including .pov, .inc and
image files), which in turn will return the rendered images
before requesting another job.

if you already know perl (i assume you do), then you should
have no trouble understanding the way it works by looking at
the code.  there also is a readme included in the zip archive
describing how to configure everything needed.

note though that i was developping it at a time when i had
no unix box at hand (and did hardly know perl before), so it
is only tested on perl for win32; but getting it to work on a
linux box would only require a few minor changes.

if that is what you'd like to do, and if i can provide further
help, please let me know.  actually, i was already thinking of
doing the port myself, because i've just got a new 1.3 GHz
celeron gateway running linux with over 95% cpu idle time... ;)

also, the code in the server's main loop that waits for clients'
requests and handles them, is *very* bad.  now that i have
learned more, i'd do it with a simple state machine and fork()
the handlers off (which won't work with windoze-perl :/ )...

anyway, i recommend that you keep your state information as
simple as possible, and that you do not touch the time values
yourself.  it's much simpler to change the subset_start/end_-
frame numbers only, and let povray figure out the actual time
itself - except if you insist on changing the initial/
final_frame values as well; but this will make things *very*
(and unnecessarily) complicated!

OTOH, smpov is an alternative. i guess that would mean less
work! :D


i hope this helps.

g.

-- 
"Beware of bugs in the above code. I have only proved it
correct, not tried it."  -- Donald Knuth
++ mailto:gim### [at] psicoch ++ http://www.psico.ch/ ++


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.