[RC5] film rendering
gindrup at okway.okstate.edu
Thu Jan 28 16:00:37 EST 1999
Voting would most easily be accomplished by setting up all potential
projects and letting the users specify the project on which the
client works (or the mix ratio).
Specific presets that would be a good idea:
Maximum Expected Pay-off/second worked.
Project for which this machine maximizes (normalized?) throughput.
Default project (whatever D.Net would like).
This should hit the participants who are in the following camps and
allow them to fire and forget their clients:
Money-seekers (in D.Net?!)
(Abstract) Distributed Computing supporters
There are others, but I don't see a way to automatically cater to
their preferred project mixes.
I'll say *this* a different way.
There are many people who've worked out how to do large-scale
parallel mathematical operations. If rendering scenes can be
reduced to some (small) preprocessing followed by an application of
one of those operations, then the project is feasible.
It was once pointed out to me that the rendering of a frame of
"standard complexity" with "standard bells-and-whistles" always
seems to require ~30-60 minutes. (The complexities increase and the
"necessary" options increase, but so do the computer capacities.)
If this is so, then a small number of machines could do the
preprocessing for rendering, converting the problem to one in, say,
(large) matrix inversion. The multiple inversions (one for each
frame) could then be distributed.
It won't be real-time. No client will have "some pixels in the
output image". It won't be meaningful until a little postprocessing
converts the resulting matrices back into images.
A pure hemicube algorithm requires some setup (to define the
interaction coefficients between patches on the various models).
This is parallelizable by sending two models ("in position") to a
client and having that client compute the coefficients. This would
require decent available bandwidth. (High-speed modems might be
fine). Then the object is to compute the limit matrix of raising
the resulting full interaction matrix to successive powers. I.e.,
finding what part of this patch's coloring is caused by reflections
in another patch of yet a third patch. The limiting value is the
long-time steady state for the illuminated scene.
Matrix multiplication can be decomposed. (Q.v. Numerical
Recipes) This means that one can send pieces of the matrices out to
multiple clients, have them do a litle work and return results which
can be pasted into the result of the multiplication. (This begs to
have a two-tiered client network.)
Normally, one iterates *many* times and calls the result the
limiting value. Frequently, track is kept of how much the matrix
changed last time and when the change is small enough, the process
Again, no client ever holds any final pixels (really). No client
ever sees the models (except the ones in the setup pass and that can
be done by a "trusted cadre" of clients since it will be faster than
the multiplication pass).
-- Eric Gindrup ! gindrup at okway.okstate.edu
______________________________ Reply Separator _________________________________
Subject: Re: [RC5] film rendering
Author: <rc5 at lists.distributed.net> at SMTP
Date: 1/27/99 10:17 PM
But who says D.net would be doing anything for them? I'm thinking more
along the lines of helping small indy film makers add a few 'effects
shots' that would be far out of their own, or contractors price range
due to the time to render/# of frames.
That would be the better use of D.net if we have a 'render ranch' core
in the future.
We could be like the hubble - with indivuduals queing up to 'get time'
on D.net for a project. With some projects given more weight as desided
by votes, akin to picking the rc5/des charity.
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5