In article <40609ba0@news.povray.org>, ric### [at] kitty5com says...
> Christoph Hormann wrote:
> > Please reread what i wrote about it.  You write that you can't use tools
> > that distribute a render via file system for reasons specific to your
> > situation but you generally say "for professional print work, ... , POV
> > is not a suitable tool" a few sentences later.  I don't want to get
> > personal here but this to me seems quite clearly either ignorant or
> > malicious.
> 
> Oh come on! Distributing via a shared filesystem is an almighty kludge if
> ever there was one. great for proof of concept, pointless for anything
> beyond your users lan.
> 
> 
Well.. Then code something better, like they said.

As I understand it things like photons and radiosity are computed once 
globally for the image. No way you can really get around this, but the 
same data can be used by several engines, so... How about a set of TCP/IP 
sockets. You set the first copy of POVRay to serve the critical data to 
the others and the other to receive it. Then each takes the 'section' of 
the image its told to handle and renders it based on the precomputed data 
done by the server. You could have that version track the line by line 
final result from the others, just the statistics from them or even run 
multiple scenes through several different available groups of machines. 
It wouldn't be perfect, since photons and radiosity data must be 
precomputer by the 'server', but everything else, once these are 
computed, should be scalable to any number of copies of POV-Ray as 
needed, making the final render far faster.

That is what I would consider doing, if I had a clue how to write decent 
C or make any of it work. Feel free to use or reject it as you wish, but 
I am not going to code it and if you are not going to either, then 
neither of us should complain about someone else not doing it.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message