Why do we use physics engines for collision testing or raycasting?

Hello. There is a thing I don't understand about game engines: why it is so common to use physics engines to do raycasting or collision testing?

Say that you have a 3D scene loaded in your scene manager (Ogre or whatever) and you have to do some raycasting. Is it really efficient to load all your objects in the physical or collision world just to test them for intersection? Why do game engines don't implement the same structures so you don't need to load a physics engine? This sounds like a waste of resources, especially if you don't need physics.

From game development tunnuz

• (Rigid-body) Physics is collision testing, raycasting, and response. There's no magic pixie dust that changes that combination into "physics engine" - if you need collision testing and raycasting, you need some kind of physics engine, whether you use an existing one or roll your own.

  tunnuz : That doesn't answer my question. Raycasting is a geometric technique, why it is implemented in Bullet, but not in Ogre? Why should I load Bullet to do raycasting on an Ogre scene? I guess this has to do with how the scene is represented in Bullet, so why this representation is not implemented directly in Ogre?

  tunnuz : I mean, the representation could be a BSP, which is also useful in Ogre for back-to-front polygon sorting in order to do polygon-precise transparencies.

  Joe Wreschnig : All you are asking is "Why doesn't OGRE include a physics engine?" or maybe "Why doesn't OGRE include a bad physics engine?" The answer is because plenty of physics engines already exist.

  Kaj : This is a bold statement, and not true. If you need raycasting and collision testing you need a collision detection engine. If you want the to simulate rigid bodies that respond to collisions you need a physics engine. The only reason people use physics engines for collision testing is that (a)you can have it resolve collisions for you to prevent penetrations and (b) since collision detection is such a huge and important part of any physics simulation the implementation is likely more optimal than something you could whip up yourself.

  Joe Wreschnig : @Kaj: Like I said unless you are making a game where the only response to collision is deletion, here's where the asker's thought process invariably takes you: "I don't need physics, just collisions and raycasts!" -> "But my objects move, so I need something aware of all the objects' motions each frame or I'll get tunnelling" -> "Oh crap I have penetration, now I need the collision code to move objects" -> "Now it's not stable, I need it to manage forces and inertia, not just flat-out move stuff" -> This is a rigid-body physics engine.

  Kaj : Hmmm, from his/her question I assumed he was asking 'if I only need raycasting or coldet', say for object picking or some sort of collection game, or heck a shooter where every collision if fatal. In that case no physics are needed at all, although in many instances, if you can't get away with sphere/sphere I'd opt to abuse a physics engine for that anyhow.
  From Joe Wreschnig

• Is it really efficient to load all your objects in the physical or collision world just to test them for intersection?

  Yes it is efficient... for the programmer. There are lots of physics engines around and it's far easier to just use one - than to strip one down, or implement raycasting yourself.

  Talking about code (in fairly rough terms):

  You've got the code to create physics objects (you're not going to coldet/raycast against fully triangulated models, are you?) in a data structure that is efficient for doing coldet/raycast (you're not going to bruteforce it, are you?). And then some wasted code for various physical properties (and depending on the physics engine you can probably avoid much of this). Plus the CPU and memory requirements for the same (relatively small).

  Then you've got the raycasting code. You need that in any case.

  And finally the rest of the physics simulation code - which just sits in its binaries, never executed, never loaded to cache. Code doesn't take up much space anyway.

  So the "wastage" here is utterly minuscule. Especially compared to the massive effort involved in replacing or stripping down half a physics engine.

  Joe Wreschnig : You still need some of the code for physical properties ("this is one-sided", "this causes a sound when collided with") regardless of whether you use a "not physics engine" or a physics engine, unless your game is really boring. As for the physics simulation code, you will need some of that in order to perform stably when resolving collisions, unless the only thing that happens on collision in your game is death.

  dash-tom-bang : We used the GPU on the (first) PlayStation to do our raycasts. Render the scene real quick from the "shooter", each entity a different color. Whatever color the center pixel is tells you the thing you hit... :)
  From Andrew Russell

• Raycasting and collision detection is a smaller subset of a physics engine. Therefore most people use physics engines for this task and they generally have a good implementation of these functions.

  You can use the the collisions detection and raycasting features of a physics engine without using the Rigid Body dynamics part. For example Bullet has a btCollisionWorld class that just does the basic collision and raycasting. btDynamicsWorld is built on top of that.

  ODE (another popular but older physics engine) uses OPCODE (downloadable as a separate library) for its collision and raycasting.

  From lloydw