Item and Interior Collision bug
by Josh Albrecht · in Torque Game Engine · 08/04/2005 (8:05 pm) · 20 replies
I am encountering the same bug reported in this thread:
www.garagegames.com/mg/forums/result.thread.php?qt=32210
Basically, if you make an Item slide along the surface of a DIF it will experience collisions with invisible planes that make no sense. The normal of the collision will be basically parallel with the surface of the DIF. The collisions happen at the seams of the brushes used to make the DIF and the collision normals are perpendicular to these edges (I think).
This bug was also reported in another thread quite some time ago, but I've since lost the link. :( However, one of the suggestions to solve it was to use the player movement code. Unfortunately, I tried that and it did not work. The ball STILL hits things that arent there, and even the item::step function (ripped almost directly from player::step) fails to step over them sometimes because they occur at points below where the ball should be.
The only way I've found of getting around these collisions is to refuse to collide with any edge that does not pass this test:
It didnt even work when I tried using 0.1 instead of 0.3, which means that some of these invisible edges must be pointing upwards. However, all my brushes in the file I used to generate the DIF of of the same format. They have vertical side planes that are marked as NULL, and a single textured triangle on the top. There are a few hundred of these that form a relatively flat looking mesh. Almost all of the normals of the textured surfaces would probably have a zdot of 0.7 or higher. There are only a few polys that are the exception to this rule, but they are grouped in one area of the mesh (so they arent involved in the problem collisions), but they are crucial to the gameplay and I cant simply refuse to collide with them.
I've worked on this problem for days, and I'm stumped.
Does anyone have a clue what is causing this problem? Any help, pointers, common experiences would be helpful.
Thanks!
www.garagegames.com/mg/forums/result.thread.php?qt=32210
Basically, if you make an Item slide along the surface of a DIF it will experience collisions with invisible planes that make no sense. The normal of the collision will be basically parallel with the surface of the DIF. The collisions happen at the seams of the brushes used to make the DIF and the collision normals are perpendicular to these edges (I think).
This bug was also reported in another thread quite some time ago, but I've since lost the link. :( However, one of the suggestions to solve it was to use the player movement code. Unfortunately, I tried that and it did not work. The ball STILL hits things that arent there, and even the item::step function (ripped almost directly from player::step) fails to step over them sometimes because they occur at points below where the ball should be.
The only way I've found of getting around these collisions is to refuse to collide with any edge that does not pass this test:
F32 zdot = mDot(Point3F(0,0,1), normal);
if(zdot > 0.3)
{
//then the normal is ok, we can collide with this plane
}It didnt even work when I tried using 0.1 instead of 0.3, which means that some of these invisible edges must be pointing upwards. However, all my brushes in the file I used to generate the DIF of of the same format. They have vertical side planes that are marked as NULL, and a single textured triangle on the top. There are a few hundred of these that form a relatively flat looking mesh. Almost all of the normals of the textured surfaces would probably have a zdot of 0.7 or higher. There are only a few polys that are the exception to this rule, but they are grouped in one area of the mesh (so they arent involved in the problem collisions), but they are crucial to the gameplay and I cant simply refuse to collide with them.
I've worked on this problem for days, and I'm stumped.
Does anyone have a clue what is causing this problem? Any help, pointers, common experiences would be helpful.
Thanks!
#2
I took your advice and rendered the polys that were involved in the bad collisions, and I found that some of them are YARDS away from where my Item is. There is no way it should be colliding with these polygons. Here is what a typical brush in my DIF looks like:
|.\
|...\
|.....\
|......|
|......|
|......|
|......|
|___|
This is a side view of the brush. ASCII isnt necessarily the best art tool, so you'll have to pretend that the slope of that top plane is much less steep. The plane on the top is a triangle, and the bottom plane is an unsloped version of that same triangle, and there are 3 square vertical sides to the brush. I hope that makes sense. A few hundred of these brushes make up the surface I want to collide with.
Now, the poly that the Item is colliding with is that BOTTOM plane, the one that would have a normal of (0,0,-1). And the ball is moving across the TOP of that brush, which is a good 30 or so world units away. So I suspect there is a bug in a method of ExtrudedPolyList or in InteriorConvex::getPolyList, but I dont know enough about collision to have a chance of fixing it.
I think I might just filter out all polys with normals close to (0,0,-1) in InteriorConvex::getPolyList(AbstractPolyList* list), since I never need to collide with them in the game anyway. It's hackish, but I think it should work.
Unless anyone has any further thoughts or insights on this issue?
08/05/2005 (11:09 am)
Right as always Ben. :)I took your advice and rendered the polys that were involved in the bad collisions, and I found that some of them are YARDS away from where my Item is. There is no way it should be colliding with these polygons. Here is what a typical brush in my DIF looks like:
|.\
|...\
|.....\
|......|
|......|
|......|
|......|
|___|
This is a side view of the brush. ASCII isnt necessarily the best art tool, so you'll have to pretend that the slope of that top plane is much less steep. The plane on the top is a triangle, and the bottom plane is an unsloped version of that same triangle, and there are 3 square vertical sides to the brush. I hope that makes sense. A few hundred of these brushes make up the surface I want to collide with.
Now, the poly that the Item is colliding with is that BOTTOM plane, the one that would have a normal of (0,0,-1). And the ball is moving across the TOP of that brush, which is a good 30 or so world units away. So I suspect there is a bug in a method of ExtrudedPolyList or in InteriorConvex::getPolyList, but I dont know enough about collision to have a chance of fixing it.
I think I might just filter out all polys with normals close to (0,0,-1) in InteriorConvex::getPolyList(AbstractPolyList* list), since I never need to collide with them in the game anyway. It's hackish, but I think it should work.
Unless anyone has any further thoughts or insights on this issue?
#3
That's good you are making some progress. I've been working with Aaron on this (the guy that posted the original thread you linked to), and the only way we were able to get around this problem was to avoid it completely - we remade our DIF structure to only have one face where we wanted our Items to move along the surface. That way, there was nothing for it to collide with.
This is a pretty weak solution, and wouldn't work in most cases, but luckily it worked for what we needed it for. I also don't understand the collision that well (though I've read Matt Fairfax's excellent tutorial and must have traced through the collision code a dozen times), probably for the reason Ben says, it can be easier to visualize a problem. Since we've gotten burned before on spending too much time wrestling a technology problem over our head, we just decided to side-step it.
You used the map render mode to see where the different faces are in the DIF, that's how we caught on to the problem. If we figure out anything else I can post it here.
How did you get the collision faces to render so you could debug your problem? Would you be up to sharing how you did it or posting a code snippet?
Good luck with your problem!
- Drew
08/05/2005 (11:54 am)
Hi Josh,That's good you are making some progress. I've been working with Aaron on this (the guy that posted the original thread you linked to), and the only way we were able to get around this problem was to avoid it completely - we remade our DIF structure to only have one face where we wanted our Items to move along the surface. That way, there was nothing for it to collide with.
This is a pretty weak solution, and wouldn't work in most cases, but luckily it worked for what we needed it for. I also don't understand the collision that well (though I've read Matt Fairfax's excellent tutorial and must have traced through the collision code a dozen times), probably for the reason Ben says, it can be easier to visualize a problem. Since we've gotten burned before on spending too much time wrestling a technology problem over our head, we just decided to side-step it.
You used the map render mode to see where the different faces are in the DIF, that's how we caught on to the problem. If we figure out anything else I can post it here.
How did you get the collision faces to render so you could debug your problem? Would you be up to sharing how you did it or posting a code snippet?
Good luck with your problem!
- Drew
#4
I think I'll be able to get around it by just avoiding collision with those faces that have (0,0,-1) normals, but I didnt get a chance to test today.
08/05/2005 (7:31 pm)
Basically I knew that the collisions were being caused by planes with illegal normals (ie, normals that pointed directions that no visible surface was pointing), so I just made an if() statement that caught those cases, set a breakpoint there, and played a Torque journal that had recorded the bug. The debugger stepped in RIGHT before the bad collision was about to happen, so I just used the QuickWatch feature of .NET to extract all the information I wanted about the planes it hit and the normals.I think I'll be able to get around it by just avoiding collision with those faces that have (0,0,-1) normals, but I didnt get a chance to test today.
#5
08/06/2005 (9:01 pm)
Have you tried using the interest normal on the PoyList, or tried culling the faces more precisely in the item collision code? It might be considering everything that it gets back for collision, rather than what it's actually colliding with...
#6
Thanks for the suggestion!
08/06/2005 (10:27 pm)
Actually, I kind of just assumed it would be using the interest normal, but I had no reason to make that assumption. I'll check to make sure it isnt already using it, and if not, try it. The interest normal should just be the normalized Item velocity, right? Does it have to be in any particular object-space, or should it just be in worldspace? I'll try it every way and see if that works. Thanks for the suggestion!
#7
08/11/2005 (8:04 am)
Did you have any luck with this? I would like to know how to fix this.
#8
You got me thinking about this again and after hours of searching the net and pulling
apart player.cc I came across this site that has some interesting info on vertex-edge collision,,,
http://www.cg.tuwien.ac.at/studentwork/CESCG/CESCG-2000/PSovis/
anyway just then I came across this bit of code in collision/extrudedPolyList.cc
So I thought that could be the problem! , its getting an odd normal from the edge,
so I removed it like this:
What do you think?
08/11/2005 (10:11 pm)
My problem was with the terrain phantom collisions but I think its the same bug.You got me thinking about this again and after hours of searching the net and pulling
apart player.cc I came across this site that has some interesting info on vertex-edge collision,,,
http://www.cg.tuwien.ac.at/studentwork/CESCG/CESCG-2000/PSovis/
anyway just then I came across this bit of code in collision/extrudedPolyList.cc
if (edge == false)
collision.normal = mPoly.plane;
else
collision.normal = -face->plane;So I thought that could be the problem! , its getting an odd normal from the edge,
so I removed it like this:
//if (edge == false)
collision.normal = mPoly.plane;
//else
// collision.normal = -face->plane;and now it seems perfect, Ill go do more testing now but ive tried running around allot and hitting edges to see if it crashes but its good so far.What do you think?
#9
Thanks for sharing. Using the Torque Journal is pretty nice. It's something I've only played with once or twice, but it can be pretty handy for duplicating some weird behavior like this.
@Brian
That looks good! I'll be testing this at some point, so I can let you know what I find. I'll try to do it sooner rather then later. :)
08/11/2005 (10:19 pm)
Josh@Thanks for sharing. Using the Torque Journal is pretty nice. It's something I've only played with once or twice, but it can be pretty handy for duplicating some weird behavior like this.
@Brian
That looks good! I'll be testing this at some point, so I can let you know what I find. I'll try to do it sooner rather then later. :)
#11
That's the only line I left uncommented above. , Is that what you mean?
Its working great to, I can slide around very smoothly with no stops.
I want to test it by standing on top of a very pointy item , or a sheet of glass to see what happens
But I haven't had a chance to do that just yet.
08/15/2005 (11:22 pm)
Collision.normal = mPoly.plane;That's the only line I left uncommented above. , Is that what you mean?
Its working great to, I can slide around very smoothly with no stops.
I want to test it by standing on top of a very pointy item , or a sheet of glass to see what happens
But I haven't had a chance to do that just yet.
#12
Interesting.
08/16/2005 (12:14 am)
Ah... Yeah, duh. My bad. Shoulda read the code more closely. ;)Interesting.
#13
It behaves the same as normal so Im not real sure what the reason for that code is.
Maybe it is for small steps?
08/16/2005 (2:21 am)
I just tested walking along the top of a sharp wedge model.It behaves the same as normal so Im not real sure what the reason for that code is.
Maybe it is for small steps?
#14
This works great! It seems to work about 90% of the time. Occasionally, I still get a collision from a bad normal, but even when that happens it is not as pronounced as before.
Thanks a lot for catching this! I'll let you know if I found out anything else...
- Drew
08/16/2005 (9:40 am)
Hi Brian,This works great! It seems to work about 90% of the time. Occasionally, I still get a collision from a bad normal, but even when that happens it is not as pronounced as before.
Thanks a lot for catching this! I'll let you know if I found out anything else...
- Drew
#15
What happens if you drop on the wedge from a great height?
I'm poking at this issue a bit more - I think that the normal thing is fine, but I'm also trying to address the poppy normal problems.
08/16/2005 (11:42 am)
Brian,What happens if you drop on the wedge from a great height?
I'm poking at this issue a bit more - I think that the normal thing is fine, but I'm also trying to address the poppy normal problems.
#16
skip across the top of the wedge at certain landing points but im not sure if that's a new effect?
@Brad - Thanks, im happy I found it too:)
My game is a sort of hocky style so needs allot sliding.
Not sure if im traveling as fast as you but I did remove some other suff from player.cc that may be effecting it?
When i removed the early out section, the problem got allot worse , like one stop every 5m, but then after the above change it went away.
08/17/2005 (12:34 am)
I did drop on it from about 300m and it seems ok, I did get a bit of a funny skip across the top of the wedge at certain landing points but im not sure if that's a new effect?
@Brad - Thanks, im happy I found it too:)
My game is a sort of hocky style so needs allot sliding.
Not sure if im traveling as fast as you but I did remove some other suff from player.cc that may be effecting it?
When i removed the early out section, the problem got allot worse , like one stop every 5m, but then after the above change it went away.
#17
Oh, and another interesting thing to note... once when my item was sliding along the ground, one of the bad collisions occured, but ONLY on the client. The server predicted the motion correctly, and a second later, when the ball stopped, it warped to where the server had simulated that it should go. So I thought that was kind of weird too.
Thanks for trying though Brian!
08/27/2005 (10:24 am)
I know this is a little late, but I tested out Brian's solution, and it didnt solve my problem. It looked like that really could have been the cause, but I still get bad normals during collisions, and still dont know where they're coming from. I've been trying with the Item collision code though, not the player collision code, so maybe that has something to do with it.Oh, and another interesting thing to note... once when my item was sliding along the ground, one of the bad collisions occured, but ONLY on the client. The server predicted the motion correctly, and a second later, when the ball stopped, it warped to where the server had simulated that it should go. So I thought that was kind of weird too.
Thanks for trying though Brian!
#18
For the record, this collision fix does improve things, but it seems there are other issues.
Josh, are you getting these bad collision normals from all objects or only specific types?
08/27/2005 (12:32 pm)
Man, that's wild stuff.For the record, this collision fix does improve things, but it seems there are other issues.
Josh, are you getting these bad collision normals from all objects or only specific types?
#19
Most of my testing has been against Interiors. A while ago (3 months) though I did notice poor collisions against the edge of Terrain convexes with the default Item collision code. By bad collision I mean that it hit a plane with a normal that clearly didnt exist, but it didnt do any of the client/server disagreeing stuff like I mentioned in my post above.
Part of the reason why I notice more problems with Item is the way it selects which collision to use... Item always picks the MOST resistive plane to collide against, and Player picks the LEAST resistive plane. Also, Player uses the step() function to get over tiny bumps, whereas Item doesnt do that.
It would probably be worth me trying to use the Player collision code for my Item again with this new fix of Brian's, but I'm just too tired of messing with this code right now. Maybe if our alternative collision solution doesnt work out, I'll come back and try my hand at this issue again.
Thanks for all the help everyone, and good luck figuring it out. I'll be watching this thread in case anyone has any brilliant flashes of inspiration. :)
08/27/2005 (3:07 pm)
Yeah, it looked like a logical fix, it just didnt solve all my issues.Most of my testing has been against Interiors. A while ago (3 months) though I did notice poor collisions against the edge of Terrain convexes with the default Item collision code. By bad collision I mean that it hit a plane with a normal that clearly didnt exist, but it didnt do any of the client/server disagreeing stuff like I mentioned in my post above.
Part of the reason why I notice more problems with Item is the way it selects which collision to use... Item always picks the MOST resistive plane to collide against, and Player picks the LEAST resistive plane. Also, Player uses the step() function to get over tiny bumps, whereas Item doesnt do that.
It would probably be worth me trying to use the Player collision code for my Item again with this new fix of Brian's, but I'm just too tired of messing with this code right now. Maybe if our alternative collision solution doesnt work out, I'll come back and try my hand at this issue again.
Thanks for all the help everyone, and good luck figuring it out. I'll be watching this thread in case anyone has any brilliant flashes of inspiration. :)
#20
I'm having a problem where a moving item is colliding with a stationary item even though the direction of motion should be one item sliding by the other. I am using HEAD 1.4r2, which I believe has Brians fix in it, but am still seeing a problem. I was wondering if I wanted to use your code from the very first post on this, where I would add it, and if it really helps. Also did it cause other problems?
10/06/2005 (5:46 pm)
@Josh,I'm having a problem where a moving item is colliding with a stationary item even though the direction of motion should be one item sliding by the other. I am using HEAD 1.4r2, which I believe has Brians fix in it, but am still seeing a problem. I was wondering if I wanted to use your code from the very first post on this, where I would add it, and if it really helps. Also did it cause other problems?
Associate Ben Garney