Newsgroups: comp.parallel.mpi,comp.graphics.raytracing
From: thite@netcom.com (Thomas D. Hite)
Subject: Re: Using multi-threading/MPI/etc. for ray-tracing?
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Date: Sun, 21 Aug 1994 19:40:40 GMT
Message-ID: <thiteCuwHBs.30C@netcom.com>

Ken Geis (kgeis@ucsee.EECS.Berkeley.EDU) wrote:

: 	Hi.  I am planning to write or extend a ray-tracer with some
: ideas of my own.  I am looking for ideas of how to implement what I want
: it to do.

[lots of stuff deleted describing multiprocess/threading raytracer]

What you're talking about is a threaded distributable raytracer.
Such an effort is really quite easy with a raytracer simply
because of the fact that raytracing is such an independent process.

Each ray is an independant issue.  Therefore you have some starting points:

    1)  Pump each ray off to a processor.
    2)  Since rays are independent, so is the color updating of a pixel,
        and therefore, pixels are independent. Therefore, the
        threads can complete a full ray tree computation. 
    3)  Since pixels are independent, so then are regions of
        the output. Use a process to manage the threading of a 'region'.
    4)  Then the raytracer is a bunch of processes (distrubution) which manage
        the regions into which to pump rays (threads).  Each process should
        run on a processor and should divvy out threads to other processors
        which handle the ray tree computations.

I've created exactly this model which I still hope to release to the
net (when Micrografx, Inc. allows me to).  If you check out any of the up
and coming Intel technology demos, you'll see the a raytracer from Micrografx
doing exactly what's explained above. 

Without giving up my complete design, which would be inappropriate at
this time, you need to start thinking about what are the base objects of
interest to a computation thread.

Well, just a hint here, pack up the ray class with what you need to
complete a ray tree computation.  A ray should be able to
spawn a child ray correctly, incorporating the threading as appropriate.

Done correctly, the raytracer could really care less how many rays are
currently running in threads.  Then the processes are also full fledged
raytracers and they are happy too.

The only sticky situation is when to anti-alias.  The obvious brute force
is since you'll have a pretty fast raytracer, it'll do pretty well at
suporsampling the whole scene.

I personally use a back end (post process) high contrast region super
sampling approach.  This fits well because, as stated above, the raytracer
process looks at regions and divvies up ray tree threads.  The supersampling
is just another process which does the normal thing at a higher
resolution.  The only difference is that it runs a special weighting
convolution matrix over the supersampled region before updating the display
(output) pixel.  (Are we thinking subclass of a raytracer here???).

The antialising processes are started up after
a certain number of scan lines have been completed.  The drag is that I have to
manage the semaphores such that enough of a region is available before
firing off a process to antialias a region.  Nothing too steep though.

BTW, in the absence of any code I can give you, I'd suggest starting
with Craig Kolb's RayShade.  The code is clean and conforms well to
object orientation already.  Do your new stuff in C++ and leave RayShade
alone though.  All you'll have to add is threading.

Tom Hite
thite@netcom.com
thite@micrografx.com

