Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!psuvax1!psuvm!cunyvm!uupsi!pixar!markv
From: markv@pixar.com (Mark VandeWettering)
Newsgroups: comp.graphics
Subject: Re: Ray Tracing Optimization Idea
Keywords: Exploit coherence
Message-ID: <1991Mar26.183524.1547@pixar.com>
Date: 26 Mar 91 18:35:24 GMT
References: <1991Mar21.183340.19319@dartvax.dartmouth.edu> <2448@umriscc.isc.umr.edu>
Sender: news@pixar.com (Usenet Newsmaster)
Organization: Pixar -- Point Richmond, California
Lines: 28
Nntp-Posting-Host: roger

Regarding the "object cache" for raytracing:

This is an interesting idea.  I believe I actually did try doing this
in my raytracer, but took it out because of the limited performance
gains. (<2% as I recall)

I implemented it slightly differently than described initially.  It makes
more sense to cast the second ray in the same direction as the first, but
with the distance cutoff, because you are looking for the intersection
CLOSEST to your eye.


In article <2448@umriscc.isc.umr.edu> ercal@cs.umr.edu (Fikret Ercal) writes:
>"How would you perform the second intersection test with the
>objects between the point hit and the eye fast enough such that
>the gain will be justified ?"

Often you can prune large amounts of the ray tree if you know that the
ray is a "short" ray.  In the case of Kajiya/Kay, you avoid some heaping
operations which normally would have to have been done.  Basically, any
method which has a "top down" approach can benefit (at least marginally)
be expressing the ray as a "segment".

This same approach is more effective in shadow testing:  cacheing the
last object that shadowed a given pixel is often quite useful.  The
MTV raytracer does include shadow cacheing optimizations.

Mark