in
Welcome to Lionhead Community Sign in to Windows Live ID | Help

Last post 10-14-2001, 11:28 by Scrambled_Egg. 0 replies.
Sort Posts: Previous Next
  •  10-14-2001, 11:28 299728

    After going through all the john nettle / telemachos ellipse collision detection (on flipcode), and getting disappointed with the results, I've become more and more convinced that as far as moving characters about in static 3d levels is concerned, offset surface collision detection (in a similar manner to stan melax shifting plane bsp, and it sounds as though quake uses this technique as well from melax's article) is the way to go. There are just a few things not too clear to me before I implement it. 1) It seems that the technique to use to get the character correctly seated on the floor is : a) get the current position of the point (probably sphere centre) assuming it is seated on the floor b) add the maximum step up distance to the z height of this position c) test from this raised position along a line segment in the direction of the velocity d) assuming no collisions, perform a second test downwards from the new raised position to find the new seated position on the floor e) repeat Is this correct? 2) Although the system above will enable the character to clamber over all kinds of obstacles on the ground, it has occurred to me that the character will still get stuck on obstacles along walls, such as beams. The reason is that when the character slides into the expanded geometry of a beam, the normal of the beam is exactly opposite to the direction of slide, hence the character will get stuck. I have tried this out with the demo from stan melax's site and this 'getting stuck' does occur in his implementation. Unfortunately, our level geometry contains lots of beams and obstacles in walls, and getting stuck at each tiny little beam in a wall would be a severe problem for gameplay. We could build physics proxy geometry for the beams etc however this isn't a very good solution, as it adds a huge burden to the workload of our artists, so it would be better to come up with a programming solution. What I was using before was creating my own sliding vector, based on the vector between a sphere centre and the point of collision, rather than the surface normal.. however I am not sure whether this approach will solve the problem using this offset surface technique. Another solution might be to bevel the beam corner and create new sliding polys. Has anyone had any experience of this problem or could anyone suggest any solutions?
View as RSS news feed in XML