Collision Problem
by Steve Lamperti · in Torque Game Engine · 10/05/2005 (5:28 pm) · 4 replies
I'm having a lot of trouble with a collision problem, and I'm hoping that if I post it here, someone will have had a similar problem, and will be able to offer some hints to help me stop banging my head against the wall. (Another collision problem that I hope to resolve ;)
What's happening is that I have built a class of objects that descend from Item, but I've added quite a bit of functionality to them. A lot of the collision behavior is borrowed from Player. (For example the default Item code for collision doesn't deal well with scaling at all, and the player code is better.) The problem I am trying to resolve is that I move these items on paths, and when they take a right angle turn, they sometimes stick to each other. The first one will get to the 'corner' of the path, and the next one will bump up against it, and the first one will stop moving, colliding with the one behind it, even though it's path of motion should be perpendicular to the surface of the bounding box of the following object.
The funny thing is that this only happens about one time out of 20 or so, and I don't see any real pattern to when it happens. I've stepped through the collision code many times, and it's definately getting a collision with the object that is beside/behind it on the path, but I can't figure out why, or why it only happens sometimes.
If anyone has any suggestions, or any requests for more information about the question, please post. As I said, I've been banging my head against the wall for a while, and could use a rest.
What's happening is that I have built a class of objects that descend from Item, but I've added quite a bit of functionality to them. A lot of the collision behavior is borrowed from Player. (For example the default Item code for collision doesn't deal well with scaling at all, and the player code is better.) The problem I am trying to resolve is that I move these items on paths, and when they take a right angle turn, they sometimes stick to each other. The first one will get to the 'corner' of the path, and the next one will bump up against it, and the first one will stop moving, colliding with the one behind it, even though it's path of motion should be perpendicular to the surface of the bounding box of the following object.
The funny thing is that this only happens about one time out of 20 or so, and I don't see any real pattern to when it happens. I've stepped through the collision code many times, and it's definately getting a collision with the object that is beside/behind it on the path, but I can't figure out why, or why it only happens sometimes.
If anyone has any suggestions, or any requests for more information about the question, please post. As I said, I've been banging my head against the wall for a while, and could use a rest.
#2
http://www.garagegames.com/mg/forums/result.thread.php?qt=33044
or I think adding some bounce to the player code in player.cc helps alot.
10/06/2005 (4:07 pm)
I think i know what you mean..It may be something to do with the bug report on this threadhttp://www.garagegames.com/mg/forums/result.thread.php?qt=33044
or I think adding some bounce to the player code in player.cc helps alot.
#3
Thanks for the response. That does look relevant to my question, but I'm afraid I'm a bit too much of a novice at 3D graphic math to understand much of the descriptions of what's happening. Does anyone know where I could find a basic description of the math involved? Specifically the normals and which way the various planes are facing, and the stuff Josh is talking about about eliminating certain normals that should not be involved in the collision calculation. I realize that this is probably pretty basic to many of the people developing with the TGE, but I have a slightly different background, and haven't been exposed to this math.
An internet article would be fine, a book recommendation would be great as well, especially if it's pretty tailored to the math being used here.
10/07/2005 (5:06 pm)
@Brian,Thanks for the response. That does look relevant to my question, but I'm afraid I'm a bit too much of a novice at 3D graphic math to understand much of the descriptions of what's happening. Does anyone know where I could find a basic description of the math involved? Specifically the normals and which way the various planes are facing, and the stuff Josh is talking about about eliminating certain normals that should not be involved in the collision calculation. I realize that this is probably pretty basic to many of the people developing with the TGE, but I have a slightly different background, and haven't been exposed to this math.
An internet article would be fine, a book recommendation would be great as well, especially if it's pretty tailored to the math being used here.
#4
My collision code uses the Extruded poly setup code from Player, that includes this code
plistBox.min.setMin(oldMin + (mVelocity * time) - Point3F(0.1, 0.1, 0.1));
plistBox.max.setMax(oldMax + (mVelocity * time) + Point3F(0.1, 0.1, 0.1));
What I think that this is doing, is to make the extruded box a little bigger then the original box, so it will collide with items that are close to its path. This makes sense, but I think what is happening is that my objects move in one direction until they are very close to each other, and then they change direction, and this code means that the extruded box is already overlapping the object that the moving object is adjacent to. So they get stuck, as they are already collided with the object that they are up against. I've tried removing the - Point3F, and the + Point3F, but that seems to break the collision code completely.
If anyone has any suggestions, I would appreciate it.
01/09/2006 (11:41 am)
I'm revisiting this problem, and I think I have a little better idea what is happening in my case, at least. I'm posting some additional information in case anyone has any suggestions that may help me.My collision code uses the Extruded poly setup code from Player, that includes this code
plistBox.min.setMin(oldMin + (mVelocity * time) - Point3F(0.1, 0.1, 0.1));
plistBox.max.setMax(oldMax + (mVelocity * time) + Point3F(0.1, 0.1, 0.1));
What I think that this is doing, is to make the extruded box a little bigger then the original box, so it will collide with items that are close to its path. This makes sense, but I think what is happening is that my objects move in one direction until they are very close to each other, and then they change direction, and this code means that the extruded box is already overlapping the object that the moving object is adjacent to. So they get stuck, as they are already collided with the object that they are up against. I've tried removing the - Point3F, and the + Point3F, but that seems to break the collision code completely.
If anyone has any suggestions, I would appreciate it.
Torque Owner Steve Lamperti
Imagine That!