On Thu, 3 Jun 1999 08:29:49 -0400, Bill DeWitt wrote:
>Search for Extra Tracing Engines-at-home.org anyone? Problem would come when
>you were waiting for the three middle frames of your animation and some guy
>with a 386 and a tendency to do long renders himself has your info....

Just set minimum performance specs on clients.  I thought extensively about
this sort of thing a couple of months ago, and I even thought about ways to
make the distribution of labor fair to all comers, so that one person couldn't
tie up the resources of the whole network for weeks at a time.  Preference 
would be given to those who contributed the most rendering time and/or had 
used the least rendering time, for example.  To solve the problem you mentioned,
the server just has to reassign the blocks that don't come back in a reasonable 
amount of time.  The system would get really slow when IRTC-time rolled around,
too.

The only problem is, this application isn't as network-friendly as SETI-at-home 
or the distributed.net crypto efforts.  Consider how long it would take to send
a scene with lots of large uncompressed image maps to a client, or how long it 
would take to send the results back.  That pretty much eliminates clients who 
don't have an inexpensive net connection.  Also, you'd want one or more nearby 
clients who could render histograms and do time tests continuously to get an 
idea of how long the rendering would take.  In addition, you'd want to modify 
POV on the clients to create and use something like the POB format, to keep 
from having to reparse really complex scenes.

Finally, you'd want some security measures: you'd have to reject scripts that
use the file-access functions, you'd have to ignore shellouts, and you'd have
to set a time limit on the parse phase to keep from killing all the clients
with a script that says just #while (1) #end.

Post a reply to this message