   Best and easiest  way to handle collision
  For the past few months i've been trying to find the best way to handle collisions, and heared a lot about AABBs, triangles, ellipsiods, OBBs, and the like, through various tutorials, sites, and posts, but nothing straight forward, hard code or tangible for me. So i come and present my case to you:I have a 3D model and a 3d scene, made of triangles(no need for speed improvements), i do not need fancy physics, i just want to prevent him from going through the walls, but i DON'T want:If collides, go back to last pointSee what i mean?I seem to get the Collision Detection Part, but its the Reponse that i can't seem to comprehendAlso, the model is animated and rotates without a chnage in the velocity. Thanx!   
  Are you looking for the object to "bounce" off whatever it hits?  If you can detect a collision, what behavior do you want when a collision IS detected?   ;  If you want your objects to bounce around realisticly you'll have to simulate them using 'rigidbody dynamics'.  Just do a google search for these key words, there's plenty of free resources out there which explain the dynamics of rigidbodies and how to apply collision impulses to them to have them bounce of scenery and each other in a realistic fashion.  In particular you might want to read up on Chris Heckers tutorials we pointed you to in your last thread or for an in depth view I recommend tracking down any papers by Baraff such as:www.cs.cmu.edu/~baraff/sigcourse/notesd1.pdfIf you have any problems understanding this stuff you know where to come ^_^   ;Quote:Original post by TheC00L1no need for speed improvementsAre you Sure? triangle soup sounds potentially slow, as well as prone to problems with accurate collision detection (thin wall vs fast bullet problem)The Easiest way to deal with collisions, so you don't have to mess with the difficult response, is to set the object's health to 0, animate a little explosion or death animation, then delete it.This is done in many arcade games, as well as even more recently in Halo1; whenever a player touched a moving vehicle he died instantly, because it was simpler than calculating the soft vs solid body collision responce.Other responce ideas include:bouncing, or slidingbouncing is pretty easy, you just reflect the velocity of the object against the plane it collided along.for sliding, you project the velocity onto the collision plane; this gets complicated if you hit more than one plane at once or in succesion, since you'd have to figure out which came first and continue checking after each new slideYeah, Kill Player has got to be the easiest collision responce.   ;Quote:Original post by haphazardlynamedQuote:Original post by TheC00L1no need for speed improvementsAre you Sure? triangle soup sounds potentially slow, as well as prone to problems with accurate collision detection (thin wall vs fast bullet problem)What i meant was i can always do the octtree or bsp, later, i just want to be able to responed before things get to complex.  As for the fast collison detection i was going to turn the points into lines if it has a squared distance(x*x+y*y+z*z) greater than whatever.Quote:If you want your objects to bounce around realisticly you'll have to simulate them using 'rigidbody dynamics'. Just do a google search for these key words, there's plenty of free resources out there which explain the dynamics of rigidbodies and how to apply collision impulses to them to have them bounce of scenery and each other in a realistic fashion. In particular you might want to read up on Chris Heckers tutorials we pointed you to in your last thread or for an in depth view I recommend tracking down any papers by Baraff such as:www.cs.cmu.edu/~baraff/sigcourse/notesd1.pdfIf you have any problems understanding this stuff you know where to come ^_^ Yeah, thanx Motorherp for your last reponse on my AABB thing, The rigid body stuff is pretty tempting, but i don't want anything fancy yet, but i might just have to do it, that link actually wasn't that bad. And Chris Hecker's stuff has to do a lot with 2D and not clear enough about 3D response part, it has 3D rgid body, but not exacty what i'm look for.Quote:Are you looking for the object to "bounce" off whatever it hits? If you can detect a collision, what behavior do you want when a collision IS detected?Well, i got a book, and i tested the functions and they did work on my testing enviroment. But i have a problem with fact that i don't want the character to go through walls, and sometimes bouncing has a problem.Quote:The Easiest way to deal with collisions, so you don't have to mess with the difficult response, is to set the object's health to 0, animate a little explosion or death animation, then delete it.This is done in many arcade games, as well as even more recently in Halo1; Yeah, Kill Player has got to be the easiest collision responce.I could do that with the builits, but killing him does not make it fun, when he falls on the ground or hits a wall. Plus I want gravity to have a share in all the polygons not just the ones facng almost or directly up. I guess i could try the bounce part, since i haven't yet, though since my objects are iregulary shaped, like there's hands that stick out, i might have to do the rigid body stuff. Quote:for sliding, you project the velocity onto the collision plane; this gets complicated if you hit more than one plane at once or in succesion, since you'd have to figure out which came first and continue checking after each new slideYeah, sliding sounds better, is it better for irregularly shaped object, there could be a problem where, like a protruding rock hits the inside of his hand, as he rotates. But i'm not sure what i should include, maybe it is the rigid body. Should i take a physics engine and plug it into my geometry?Have any of you designed the collision reponse part in a 3D game before? Thanx for your time and patience.   ;Quote:Original post by TheC00L1But i'm not sure what i should include, maybe it is the rigid body. Should i take a physics engine and plug it into my geometry?Have any of you designed the collision reponse part in a 3D game before?Yup I certainly have, I'm a proffesional games programmer and I specialise in systems such as collision detecton and response, vehicle dynamics, ragdoll, etc.  Anyways now that I know that you're talking about colliding a player controlled character this makes the situation a lot different.  Rigidbody collision response is definately the way to go for objects such as furniture and vehicles but you'll find using this for a player character will just create a very fustrating user experience.  For these situations you'll want to go more with a sliding type collision response.  This can actualy be very simple to implement in your typical 1st/3rd person game environments since the scenery polygons tend to be fairly large.  Basicaly you need to calculate the amount by which the character penetrates the scenery in the direction of the normal of the triangle the character intersects with.  Then simply translate the character that distance in the direction of the tri normal so penetration no longer occurs.  This will allow the player to slide along walls without penetration and without hinderance to his movement along the wall.  For higher resolution environments or scenery with very sharp concave corners you might need a more sophisticated approach however since it might be possible for the character to cross many triangles in one frame or get stuck in an infinite collision loop between facing triangles.  In this case I'd recommend using predictive collision routines and only move the character up to the time of the first collision.  At this point it will be a matter of trying different approaches to see what works best for your game.  You could just leave it here but that would lead to your character seeming to get stuck.  You could try pushing the character out along the collision normal slightly, or maybe even canceling out his movement velocity in the collision normal direction and continue to update his motion over the rest of the frame with his new velocity.   ;Quote:Basicaly you need to calculate the amount by which the character penetrates the scenery in the direction of the normal of the triangle the character intersects with. Then simply translate the character that distance in the direction of the tri normal so penetration no longer occurs.Now, how you do this, like calculate the distance of pentration(using the plane?)? Would i just use the point which overlaps the trangle, and what about when both trangles intersect each other as opposed to one piercing the other?Quote:Yup I certainly have, I'm a proffesional games programmer and I specialise in systems such as collision detecton and response, vehicle dynamics, ragdoll, etc. Anyways now that I know that you're talking about colliding a player controlled character this makes the situation a lot different. Rigidbody collision response is definately the way to go for objects such as furniture and vehicles but you'll find using this for a player character will just create a very fustrating user experience. For these situations you'll want to go more with a sliding type collision response. This probaly a very trivial task for you, isn't it.I Bob Janova gave me some information, but i couldn't get it to work: http://www.gamedev.net/community/forums/topic.asp?topic_id=396096   ;Quote:Original post by TheC00L1Now, how you do this, like calculate the distance of pentration(using the plane?)? Would i just use the point which overlaps the trangle, and what about when both trangles intersect each other as opposed to one piercing the other?Again it really depends the specifics of your environment and the type of game experience you're trying to create.  However for typical situations where you're dealing with terrain whos features and curvature are generaly much larger than the triangles that make them up then its usualy sufficient just to treat the intersecting terrain tri as a plane.  Simply calculate the depth of each penetrating point of the body below this plane and use the largest distance to push the body out along the plane normal.  If you start faffing around with detecting tri edge collisions and the like you'll end up with situations where objects cant slide smoothly across flat expanses made up of many triagles without difficulties.  Maybe if you posted a screen shot of your character and terrain it would give me a better idea on what to suggest.;Quote:Maybe if you posted a screen shot of your character and terrain it would give me a better idea on what to suggest.Will do... it might just clear a lot up.ignore the white boxes, yeah, i'm planning on textureing it, but not till i got collision down.   ;  Looks good.  Rightio for this kind of thing I think you're going about this the wrong way.  You'll no doubt find it sufficient to simply treat the characters collision geometry as an OBB which encompases him and collide this with the scenery rather than trying to collide his tri's.  Simply treating the intersecting tri's as planes will give you the desired sliding along and around walls behaviour for the most part without catching on tri edges.  The only problem you'll get is when walking directly at a sharp convex corner which will cause the character to suddenly pop slightly to the left or right when you connect with it.  You could probably detect these circumstances though because non of the OBB verts will be on the penetrating half of either of the planes belonging to the tris which intersect the box and project into the triangle face at the same time.  In this case treat the collision resolution differently by seperating using the tri's penetration depth into the box along the box axes.Its getting on a bit over in the uk now though and I'm getting tired so you might want to think that through for yourself to make sure it'll work ^^[edit:] .... urggh definately getting tired.  If your characters box always has its y axis pointing directly up then you'll be able to detect these special corner cases because one of the tri verts will project inside the rectacle that the OBB projects onto the x-z plane.  That would be easier to calculate   