Rotation Collision Detection
Author
I''m implementing two different view systems for my game.
One, FPS view from a point were the viwe can rotate like every other FPS view and another 3rd person view that can rotate around the object just like in homeworld.
It''s easy to test for collisions of the first view - as long as the point we''re viewing from doesn''t go through walls, the view won''t - but what about the 3rd person view.
For the FPS view, these are the calls
glRotate(pitch,1,0,0);
glRotate(heading,0,1,0);
glTranlate(posx,posy,posz);
then the 3rd Person view is the opposite of course
glTranslate(0,0,-viewdist);
glRotate(pitch,1,0,0);
glRotate(viewangle,0,1,0);
How would I test that the transformed view position doesn''t move through mountains,walls?
Trigonometry, I suppose?
Chris
I don''t understand your question. There isn''t a general formula to test wheter a point hits a ''wall'' or not. It depenps on the structure of your wall or terrain. Is it out of triangles? Or polygons with >3 vertices?
in general I would do this:
save current position
move camera
test new point against all polys
if point outside
load saved position
But testing the point agains all polys of your scene could be slow since there could be thousands of them. You should consider to implement something like an octree. This way you can test only polys which are possible candidates for collision.
in general I would do this:
save current position
move camera
test new point against all polys
if point outside
load saved position
But testing the point agains all polys of your scene could be slow since there could be thousands of them. You should consider to implement something like an octree. This way you can test only polys which are possible candidates for collision.
Author
Thats basically the answer to the question - and I will do some kind of test reduction, but the actual problem is to work out the new point, using the point I am rotating about and the vector to the new one - I suppose it''s actually easy, just components of vectors
Thanks anyway.
Thanks anyway.
I don''t know how you handle your data, but if you''re using a BSP tree here''s one way to do it..
The standard BSP walk is mainly a series of front/back tests against a plane..you can use the same code to control the floating camera..
*Start at the root and recurse through the tree(as usual)..
*Do 2 front/back tests against the plane, one for the player and one for the camera..
*If the points are on opposite sides, there''s an intersection and you need to clip the camera against the plane, pushing it towards the side that the player is on..this is simply a matter of calculating the distance from the plane from each of the 2 points, getting a percentage, multiplying the camera vector by that percentage, and adding that to the camera position(or vice versa)..I always have a minimum clipping distance from any plane, so I just tack that on after I get the intersection..
*Here''s where it gets cool..if both points are on the same side you can totally ignore the other side of the BSP, and recurse on the same side the points are on..that way, assuming your tree is perfectly balanced, you eliminate half of the data to be tested at every iteration..
There''s some math involved, but not much..the method is solid and uses alot of the same code you would have in a normal BSP tree situation..I use the same principle for line of sight calculations(except you can stop when you find an intersection), and at one time for collision detection for static geometry(I''ve since gone the sector based lookup table route)..
BSP trees are great for clipping against the geometry, which is basically what you want to do with the camera(in relation to the player)..by testing against both points you can still use the BSP structure and not have to write alot of new code..
If you need clarification about the math involved feel free to email
"Like all good things, it starts with a monkey.."
The standard BSP walk is mainly a series of front/back tests against a plane..you can use the same code to control the floating camera..
*Start at the root and recurse through the tree(as usual)..
*Do 2 front/back tests against the plane, one for the player and one for the camera..
*If the points are on opposite sides, there''s an intersection and you need to clip the camera against the plane, pushing it towards the side that the player is on..this is simply a matter of calculating the distance from the plane from each of the 2 points, getting a percentage, multiplying the camera vector by that percentage, and adding that to the camera position(or vice versa)..I always have a minimum clipping distance from any plane, so I just tack that on after I get the intersection..
*Here''s where it gets cool..if both points are on the same side you can totally ignore the other side of the BSP, and recurse on the same side the points are on..that way, assuming your tree is perfectly balanced, you eliminate half of the data to be tested at every iteration..
There''s some math involved, but not much..the method is solid and uses alot of the same code you would have in a normal BSP tree situation..I use the same principle for line of sight calculations(except you can stop when you find an intersection), and at one time for collision detection for static geometry(I''ve since gone the sector based lookup table route)..
BSP trees are great for clipping against the geometry, which is basically what you want to do with the camera(in relation to the player)..by testing against both points you can still use the BSP structure and not have to write alot of new code..
If you need clarification about the math involved feel free to email
"Like all good things, it starts with a monkey.."
Author
To be honest - I have not implemented any sort of BSP code or anything like that - I am new to 3D stuff and am still in the process of learning the OpenGL API.
Your advice looked very solid - and I''ve saved the text for future reference when I get there. Thanks anyway.
I can see how to do the opposite side check though.
Your advice looked very solid - and I''ve saved the text for future reference when I get there. Thanks anyway.
I can see how to do the opposite side check though.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
