Path: utzoo!attcan!uunet!husc6!rutgers!netnews.upenn.edu!linc.cis.upenn.edu!david From: david@linc.cis.upenn.edu (David Feldman) Newsgroups: comp.graphics Subject: Re: Raytracing speedups.... Summary: I have done this too... Keywords: not much speedup Message-ID: <6819@netnews.upenn.edu> Date: 21 Dec 88 16:36:55 GMT References: <907@cmx.npac.syr.edu> <7839@versatc.UUCP> Sender: news@netnews.upenn.edu Reply-To: david@linc.cis.upenn.edu.UUCP (David Feldman) Distribution: na Organization: University of Pennsylvania Lines: 35 Article 4169 of comp.graphics: From: ritter@versatc.UUCP (Jack Ritter) Subject: Re: Raytracing speedups.... > Do once for each object: > compute its minimum 3D bounding box. Project > the box's 8 corners unto pixel space. Surround the > cluster of 8 pixel points with a minimum 2D bounding box. > (a tighter bounding volume could be used). > To test a ray against an object, check if the pixel > through which the ray goes is in the object's 2D box. > If not, reject it. > It sure beats line-sphere minimum distance calculation. I did this for a ray tracer that a friend of mine and I hacked up. This particular ray tracer only handled spheres, so the calculations were not bad at all. The code was short and ugly. > would be the fastest method. The main problem with ray-tracing, > though, is the object intersections encountered at the later levels > when traversing the tree. This is where the majority of time is spent > in this type algorithm. Hope this was helpful. This does seem to be the case. I used a Phong illumination model for reflections (best results per MFLOP I think) and also had special cases for mirrors and zenith lighting. The speedup due to the bounding boxes on the image plane (pixel space) was less than ten percent for the complicated images we did. In the end, my friend took out the b-box code to keep things simpler, i.s. he did not think it was worth it. _ /| Dave Feldman \'o.O' david@dsl.cis.upenn.edu =(___)= Ok, cough! U DSL - land of wonder and enchantment ACK! PHHT!