Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 / ST 1.0; site saber.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!sun!saber!skinner
From: skinner@saber.UUCP (Robert Skinner)
Newsgroups: net.graphics
Subject: Re: Dvorak and SIGGRAPH (rather long)
Message-ID: <1730@saber.UUCP>
Date: Tue, 6-Aug-85 13:05:13 EDT
Article-I.D.: saber.1730
Posted: Tue Aug  6 13:05:13 1985
Date-Received: Sat, 10-Aug-85 20:32:21 EDT
References: <1063@dual.UUCP> <1723@saber.UUCP> <276@gcc-bill.ARPA>
Distribution: net
Organization: Saber Technology, San Jose, CA
Lines: 57

> I've been reading InfoWorld long enought to take anything Good 'ol John
> writes with a shot of tequila.
> 
Like movie reviewers, right?

> But this is really neat:
> 
> >... a ray-tracing algorithm
> >that executes in constant time ( same time for 5 polygons as for 50,000 ) 
> 
> I read about the commercial program. I didn't know it was to be
> discussed at SigGraph. I guess I'll buy the course notes now.
> 
> Could someone give a brief description of the process? (octtrees?)
>
You are on the right track.

The process involves preprocessing the image data by subdividing the
image space in an octree fashion, until there are a small (1-5) number of 
primitive objects in each node.  This preprocessing takes on the order
of a few minutes for 50,000 objects.

Rays are then cast through this octree space.  If the ray passes into
an empty node, it is simply passed to the next intersecting node.  
If the node is not empty, the ray is tested for intersection with the 
objects in that node.

The calculations for the ray intersection with an octree node is very 
simple because of the binary nature of the octree.  Empirical data 
indicates that 7 octree intersections can be calculated for each normal 
ray-object intersection.

The net result of the octree organization is a spatial sorting along any
ray for the image data.  A ray is tested for intersection only with objects 
that are along its path.  Objects that are far from the ray's path are 
not tested.  An additional benefit is that the nearest intersection is 
found first (or at least the sort is fast).  Any secondary rays generated 
from reflection can be treated similarly.  As a result, each ray is tested 
for intersection a small number of times.  This number is fairly constant 
for a given octree resolution.

As Bill Reeves (Lucasfilm) said after the presentation:  "Now I'll never
be able to qualify for Kajiya's Tera-FLOP club!"
(Too bad)

It seems fairly straightforward to me, even though I've never written
a ray-tracer and my experience with octrees is limited.  I just wish
I had a copy of the program running on my workstation.  Maybe the
workstation could handle reasonable images.

------------------------------------------------------------------------------

Name:	Robert Skinner
Mail:	Saber Technology, 2381 Bering Drive, San Jose, California 95131
AT&T:	(408) 945-0518, or 945-9600 (mesg. only)
UUCP:	...{decvax,ucbvax}!decwrl!saber!skinner
	...{amd,ihnp4,ittvax}!saber!skinner