|
![](/i/fill.gif) |
In article <40611ef1$1@news.povray.org>, dne### [at] san rr com 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
|
![](/i/fill.gif) |