Robust collision response
I''m checking for collisions with sphere triangle tests, no probs. When it comes to collision response, it''s proving more difficult.
To implement effective sliding when colliding with more than one poly/plane, one must find out which polygons were hit first, slide parallel to their planes, repeat.
But finding which collision was first, especially when we come to polygons very close together, using linear subdivision methods can become _VERY_ computationaly expensive. Imagine hitting the two planes within a fraction of a world point, hundreds of subdivisions may have to be done. And if they are hit at the same time, an infinite loop will result.
Defining a cut-off point proves too inefficient, and results in poor response.
Can anyone with experience suggest a way to handle such multiple collisions?
Any help would be greatly appreciated.
BTW: No, I''m not using BSPs, and line-triangle tests are no good, due to the lack of any radius, and sliding parallel to all planes would result in an incorrect vector, stopping sliding at right angles etc.
It seems like collision detection is ''theme of the month'' around here!
This is how I see your problem;
If the player is sliding, he is either standing on a steep surface and gravity takes its toll, or he is ''scraping'' along a wall whilst moving forwards. We need to detect if a second collision comes into effect, because he''s either slid down into a wall, or walked right into a corner.
I think your problem may lie, not with calculations, but with logic.
When the first collision occurs, we can flag this as ''SolidBoundaryHit'' or whatever, then when we next do our collision detection we can take this into account. Unless the user has taken some other action to change the state of ''SolidBoundaryHit'' (by changing direction or something) we''ll only look for other collisions...
Now if two collisions occur together, treat them as one collision!
Hope this gives some food for thought. I''m hoping to implement a ''scraping'' system into my driving game soon so I''d be interested in your reaction.
Regards
Matt
See my project at: www.btinternet.com/~Matthew.Bennett
This is how I see your problem;
If the player is sliding, he is either standing on a steep surface and gravity takes its toll, or he is ''scraping'' along a wall whilst moving forwards. We need to detect if a second collision comes into effect, because he''s either slid down into a wall, or walked right into a corner.
I think your problem may lie, not with calculations, but with logic.
When the first collision occurs, we can flag this as ''SolidBoundaryHit'' or whatever, then when we next do our collision detection we can take this into account. Unless the user has taken some other action to change the state of ''SolidBoundaryHit'' (by changing direction or something) we''ll only look for other collisions...
Now if two collisions occur together, treat them as one collision!
Hope this gives some food for thought. I''m hoping to implement a ''scraping'' system into my driving game soon so I''d be interested in your reaction.
Regards
Matt
See my project at: www.btinternet.com/~Matthew.Bennett
There are still a few problems, such as if the camera collides with two polygons quite close together without first scraping, calculations still need to be done, and at best, approximations are acceptable(back to square one).
But as most problems arise due to 'scraping' along items, it looks like this is the best way to handle things, short of knowing the exact collision spot to determine the first hit plane.
Thanks for the valuable help, Matt.
Edited by - IDC on 4/5/00 6:41:00 PM
But as most problems arise due to 'scraping' along items, it looks like this is the best way to handle things, short of knowing the exact collision spot to determine the first hit plane.
Thanks for the valuable help, Matt.
Edited by - IDC on 4/5/00 6:41:00 PM
What about analytic way of hit_time/point calculation ? (and not iterpolation). This would either yeld exact result, and it needs constant time. Not really trivial to get the formulas out, but sphere against poly is possible... (many special case should be considered, I wouldn''t like to code it ))
So if you do firstly some rought detection, and than you calculate the exact collision just with few polys, it should be fast enough.
---------------------------------------------------
Ped - Peter Helcmanovsky - 7 Gods demo group
http://7gods.rulez.sk
First Sight Entertainment - http://members.xoom.com/fseteam
---------------------------------------------------
So if you do firstly some rought detection, and than you calculate the exact collision just with few polys, it should be fast enough.
---------------------------------------------------
Ped - Peter Helcmanovsky - 7 Gods demo group
http://7gods.rulez.sk
First Sight Entertainment - http://members.xoom.com/fseteam
---------------------------------------------------
Use linear interpolation after checking for overlaps.
What I mean is:
1. check all objects in world with bounding box.
2. when two boxes collide, check all vertices with bounding boxes.
3. if 2 meet, at an angle with another two then linear interpolate the direction and limit movement on that vector.
leave all other vectors free and repeat test the next frame.
this method is well fast. the trick is to appear to collide effectively and behave properly. fake it baby.
What I mean is:
1. check all objects in world with bounding box.
2. when two boxes collide, check all vertices with bounding boxes.
3. if 2 meet, at an angle with another two then linear interpolate the direction and limit movement on that vector.
leave all other vectors free and repeat test the next frame.
this method is well fast. the trick is to appear to collide effectively and behave properly. fake it baby.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement