Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!bu.edu!dartvax!eleazar.dartmouth.edu!npw
From: npw@eleazar.dartmouth.edu (Nicholas Wilt)
Newsgroups: comp.graphics
Subject: Re: Ray Tracing Optimization Idea
Message-ID: <1991Mar24.012243.27780@dartvax.dartmouth.edu>
Date: 24 Mar 91 01:22:43 GMT
References: <1991Mar21.183340.19319@dartvax.dartmouth.edu> <9B}=P0$@rpi.edu>
Sender: npw@eleazar.dartmouth.edu
Organization: Dartmouth College, Hanover, NH
Lines: 40

In article <9B}=P0$@rpi.edu> kyriazis@iear.arts.rpi.edu (George Kyriazis) writes:
>1. Since you are firing a ray from the object to the eye anyway, why not
>   fire a ray from the eye to the object like you are doing normally?  
>   You'll be looking through the object database anyway.  It all depends
>   if the scene complexity is higher infront of the eye or behind the eye.
>   When you fire a ray towards the eye, you may have complicated objects
>   behind you that you may hit now that you did not hit before.  If you
>   are using some kind of voxel technique to walk through the scene, I
>   think that you'll be just complicating the intersection algorithm.

True.  But how often is the scene complexity behind the eye?  This
seems like an uncommon occurrence to me.  If the scene complexity is
behind the eye, and the objects there aren't likely to be reflected
by mirrors in front of the eye, then they should be culled from the
database before you start tracing anyway.

I am using rectangular bounding volumes and Kay-Kajiya traversal; this
approach is easily adapted to find the farthest intersection not beyond
the eye.

As was pointed out in an earlier post, the scheme could be simplified
to just find out if the cached object is still the closest.  In this
case, the traversal is as simple as tracing a shadow ray.

>2. Why do you think that works just for primary rays?  It looks to me

Because it exploits the tendency for objects in the scene to occupy
adjacent pixels.

I have partially implemented the scheme as follows: intersect with the
cached object and fire a ray back at the viewer; if no object intersected,
the cached object is still the nearest, otherwise, run the standard
find-nearest-intersection code.  As implemented, it generates polygon-
intensive images _much_ faster, but quadric-intensive images much
slower.  I think looking for the "farthest intersection" (not beyond the 
eye) would keep the scheme from slowing you down in images which don't
respond well to the approach.

--Nick
  npw@eleazar.dartmouth.edu