[RC5] film rendering

Eric Gindrup 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 
     is halted.
        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 mailing list