   Collision Data
  I've ran into a problem in my game design where I'm thinking of storing collision data separate from rendering data (i.e. mesh data). The problem is I'm not to sure on what data I want for collisions, initially I was just going to place some axis aligned bounding boxes around the scene to represent walls etc. but for anything that is not axis-aligned (slopes etc.) this is a very limited method. So I now have two problems... what should I actually use for the collision data? and how do I build it on top of the rendering data?I know old games like quake used brushes which stored triangles that were used for both collision and rendering and because they used a bsp-tree they could determine when a specific point was inside or outside a mesh. So What do modern games use? and do they also need to construct collision data separate?   
Quote:what should I actually use for the collision data?That depends entirely on what your collision engine needs to work, or what type of collisions you want your collision engine to detect, combined with the method you want to use to render your objects.The collision engine doesn't render the object so you can use collision geometry data for rendering if you like. Or you may choose to simplify the collision geometry data to a box, sphere, cylinder, etc., for faster detection and render the objects from separate data for more visual detail.There are several collision engines commonly used ( bullet, physx, ODE, etc. ) and each requires data stored in slightly different ways.ODE, for instance, can generate AABBs from detailed geometry data and use that for culling collisions. If a potential collision between AABBs is detected, more detailed triangle collisions can be evaluated. You can choose to use the collision detection data to render, or use a separate data buffer if you want the visual object to be different than the collision object.Do I understand your question?   ;Quote:Do I understand your question?I think you've got it the wrong way around, I'm not going to be using the collision data for rendering but I could *possibly* use the rendering data for collision (i.e the triangles). I've tried this approach before and (looking back) I think its a bad idea, the only good thing about it is that you just need to export one set of data.If for instance you have a highly detailed object with lots of triangles then it would be more efficient and robust to just place an axis aligned abounding box around this rather than check for a collision against each triangle.I used axis aligned bounding boxes in a game that I finished not that long ago and the only bad thing about it was the fact that you couldn't get sloped surfaces etc.I was just wondering how other games might approach this?   ;  Firstly, I'll mention again what Buckeye did.  Look at physics engines like Bullet, PhysX, ODE, and Havok.In a lot of cases, you can get away with just using the visual mesh as a collision mesh. But that approach can fall apart fast.  On the other hand, using seperate collision data can have downsides too.  It is all a balancing act.* Mesh collision is slow.  Giving game objects primitive shapes like "box" and "sphere" can speed up collision immensely.* Visual meshes make for bumpy collision meshes.  Artists put a lot of detail into the visual mesh, but a lot of times it is nice to have a smooth collision mesh to keep things from bouncing around all funny or getting stuck.* Visual meshes contain visual information. You want collision information. Artists might have 10 different textures for "dirt", combined with lots of little detail objects like weeds and tufts of grass.  You don't care about any of that, because all of those count as "dirt" for gameplay. So, your collision data might contain extra information about the surfaces that the visual mesh doesn't.* Visual meshes have optimal formats that differ from the optimal formats of collision. You may have to process the visual mesh to create the collision mesh anyway.* Using two meshes means twice the data.* Using a simplified collision mesh can be good for gameplay by providing a smooth area to walk in. It can also be bad, because you'll have areas that look like you can walk there, or shoot there, but the mesh doesn't have the detail and blocks your player.Most those physics engines have plugins for Maya and other 3d tools.  You can also write your own exporters for those tools. That way you can place collision along side your visuals when making your levels.My last 3 games all used the approach of having seperated collision and visual meshes.  The collision mesh/primitives contained metadata about the surfaces, for what effects/sounds/gameplay happened when you collided with them.   ;  Thanks a lot, that's all I wanted to know.