   VBO & Collision?
  This is about collision detection but still related to openGL.I recently implemented VBO's into my code which is fantastic. But I've been looking into the many common collision detection algorithms out there and found myself questioning how to store or deal with the data.Either a) I need to do the collision detection on the GPUor b) I need to access the mesh data for collision on the GPU to calculate it externallyor c) I need to store 2 seperate sets of data (one for rendering, one for collision)Any suggestions would be appreciated on how to do this. I'm currently looking at sticking to bounding spheres and then just per polygon collision.Thanks.   
  collision detection is usually not handled on the gpu (and it would be slow anyway)the nomral method is c have a render mesh + a collision mesh, usually the collision mesh is simplified eg done with a sphere or like in quake3 halflife etc a few boxes   ;  Cheers... now I guess one more question which is a bit further off from this...  and I realize it doesn't directly relate to openGL but its part of the same problem I'm dealing with so I hope its okay. (oh, also, I took at look at your site zedzeek, game looks good man!)Theres a few articles I've read on ellipsoid collision. The one I'm interested in  specifically is one by Kasper Fauerby. He explains with the example of an FPS. Using a ellipsoid to be more accurate as a bounding shape for a human, and then converting everything to ellipsoid space in order to just work with spheres.(Hope this makes sense, but basically if the ellipsoid is 3, 4, 5, you change your basis for everything to match that)In my mind, this does not take into account if the ellipse rotates. in my case the object follows the terrain (a vehicle that fits in an ellipse) so it will rotate on all axis (potentially)... so I would figure you need to rework all verts relative to the rotation.I hope this makes some sense... its hard to explain. Again advice is appreciated.   ;Quote:Original post by greyrootTheres a few articles I've read on ellipsoid collision. The one I'm interested in  specifically is one by Kasper Fauerby. He explains with the example of an FPS. Using a ellipsoid to be more accurate as a bounding shape for a human, and then converting everything to ellipsoid space in order to just work with spheres.(Hope this makes sense, but basically if the ellipsoid is 3, 4, 5, you change your basis for everything to match that)I would advice against that paper, and about using ellipsoids altogether. The first "edition" of that paper overlooked the edge and verctor collision cases which at least on my implementation caused the algorithm to explode, once I implemented edge and vector cases (using voronoi regions), the code ended too complex and in my eyes quite inelegant.That would had been fine if it worked on all cases, however, due to the quasi-recursive nature of the algorithm (you have to run the algorithm over and over until it returns with no collisions), there were cases such as when the ellipsoid ended over a gap between 2 "walls" on which it did not fit, then an infinite loop would araise, locking the simulation.I would instead recomend looking into AABB or capsule collision detection against a BSP, such as the one Quake 3 uses.Quote:Original post by greyrootIn my mind, this does not take into account if the ellipse rotates. in my case the object follows the terrain (a vehicle that fits in an ellipse) so it will rotate on all axis (potentially)... so I would figure you need to rework all verts relative to the rotation.Yes, rotation is not taken into consideration, and you shouldnt need it since the paper is meant for humanoid characters, which dont follow the slope of the terrain, for a vehicle, you would be better off using spheres for each wheel (4 in the case of a car) and perhaps an object oriented box for the vehicle body.   