POV-Ray : Newsgroups : povray.general : POV Wishlist : Re: POV Wishlist Server Time
3 Aug 2024 18:16:29 EDT (-0400)
  Re: POV Wishlist  
From: Patrick Elliott
Date: 24 Mar 2004 20:20:19
Message: <MPG.1acbe18560fb0b639899f4@news.povray.org>
In article <40611ef1$1@news.povray.org>, dne### [at] sanrrcom says...
> Patrick Elliott wrote:
> > 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...
> 
> I think the question is two-fold.
> 
> 1) What is computed globally that can't be saved in a file after 
> computation and before the final render?
> 
True and that is in essence the point.

> 2) How automated do you want it?
> 
For myself, if I was using it like that, then 'very' to 'completely' 
would be about right. You could do it with scripts (to a limit), but you 
start getting a bloody mess:

Program 1 - generates a scene file.
POV-Ray 1 - Generates a Photon and/or Radiosity file.
Script sends file to x number of systems.
Script tells each system it is sent to "start povray with ..."
Hopefully nothing goes wrong.

Personally I would prefer if one server handled everything starting with 
step 2, so the only thing that 'can' go wrong should be if one of the 
machines the clients are on doesn't respond. Even then, it could be 
annoying, but not necessarily critical, since the server end can retry 
and in the worst case adjust the image chunks to compensate. But that is 
just me.

> So, I think the real question is, "what's the problem?"
> 
Probably nothing, but if we wanted to bloody do it manually, we wouldn't 
be looking for a better solution. lol Or at least those planning to use 
it. I just see it as an interesting possible way to expand the program. 
The same thing could be done with a plugin/program combo that waits until 
rendering starts and automatically sends out the needed files and 
modified .INIs needed to handle it, then kills the original rendering. 
But I personally hate plugins (in any program), they often require hacks 
to do what you wanted, simply can't do what you need or don't actually 
work the way people claim they are supposed to. They also rely in the 
questionable theory that the program they plug into will never change its 
behaviour or otherwise stop working with the plugin.

I have had some fights over issues like this on another program I use and 
there are still things that I am arguing about with the developer, 
because the hacks needed to do what I want are complicated, not always 
stable or just flat out totally and completely impossible to do as an 
external process.

In any case I see this idea as a major advantage if built in. First off, 
you don't need to install anything extra, so all you need to start a 
render farm is network some computers, install POV-Ray on them and give 
the server the IPs of the other machine. Done!

Now.. A TCP/IP for over the internet would be useful though. If the 
'server' copy could launch to multiple available groups then a plugin 
could be added that lets someone remotely connect with a user name and 
password, then send the file to render direct to the server. The server 
then immediately passes it to a group on the farm or queues it for later, 
then when it does run, tracks the total time and could charge the users 
account based on that. This would make sense as an external addon/plugin, 
while the basic functionality to network POV-Ray in groups makes more 
sense imho if built in.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}


Post a reply to this message

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