flipcode - Collision Detection When Using T&L

Collision Detection When Using T&L
Question submitted by (18 November 1999)


	I've been thinking a lot about how to implement collision detection and with all the recent hype about T&L I've had to take that into consideration as well. My primary objective with the collision detection is precision, that means I have to do per-vertex detection. Since I keep all my objects in their own coordinate systems, I have to transform everything into worldspace before doing the collision detection - this is where the T&L comes into play. I assume that the geometry is stored in local T&L memory, so I only have to send the geometry to the T&L once. Furthermore I assume that you can retransform an object by just sending a new transformation matrix to the T&L. Worst-case scenario : Send all geometry to T&L; // only have to do this once Transform geometry; Fetch transformed geometry from T&L; Do Collision Detection (result = all objects collide with something); Retransform all geometry; Done; Best-case scenario : Send all geometry to T&L; // only have to do this once Transform geometry; Fetch transformed geometry from T&L; Do Collision Detection (result = no objects collisions); Done; What I'm worried about is the constant fetching of geometry. I realize that all this would be much less expensive if I just used bounding volumes, but I want precission. My question is this : Will the T&L speed things up under these conditions, or does the time spent sending geometry to and from the T&L chip, cancel out the time saved by not letting the cpu do the transformations.


	Simple answer. Don't ask 3D hardware to send anything back to the system. Long answer: All 3D hardware uses a very long pipeline (both in the hardware and in the driver) to accomplish its tasks quickly. When you ask for results back the hardware and driver flush this pipeline to get to the point where the data is valid and then return the data to you. It is not unheard of for a driver to have up to one and half frames worth of rendering commands (including the page flip!) in the pipeline waiting to be executed. Many folks will debate this topic one way or the other with regards to everything from reading back the frame or z-buffers, to requesting vertices back from the hardware but unless you know exactly what you're doing, and the exact system you're going to be working with (not likely in the PC world) then you can basically forget about asking the driver for its results. In some cases you can acheive better performance this way, but as a general rule of thumb it will be slower. Response provided by Tom Hubina

This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists.