_ __ ______ _ __ ' ) ) / ' ) ) /--' __. __ , --/ __ __. _. o ____ _, / / _ , , , _ / \_(_/|_/ (_/_ (_/ / (_(_/|_(__<_/ / <_(_)_ / (_ rminor. If so, hit is OK as is. If not, calculate the distance between the hit you got and torus center. We will be needing the distance SQUARED, so no need for a square root. Put the distance squared in variable SqrDist. If rmajor < rminor && rmajor > 0 if SqrDist < (rminor*rminor - rmajor*rmajor) then discard the hit, it's on the wrong surface. If rmajor < rminor && rmajor < 0 if SqrDist > (rminor*rminor - rmajor*rmajor) then discard the hit, it's on the wrong surface. Voila! -------- Joe Cychosz (3ksnn64@ecn.purdue.edu) responds: I did test the case where the torus was degenerate, however I did not consider the application sense of it not really being a wanted surface. I will study this further and incorporate your suggestion. Also, not include in the GEM is the following code which compensates for the order of the roots being transposed. I didn't include it since it would make the GEM dependent on the behaviour of the root solver. Insert after the call to SolveQuartic: /* SolveQuartic returns root pairs in reversed order. */ if ( *nhits > 1 ) m = rhits[0]; u = rhits[1]; rhits[0] = u; rhits[1] = m; if ( *nhits > 3 ) m = rhits[2]; u = rhits[3]; rhits[2] = u; rhits[3] = m; ------------------------------------------------------------------------------- Information on Taos Parallel Processor, by Paul Wain (ee89psw@brunel.ac.uk) [edited from bits and pieces by Paul. - EAH] I am after any info on the Taos parallel processor raytracing stuff. The reason I sat up and paid attention when I read about Taos was only because of the way it handles code from a programmer's point of view. Apparently it doesn't link the program at the compilation stage but rather downloads the objects as and when they are needed, and destroys them as they are finished with (how quickly depends on their priority). Also, if one branch calls an object which is already resident on another node rather than load dwon from the data store it loads in from the other node. Also, the programmer doesn't need to allocate them to the nodes and ensure that all the node loads are balanced. Indeed Taos does this for the programmer to supposedly ensure optimum performance. It can apparently do a 790x400 24bpp colour raytrace on 256 compound objects in under 15 minutes. And supposedly a 50x50 array of em can do real-time raytracing.... ------------------------------------------------------------------------------- The Glazing Trick, by Haakan "Zap" Andersson (zap@lage.lysator.liu.se) [This is an excerpt from a longer document by Zap - more later. It's one of those tricks that many people know, but if you don't know it then it's worth knowing. Or something. - EAH] Next "bad" thing with standard Phong is the inability to get really shiny surfaces. Pumping up the specular exponent makes the shiny spot SMALLER, not (as it should) SHARPER. So it might look pretty shiny on a sphere, but use it on a cube, the chance of you ever SEEING that tiny little specular spot is very small, unless the light is positioned just right in respect to the viewer and some cube surface. There is a nice and simple trick for this, used frequently by Pixar in their little movies: You simply threshold the specular light instead of feeding it directly to the output light. Let's assume we have a function similar to the Renderman (tm) function SmoothStep() that work like this: Smoothstep(a,b,x) if (x < a) return 0.0; if (x > b) return 1.0; if (x > a and x < b) return a smooth gradation between 0.0 and 1.0 (Pixar uses a hermite spline I think) Then let our "all new" specular highlight be... OLD specular formula: Ks * (cos b ^ Ke) NEW specular formula: Ks * SmoothStep(0.4,0.5,cos b ^ Ke) ...where the numbers (here 0.4 and 0.5) could be anything you wish. This gives the surface a "glazed" appearance and may be useful modelling glass and similar. ------------------------------------------------------------------------------- Bug in Ray-Convex Polyhedron Intersector in Graphics Gems II, by Eric Haines This bug was found by Peter Flatau. The test for my polyhedron intersector was (p. 576, middle of the page): if ( t < 0.0 ) return ( MISSED ) ; if ( t < tfar ) { /* hit near face, update normal */ It should be: if ( t < tnear ) return ( MISSED ) ; <-- 0.0 to tnear if ( t < tfar ) { /* hit far face, update normal */ <-- near to far Also, the text in Graphics Gems II has the same bug. The last sentence on page 249 should be: "If the compute t is less than tnear, then the polyhedron is ..." ^ +--was "0" ------------------------------------------------------------------------------- END OF RTNEWS