Interior Collision Problems (and Hopefully Solutions)
by Shook · in Torque Game Engine · 12/10/2004 (1:40 pm) · 7 replies
I ran into two subtle -- but in the long run unacceptable -- problems with a detailed level I'm building for practice. I'm working entirely with a dif. I'm using both Hammer and QuArK.
1) Often when I run into a small step from an angle, I slide along the step and sometimes even stop before finally going up and over it. The step can be -- relative to the default player -- a very small step (8 units high). Note this is not at the beginning of a set of stairs. I'm talking individual steps or recessions in the floor. For whatever reason, the player handles a full set of stairs better. Go figure.
2) If I jump from one ledge and land on the very edge of another ledge (or even just shy of the ledge), the player gets stuck. The only way to free him is to go into noclip/camera mode.
First I considered that I needed to rebuild the areas in question. I did that, even greatly simplifying things to minimize the possibility of some invisible error, but I still experienced both problems after rebuilding.
Then I thought maybe this was happening because I had adjusted several variables to obtain a more crisp, responsive play control feel. So I created a fresh, clean install of Torque 1.3 and copied my diff (simplified, rebuilt version) and textures to the fps.starter's interior directory. I loaded torquedemo, brought in my dif, re-lit and ran around. And I still had both problems. :\
Admittedly, my variable changes must've amplified the problems, as they seem to be less severe when I run around with Torque's default settings. But they're still there.
The bizarre thing is that I can run over a step 20 times from the same direction without a problem. Then the next three tries produce this wonkiness. I can jump from one ledge to the other fine for several days, then one day I hit the landing along the edge at just the wrong angle and I get stuck. Like I said, the problem is relatively subtle, but it would be unacceptable for a finished product.
Is this an inherent limitation of Torque's interior collision detection, or are there some variables I can adjust to prevent these errors from happening?
Right now it just doesn't feel like the collision-detection is robust and refined enough to handle fast-paced, interior-based action. I hope I'm wrong and someone can enlighten me so I can better address the problem.
Oh, one other related issue: by default, when the torque player runs up a ramp, at the top of the ramp he floats through the air a bit -- as if the player were riding a skateboard up off the slant rather than running over it. I managed to virtually elimnate this by slightly decreasing the player speed and greatly increasing his gravity, but is there a better way to do this? It just seems that the gravity might be the variable exacerbating the collision limitations.
Thank you for reading and I'll greatly appreciate any of your input. :)
1) Often when I run into a small step from an angle, I slide along the step and sometimes even stop before finally going up and over it. The step can be -- relative to the default player -- a very small step (8 units high). Note this is not at the beginning of a set of stairs. I'm talking individual steps or recessions in the floor. For whatever reason, the player handles a full set of stairs better. Go figure.
2) If I jump from one ledge and land on the very edge of another ledge (or even just shy of the ledge), the player gets stuck. The only way to free him is to go into noclip/camera mode.
First I considered that I needed to rebuild the areas in question. I did that, even greatly simplifying things to minimize the possibility of some invisible error, but I still experienced both problems after rebuilding.
Then I thought maybe this was happening because I had adjusted several variables to obtain a more crisp, responsive play control feel. So I created a fresh, clean install of Torque 1.3 and copied my diff (simplified, rebuilt version) and textures to the fps.starter's interior directory. I loaded torquedemo, brought in my dif, re-lit and ran around. And I still had both problems. :\
Admittedly, my variable changes must've amplified the problems, as they seem to be less severe when I run around with Torque's default settings. But they're still there.
The bizarre thing is that I can run over a step 20 times from the same direction without a problem. Then the next three tries produce this wonkiness. I can jump from one ledge to the other fine for several days, then one day I hit the landing along the edge at just the wrong angle and I get stuck. Like I said, the problem is relatively subtle, but it would be unacceptable for a finished product.
Is this an inherent limitation of Torque's interior collision detection, or are there some variables I can adjust to prevent these errors from happening?
Right now it just doesn't feel like the collision-detection is robust and refined enough to handle fast-paced, interior-based action. I hope I'm wrong and someone can enlighten me so I can better address the problem.
Oh, one other related issue: by default, when the torque player runs up a ramp, at the top of the ramp he floats through the air a bit -- as if the player were riding a skateboard up off the slant rather than running over it. I managed to virtually elimnate this by slightly decreasing the player speed and greatly increasing his gravity, but is there a better way to do this? It just seems that the gravity might be the variable exacerbating the collision limitations.
Thank you for reading and I'll greatly appreciate any of your input. :)
#2
The DTS collision box can catch on things you don't expect, the beams on all my tudor stuff have needed tweaking in certain places so that the player doesn't catch on them. Check the height of the area is enough for the dts's bounding box.
12/10/2004 (3:29 pm)
I'm with methew on this, its probably your bounding box catching on the interiors collision. You'll find with steps and ladders that if you look up the ladder with the mouse you be able to get up easier, you'll also find that running helps a lot.The DTS collision box can catch on things you don't expect, the beams on all my tudor stuff have needed tweaking in certain places so that the player doesn't catch on them. Check the height of the area is enough for the dts's bounding box.
#3
Try change the maxStepHeight value in player.cs.
It worked for me .
12/11/2004 (3:05 am)
If you get stuck on thoose smaller steps.Try change the maxStepHeight value in player.cs.
It worked for me .
#4
That gives me three distinct things to try that I hadn't thought about or didn't even know about.
I just quickly changed the boundingbox. While it didn't improve the stepping problem, it may have improved the snag from jumping from ledge to ledge. (Hard to tell, of course, since it happens rarely. I'll have to test it pretty methodically.)
Maybe this is a stupid question, but does the player model and animation affect collision at all? I had assumed that the player shape and his animations all occurred within the boundingbox and thus didn't affect collision, but perhaps this is something else I should consider. Right now I was just using a place-holder model without animation (so I have a simple statue-like figure sliding and bouncing around... heh).
I didn't have a maxStepHeight variable in my player.cs, but I found it in player.cc, so I'll try adding that to player.cs and experimenting with that variable as well.
I didn't know about using the null texture on non-rendering surfaces. So I've got a lot o' surfaces to change to the null texture. At this point, I have hope that this might be the solution. :)
But approaching these problems with your suggestions (boundingbox, maxStepHeight, null texture on non-rendering surfaces) should better equip me to resolve them.
Thanks fellas. :) I'll post back once I get the problem under satisfactory control and let you know what I think resolved it.
12/11/2004 (9:52 am)
Wow -- great responses! I really appreciate it. :)That gives me three distinct things to try that I hadn't thought about or didn't even know about.
I just quickly changed the boundingbox. While it didn't improve the stepping problem, it may have improved the snag from jumping from ledge to ledge. (Hard to tell, of course, since it happens rarely. I'll have to test it pretty methodically.)
Maybe this is a stupid question, but does the player model and animation affect collision at all? I had assumed that the player shape and his animations all occurred within the boundingbox and thus didn't affect collision, but perhaps this is something else I should consider. Right now I was just using a place-holder model without animation (so I have a simple statue-like figure sliding and bouncing around... heh).
I didn't have a maxStepHeight variable in my player.cs, but I found it in player.cc, so I'll try adding that to player.cs and experimenting with that variable as well.
I didn't know about using the null texture on non-rendering surfaces. So I've got a lot o' surfaces to change to the null texture. At this point, I have hope that this might be the solution. :)
But approaching these problems with your suggestions (boundingbox, maxStepHeight, null texture on non-rendering surfaces) should better equip me to resolve them.
Thanks fellas. :) I'll post back once I get the problem under satisfactory control and let you know what I think resolved it.
#5
Matt
12/11/2004 (10:37 am)
I think collision is calculated inside the bounding box to the shape of the player. One thing I know is if you don't have a jump animation in which the player jumps inside the bounds you can't jump as high in game. The higher the animation the higher the jump. But you gotta balance it with the size of the bounding box.Matt
#6
I've used the null texture on every non-visible surface (I think), I've brought the boundingbox way down and when that actually seemed to make things worse I tried experimenting with over-sizing it. I've experimented with the maxStepHeight variable, and I've tried using different models and animations (including both the ORC and the f-man from the tutorial.base).
Everything I tried produces the same results in varying degrees. While none of the changes affect the stepping problem much, the getting stuck thing varies. The best I could do to eliminate the snagging was to use the ORC and all the default fps.starter player settings (including gravity and boundingbox). But I really don't like those player settings (they feel too soft, floaty and sluggish). :\
The settings I've played with to adjust the player control "feel" have been the following:
mGravity (in player.cc -- the rest are in player.cs)
runForce
maxForwardSpeed
maxBackwardSpeed
maxSideSpeed
minImpactSpeed
runSurfaceAngle
jumpSurfaceAngle
minJumpSpeed
maxJumpSpeed
horizMaxSpeed
horizResistSpeed
horizResistFactor
upMaxSpeed
upResistSpeed
upResistFactor
Anyone have any ideas which (if any) of these variables might increase the possibility of getting stuck?
In the mean time, I'm off to rework my geometry. If I remain stuck I'll post some example images and difs.
Man, making your own game rather than modding an existing game has turned to out to be more of an obstinate animal than I'd expected. Perhaps it's just my lack of experience and knowledge with Quark and Hammer.
12/12/2004 (10:46 am)
I'm feeling at a bit of a loss here. Since I don't see many others complaining about this sort of thing, I'm beginning to wonder if there's simply something wrong with my bsp design (I'm having both problems in two completely different maps).I've used the null texture on every non-visible surface (I think), I've brought the boundingbox way down and when that actually seemed to make things worse I tried experimenting with over-sizing it. I've experimented with the maxStepHeight variable, and I've tried using different models and animations (including both the ORC and the f-man from the tutorial.base).
Everything I tried produces the same results in varying degrees. While none of the changes affect the stepping problem much, the getting stuck thing varies. The best I could do to eliminate the snagging was to use the ORC and all the default fps.starter player settings (including gravity and boundingbox). But I really don't like those player settings (they feel too soft, floaty and sluggish). :\
The settings I've played with to adjust the player control "feel" have been the following:
mGravity (in player.cc -- the rest are in player.cs)
runForce
maxForwardSpeed
maxBackwardSpeed
maxSideSpeed
minImpactSpeed
runSurfaceAngle
jumpSurfaceAngle
minJumpSpeed
maxJumpSpeed
horizMaxSpeed
horizResistSpeed
horizResistFactor
upMaxSpeed
upResistSpeed
upResistFactor
Anyone have any ideas which (if any) of these variables might increase the possibility of getting stuck?
In the mean time, I'm off to rework my geometry. If I remain stuck I'll post some example images and difs.
Man, making your own game rather than modding an existing game has turned to out to be more of an obstinate animal than I'd expected. Perhaps it's just my lack of experience and knowledge with Quark and Hammer.
Torque Owner Matthew Jones
Second I'm not sure what player your using but when I build a model I try to reduce the sized of the bounding box to as little as possible. My experience has lead me to believe the the engine calculates the 4 corners of the bounds and to figure about where the player should be above the surface. Not sure what the code does. But the smaller the bounding box the better terrain following is and of course interiors fall into that even more.
The ORC, I have noticed, must have a big bounding box because he floats alot.
There are no provisions for steps. Some engines have area markers like "Ladders" , "Steps" ,"{Low traction" ect.. that help the system define the movement of the character. Basically Torque just wings it.
Unfortunatly thats all I got for ya. I can't explain anything from the code.
Matt