Trouble at the seams (Beta 1.1 Bug)
by Robert DeMaria · in Torque Game Builder · 03/05/2006 (6:57 pm) · 13 replies
So, I'm trying to create a series of rolling hills by stringing together a series of convex polygons. This can be seen in the following image.
The problem is that at the seams where I connect the convex polygons, a lot of the time the player will fall or walk through the polygon. This can be seen in the following image.
This is especially bad when the player just sits on a seam. Also, changing the player's collision detection from circle to one of the other collision detection modes just causes the player to get tossed around or to fall right through the polygons.
The problem is that at the seams where I connect the convex polygons, a lot of the time the player will fall or walk through the polygon. This can be seen in the following image.
This is especially bad when the player just sits on a seam. Also, changing the player's collision detection from circle to one of the other collision detection modes just causes the player to get tossed around or to fall right through the polygons.
#2
- Melv.
03/05/2006 (9:41 pm)
Oh man, I'm sitting in my hotel-room in Eugene looking at this problem. :)- Melv.
#3
03/06/2006 (10:12 am)
Setting the collision detection to POLYGON appears to make the problem much worse. With the CIRCLE mode the player can walk over most seams (often with a kind of bump occurring). With the POLYGON mode, the player falls right through the first seam he touches.
#4
03/06/2006 (6:15 pm)
Hmm, that's interesting--has the opposite result for me. Melv did however find some things that help you tweak this better--I'll leave them to him to discuss as soon as he can since I don't have them at hand!
#5
03/07/2006 (9:03 am)
Great, thanks for taking a look at the problem so quickly. :)
#6
03/11/2006 (1:10 pm)
I've been talking with my team and due to the way that our levels are structured and the way the game plays, it's essential that we construct our levels this way. We also have a deadline that we have to meet. In order to be as productive as possible we need a rough estimate of how long this bug will take to fix. (If we have a rough idea of how long the bug will remain a problem, then we can schedule tasks appropriately). Additionally, if you suspect that the bug will not be fixed for more than two or three months, then my team and I will have to make very serious long term decisions about the project.
#7
For instance, if your object has a collision polly of (-1,-1)(-1,1)(1,1)
that would be a polly of
then, if the collision location is very close to the edge of a polly (the + symbol in my picture) then use the polly-side that is most tangent to the object being collided with.
for example, if the object being collided with is directly above point 1, then the polly-side B would be used for collision calculations.
I dont know collision math in game programming, so that's a suggestion that i didnt base on actual knowlege much, so take it with a grain of salt.
----------------
@Robert: for your game, you might want to programatically check if you are colliding at a certain point (such as point 1) and if so, then ignore collision events where the normal is a certain direction (for instance, in my example, for a collision occuring at point 1, you might want to ignore all collisions where the normal has a X>0, as that would mean that the collision occured on side A.
hope that helps.
-Jason
03/11/2006 (5:01 pm)
Perhaps as a workaround, you can programatically check.For instance, if your object has a collision polly of (-1,-1)(-1,1)(1,1)
that would be a polly of
1 + |\ A| \ B | \ +---+ 2 C 3
then, if the collision location is very close to the edge of a polly (the + symbol in my picture) then use the polly-side that is most tangent to the object being collided with.
for example, if the object being collided with is directly above point 1, then the polly-side B would be used for collision calculations.
I dont know collision math in game programming, so that's a suggestion that i didnt base on actual knowlege much, so take it with a grain of salt.
----------------
@Robert: for your game, you might want to programatically check if you are colliding at a certain point (such as point 1) and if so, then ignore collision events where the normal is a certain direction (for instance, in my example, for a collision occuring at point 1, you might want to ignore all collisions where the normal has a X>0, as that would mean that the collision occured on side A.
hope that helps.
-Jason
#8
03/11/2006 (5:04 pm)
And PS: if my work-around scenario has some fundimental flaws in logic, please let me know... I think i'm pretty good about thinking up solutions, but game dev isnt my forte and i'd like to get better :)
#9
03/13/2006 (3:50 pm)
Thanks for the suggestion Jason. I haven't had time to fully test it out, but I have done some smaller tests that are kind of along the same lines. By default, if the collision occurs at one of the corners, T2D uses a smoothed normal for the collision point at the corner. I tried turning that off and replacing it with the normal of one of the edges that the corner touches. (Currently I'm just sort of picking an edge arbitrarily). This appears to cause the problem to occur much less often while the player is running. Unfortunately, the player falls through seams while stationary just as often as he did before the test. This is pretty encouraging though. As soon as I get some time, I'll see what happens if I choose the edge based on what you proposed.
#10
03/13/2006 (9:52 pm)
To work around the problem couldn't you just place an addition collision surface that overlaps the two the player is currently crossing at the seam?
#11
03/13/2006 (11:16 pm)
Actually yeah, overlapping tiles might be the thing to do. simpler. Or like Robert said, put a stich inbetween.
#12
I tried these methods today and they do prevent the player from falling all the way through the surface, but occasionally the player will become temporarily stuck at the seam and then pop out. Also, sometimes the player will sink at the seam and then pop out. This seems like a good temporary solution. We'll be able to create and test levels without having to deal with the player falling through the floor every ten seconds. But, I doubt most people would be willing to put up with the problems I just mentioned when they're actually playing the game.
03/14/2006 (10:25 am)
Yes, but to do that I'd have to be smart enough to think of a simpler solution than messing with the source code. :)I tried these methods today and they do prevent the player from falling all the way through the surface, but occasionally the player will become temporarily stuck at the seam and then pop out. Also, sometimes the player will sink at the seam and then pop out. This seems like a good temporary solution. We'll be able to create and test levels without having to deal with the player falling through the floor every ten seconds. But, I doubt most people would be willing to put up with the problems I just mentioned when they're actually playing the game.
#13
@Robert DeMaria: Are you using another object as the stich? if so, maybe make sure that it is fairly wide, and at the collision polly is at the exact same level as the pollys you are stiching... it sounds kind of weird if you are still poping/sinking.
OH, and what is your "gravety" (constant force) set to? In general, I found that using numbers in the 10^0 to 10^1 order of magnitude is the best. huge numbers such as 800 leads to funky physics.
Also, I remember seeing funky behavior when using non-standard mass and stuff like that. I guess the main take-away is "keep it simple, dont break melv's baby" :)
03/14/2006 (12:10 pm)
If it makes you feel better, i (a man who prides himself on finding simple solutions) also totally missed the *DUH* answer Robert Blanchet outlined :)@Robert DeMaria: Are you using another object as the stich? if so, maybe make sure that it is fairly wide, and at the collision polly is at the exact same level as the pollys you are stiching... it sounds kind of weird if you are still poping/sinking.
OH, and what is your "gravety" (constant force) set to? In general, I found that using numbers in the 10^0 to 10^1 order of magnitude is the best. huge numbers such as 800 leads to funky physics.
Also, I remember seeing funky behavior when using non-standard mass and stuff like that. I guess the main take-away is "keep it simple, dont break melv's baby" :)
Torque 3D Owner Stephen Zepp