Advertisement

Character Collision Detection with Level Geometry

Started by April 01, 2002 04:23 PM
2 comments, last by Tones2 22 years, 10 months ago
I''m trying to figure out the best way to implement collision detection in a 1st person 3D game for the characters OTHER than the main player / camera. I know that I can use sphere based collision detection to check between characters (after sectioning the world), but if I load an entire section of my level as a single mesh, I can''t figure out how to check for collisions with these characters again the level polygons (walls, etc). For the 1st person / camera player, I''m using sphere based collision for character intersection and D3DXIntersect for level-based polygons, which works great and is fairly efficient. But if I do D3DXIntersect for EVERY character against the level geometry, my engine will come to a HALT. I don''t want to break down the level mesh into it''s polygon components and do some type of quad-tree / plane check, since it''s in .X File format and difficult to do. I''m think of maybe segregating the level into individual walls, floors, etc. and do a transformed bounding BOX check for each component in that section against each character, though I''m not 100% how to maintain a rotated bounding box (spheres won''t work on a wall or floor). Are there any D3DX functions that can retrive a rotated bounding box on a mesh? Any other suggestions here? Thanks, Tony
The way I''m currently using is to split the world into cubes, with each cube containing a list of which polygons are contained. When doing a collision test, just pick which cube you are in and only scan those polygons. Fast and efficient. To make it even faster, use a seperate mesh that contains only those portions of the level to collision check (a simplified version of the level mesh). I spoke of using this method in my book.




Jim Adams
home.att.net/~rpgbook
Author, Programming Role-Playing Games with DirectX
Advertisement
Whether you use X files or not, at some point you are going to have to calculate at least a bounding box (if you go this direction). This type of processing can occur before hand, and you could store the data in a seperate file.




[edited by - taulin on April 2, 2002 1:26:44 AM]
If you are worried about losing your .x file simplicity, then you can still divide your world without seperating the mesh. When you load your level, divide it into "theoretical" cubes. You will end up with a list of "bounding boxes", each containing a list of polygons _inside_ the vertex buffer. Then, you check each monster against the bounding boxes, then check against the polygons indexed to by the current bounding box.

Also, as for rotations, etc. Don''t worry about them! Just use axis aligned bounding boxes and make them "roughly right". Bounding boxes aren''t meant to be 100% accurate =) They are simply a precursor stage so you can reject about 99% of the world geometry. Of course once you get this working you can refine and optimise etc, but it often helps to solve a problem simply, then build on that and advance your solution.

This topic is closed to new replies.

Advertisement