"Gilles Fedak" <fed### [at] lrifr> wrote in message
news:3AAA1D58.311A36C5@lri.fr...
> > With 480 clients out there on
> > the net, I could have my image in a half hour instead of 3 days...
>  That's the point.

I didn't gather from your original explanation that you intended to break up
the render, it sounded more like you were talking about farming out
animation frame rendering. But if we agree, hey, great!

> Yes, an idea was to calculate few pixels, that could serve both as
> predicting the rendering time of the scene, and as certificate for
> correctness of the computations.

I see two problems with that plan as a test of fitness. First, if they can
figure out where you do the test renders, they can *easily* make that area
render quickly -- maybe even if you use multiple areas (for example, by
carefully placing bounding boxes). The second problem is the converse -- I
think it would be easy to make the small-area test-render take a very, very
long time. For example, layers of transparency, lots of lights, fog, high
max trace level, etc. Then I slam a few of those into your server and the
test-renders shut it down.

And trust me, I hate being the devil's advocate on this. I would love to
have distributed rendering...

> BTW I have one question about the way you distribute the rendering on
> your different PCs. How does the distribution handles the various
> frequency of the processors. I mean how the load is distributed to the
> processors, statically or dynimically ?

My distribution method is a little something I call "doing it by hand".  :)
There isn't anything automated about how I do it now (unfortunately), other
than copying files around on the network and using remote control software
to kick off rendering on the other machines. I am toying with a couple ideas
but I haven't actually written any code yet.

Post a reply to this message