#### Archived

This topic is now archived and is closed to further replies.

# Rotation Collision Detection

This topic is 6497 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

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

##### Share on other sites
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

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.

##### Share on other sites
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.

##### Share on other sites
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.."

##### Share on other sites
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.

1. 1
2. 2
Rutin
22
3. 3
4. 4
JoeJ
15
5. 5

• 14
• 30
• 13
• 11
• 11
• ### Forum Statistics

• Total Topics
631776
• Total Posts
3002300
×