Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!zip!spencer From: spencer@eecs.umich.edu (Spencer W. Thomas) Newsgroups: comp.graphics Subject: Re: ray/bounding box intersection Message-ID: Date: 12 Apr 89 16:15:23 GMT References: <857@uceng.UC.EDU> Sender: news@zippy.eecs.umich.edu Distribution: na Organization: University of Michigan EECS Dept Lines: 32 In-reply-to: achhabra@uceng.UC.EDU's message of 11 Apr 89 21:30:37 GMT In article <857@uceng.UC.EDU> achhabra@uceng.UC.EDU (atul k chhabra) writes: > I have a question about checking for ray/bounding box intersection in ray > tracing. Rogers ("Procedural Elements for Computer Graphics," 1985, > pp. 299) suggests a transformation comprising of translation and rotations > about the coordinate axes, in order to make the ray coincident with the > z-axis. [Points out problem: some bounding boxes pass this test, but are not intersected by the ray.] I think the point here is to make a cheap test. What he is really doing is testing against the bounding box of the transformed bounding box (call it TB). Any intersection with the original box (call it B) is guaranteed to intersect TB, but there are ray intersections with TB that don't intersect B. This is not a problem, except that it can make you do more ray-object tests than you would have with a better ray-box test. So, the question is, do you lose worse by doing a few more ray-object intersections or by having a more expensive ray-box test (which will presumably occur much more frequently than the r-o test)? If you are really worried about it, you can do the (more expensive) test of the original ray against the original box (this involves intersecting the ray with each bounding plane -- if any of these intersections falls inside the corresponding face bounds, then the ray intersects the box) after the cheap test has succeeded. However, you'd probably do better by using Kay-Kajiya bounding "boxes" instead. (See paper in SIGGRAPH 1986 proceedings.) -- =Spencer (spencer@eecs.umich.edu)