Objects Passing Through Collision Boxes
by InvadErGII · in Torque Game Builder · 11/02/2006 (9:18 am) · 9 replies
I'm working on a pinball game in TGB, and I'm beginning to encounter some inexplicable collision issues. My ball launcher on the right side of the screen has its collision set up as normal, but from time to time the ball will fall straight through it and make the game pretty much unplayable.
Similarly, the thin ramps on either side of the flippers also have a tendency to do the same thing - as the ball is rolling down to the ramp, it instead falls straight through to the bottom of the pinball table, costing the player a ball in the process.
Here are some pics of the above examples. I'm not sure what other info to include at this point, but I can answer any additional questions if necessary. I'm hoping to get this figured out and taken care of pretty quickly.
http://img.photobucket.com/albums/v375/pacmanhat/pinballThing1.jpg
http://img.photobucket.com/albums/v375/pacmanhat/pinballThing2.jpg
Similarly, the thin ramps on either side of the flippers also have a tendency to do the same thing - as the ball is rolling down to the ramp, it instead falls straight through to the bottom of the pinball table, costing the player a ball in the process.
Here are some pics of the above examples. I'm not sure what other info to include at this point, but I can answer any additional questions if necessary. I'm hoping to get this figured out and taken care of pretty quickly.
http://img.photobucket.com/albums/v375/pacmanhat/pinballThing1.jpg
http://img.photobucket.com/albums/v375/pacmanhat/pinballThing2.jpg
About the author
#2
I'm not certain, but I have a feeling the collision poly is stored in a 0..1 coord space and with a thin collision poly we're seeing rounding errors creeping in. Could be totally wrong though because I've not looked at the source to track this down yet.
My temporary solution is to use two objects. The first is wide and tall, for the sprite images and is mounted to the second sceneobject. This second is wide but thin such that it closely matches the volume the collision poly will use. With this setup, the object with the CLAMP setting no longer has any issues with objects passing through.
Although it sounds like this is more a problem Invader is having than in your case Rob. Unless your ball collision poly takes up a tiny percentage of the overall sceneobjects space? (and likewise with the surface)
02/07/2007 (10:14 am)
I've encountered something along those lines. I had a reasonably sized sceneobject, with a collision poly that was as wide as the object, but nowhere near as tall. The object was set to CLAMP but occasionally it'd allow objects to pass straight through rather than clamping them.I'm not certain, but I have a feeling the collision poly is stored in a 0..1 coord space and with a thin collision poly we're seeing rounding errors creeping in. Could be totally wrong though because I've not looked at the source to track this down yet.
My temporary solution is to use two objects. The first is wide and tall, for the sprite images and is mounted to the second sceneobject. This second is wide but thin such that it closely matches the volume the collision poly will use. With this setup, the object with the CLAMP setting no longer has any issues with objects passing through.
Although it sounds like this is more a problem Invader is having than in your case Rob. Unless your ball collision poly takes up a tiny percentage of the overall sceneobjects space? (and likewise with the surface)
#3
02/07/2007 (10:25 am)
Thanks for the reply Gary. Actually, I believe I am having the same problem as Invad. I'm doing a pinball simulation as well although right now I'm just starting the ball at the top of the table and letting it drop. There are lots of places on the table where I'm going to need relatively thin pieces (namely the 'lane dividers' next to the bumpers & flippers). I follow what your solution was but I don't think it'll work in this case, mostly because I need all of the objects to provide a bounce reaction rather than clamp. The ball only gets 'pulled' through bounding volumes when it's moving slow (i.e. 'rolling' down a ramp).
#4
02/07/2007 (10:53 am)
I never found a complete solution to the problem, but I was able to make it happen less often by adjusting the collision boxes in various ways (it's been a while since I touched this project, so I can't say I remember the specifics). For when the collision failed, I put in a failsafe to reset the ball's position if it ever got higher or lower than it was supposed to. This wasn't exactly ideal or pretty, but it got the job done.
#5
Totally off topic, but this guy will go far (no sarcasm at all, I'm very serious). "Get 'er done!" is a mode of development every game developer that will come to every game dev in their career...and showing as a student you can handle it is amazing!
02/07/2007 (10:44 pm)
Quote:
This wasn't exactly ideal or pretty, but it got the job done.
Totally off topic, but this guy will go far (no sarcasm at all, I'm very serious). "Get 'er done!" is a mode of development every game developer that will come to every game dev in their career...and showing as a student you can handle it is amazing!
#6
Anyway, it's become apparent, from dozens of threads like this, that it's important to enough people that we've decided to revamp the collision and physics system. The first step was to move the engine over to a fixed-tick system, which means the physics will now be deterministic across different machines and, more importantly, independent of framerate. That part is done and we're testing and polishing it to make sure it's stable.
Another upgrade that would make it even more reliable would be to change the collision system to resolve all overlaps each tick, rather than just the first one. That change would require some time because it basically calls for a substantial refactoring of the collision system. The benefit of such a system is enormous though, in my head, because it allows all sorts of fun stuff to work (like pushing something into a corner without causing penetration or jitter). It's still to be decided whether or not that change will happen, but know that I'm pushing for it.
Sorry again for your frustrations. I hope it hasn't cost you too much of your development time. Good luck on this and future projects.
-Thomas
02/08/2007 (12:00 pm)
I'm sorry for your frustration with collision stuff. The truth is that TGB was not designed to handle complex collisions. I guess when it was initially being developed, it wasn't obvious that enough people would want to abuse physics like this, so it wasn't a priority. That kinda boggles my mind, cause the first thing I did when I was introduced to it was abuse the physics. Who wouldn't?Anyway, it's become apparent, from dozens of threads like this, that it's important to enough people that we've decided to revamp the collision and physics system. The first step was to move the engine over to a fixed-tick system, which means the physics will now be deterministic across different machines and, more importantly, independent of framerate. That part is done and we're testing and polishing it to make sure it's stable.
Another upgrade that would make it even more reliable would be to change the collision system to resolve all overlaps each tick, rather than just the first one. That change would require some time because it basically calls for a substantial refactoring of the collision system. The benefit of such a system is enormous though, in my head, because it allows all sorts of fun stuff to work (like pushing something into a corner without causing penetration or jitter). It's still to be decided whether or not that change will happen, but know that I'm pushing for it.
Sorry again for your frustrations. I hope it hasn't cost you too much of your development time. Good luck on this and future projects.
-Thomas
#7
What did you mean by "just the first one", Were you saying that it only resolves 1 overlapping object per tick (the first one it comes to) or did you mean "just the first tick" which doesn't really make sense in to me anyway.
I have been working on a game where I "teleport" alot of objects around and they're a bunch of objects in close proximity to each other. The problem that I have is when I teleport there is a chance that it will be placed on top of another object. What happens in that case most of the time is the engine gives the object an enormous velocity and shoots my object off of the screen. Is this the normal response from the engine when objects are overlapping?
I have been working on scripting fixes to try and check the location before I teleport(using pickpoint and pickline). When I do detect an object in the way I would like to teleport it out of the way as well but then I need to check it's new position and so on and so on.....
With the Physics Changes that are Coming Soon (Please) will the engine respond differently to overlapping objects than it does now in 1.1.3 ?
Just trying to come up with alternate solutions or change my gameplay up if necessary..
Thanks GG for all the excellent work that has been put into TGB so far...It's amazing what it will do!
02/08/2007 (7:34 pm)
@ThomasQuote:
Another upgrade that would make it even more reliable would be to change the collision system to resolve all overlaps each tick, rather than just the first one.
What did you mean by "just the first one", Were you saying that it only resolves 1 overlapping object per tick (the first one it comes to) or did you mean "just the first tick" which doesn't really make sense in to me anyway.
I have been working on a game where I "teleport" alot of objects around and they're a bunch of objects in close proximity to each other. The problem that I have is when I teleport there is a chance that it will be placed on top of another object. What happens in that case most of the time is the engine gives the object an enormous velocity and shoots my object off of the screen. Is this the normal response from the engine when objects are overlapping?
I have been working on scripting fixes to try and check the location before I teleport(using pickpoint and pickline). When I do detect an object in the way I would like to teleport it out of the way as well but then I need to check it's new position and so on and so on.....
With the Physics Changes that are Coming Soon (Please) will the engine respond differently to overlapping objects than it does now in 1.1.3 ?
Just trying to come up with alternate solutions or change my gameplay up if necessary..
Thanks GG for all the excellent work that has been put into TGB so far...It's amazing what it will do!
#8
I come back from a few months away from TGB and the first post I see is about improving the physics!
When I started into TGB I was learning by building simple simulations of balls bouncing around, eventually trying to work in some autonomous (boid like) movements.. Line of Sight, avoidance etc...
I got pretty far along, but when I stopped due to RL concerns, moving, busy season, new dog etc... I was still having issues with collision penetrations along tile seams, and anytime the game window moved (or alt-tab from fullscreen) the collisions would get all wonky.
Keep up the good work!
So long, and thanks for all the fish!
02/08/2007 (8:41 pm)
Holy Cow!!I come back from a few months away from TGB and the first post I see is about improving the physics!
When I started into TGB I was learning by building simple simulations of balls bouncing around, eventually trying to work in some autonomous (boid like) movements.. Line of Sight, avoidance etc...
I got pretty far along, but when I stopped due to RL concerns, moving, busy season, new dog etc... I was still having issues with collision penetrations along tile seams, and anytime the game window moved (or alt-tab from fullscreen) the collisions would get all wonky.
Keep up the good work!
So long, and thanks for all the fish!
#9
As for your specific issue, what type of collision response are you using? If you're using RIGID, then that's pretty much what's supposed to happen (severely overlapping objects are forced apart). You might consider tweaking the mass or restitution of your objects to change the severity of the response, if you are in fact using RIGID response mode.
By the way, teleporting objects that are in the way of a teleport without any sort of discretion could potentially cause huge performance hangups (read: infinite loop), so I would be careful with that approach.
@Scott - Yes, the ticked physics changes should completely kill all the physics-related problems caused by dragging/resizing the window and losing/regaining focus. The penetration you're talking about should be much less prevalent aswell. Should the second change I mentioned be implemented, they should go away entirely in most every case. There would still be a chance of forced penetration from sandwiching/stacking immovable objects, but there's no good and logical universal solution for scenarios like that - it would be more of a game-specific level design or game mechanic issue.
There are also lots of UI and tool improvements in the works for the TGB editor, so keep an eye out for those. ;)
02/08/2007 (9:27 pm)
@Dustin - I meant just the first overlap. Right now, each collision sender only gets the first overlap resolved every physics update. This causes ridiculous things to happen in corners. With ridid body collision, it can even cause forces to build up and launch objects. Needless to say, there's room for improvement there.As for your specific issue, what type of collision response are you using? If you're using RIGID, then that's pretty much what's supposed to happen (severely overlapping objects are forced apart). You might consider tweaking the mass or restitution of your objects to change the severity of the response, if you are in fact using RIGID response mode.
By the way, teleporting objects that are in the way of a teleport without any sort of discretion could potentially cause huge performance hangups (read: infinite loop), so I would be careful with that approach.
@Scott - Yes, the ticked physics changes should completely kill all the physics-related problems caused by dragging/resizing the window and losing/regaining focus. The penetration you're talking about should be much less prevalent aswell. Should the second change I mentioned be implemented, they should go away entirely in most every case. There would still be a chance of forced penetration from sandwiching/stacking immovable objects, but there's no good and logical universal solution for scenarios like that - it would be more of a game-specific level design or game mechanic issue.
There are also lots of UI and tool improvements in the works for the TGB editor, so keep an eye out for those. ;)
Torque Owner Rob Zimmerman
I have a constant force applied to the ball (1.0) and for testing purposes, had its initial position on a flat surface. Regardless of how "thick" I make the collision volume for the surface the ball rests on, it will always jitter, then fall through.