TGB pro: Simultanious Collisions Not Detected / tunneling?

#1 First off, you should put the version of TGB you are using (e.g. RC3 or RC3 mac) in the post title so if this is a bug, we'll know it's a new one and not potentially already fixed as well as stop others posting the same report :).

Secondly, it's gonna be hard (or at least more tricky) by that description to tell if it's a bug or your code without a sample of your code ;)

An obvious question but, are these item/powerup collision points setup correctly? Sorry i can't be of more help :)

#2 This looks similar to a problem I had where a non-physics simulation object (like a t2dTrigger) would still act in the physics simulation. Garage Games fixed this in RC2. If you are using RC2 or RC3, then you might still have a problem.

#3 It sounds like "tunneling" to me.
Download the latest version (RC3). This bug was present in all earlier version. I think it's finally fixed.

#4 Unfortunately I do have RC3, and I was getting this problem with RC2 before.
I thought I'd try a verbal description first because it could be hard to trim down my code to something easy to post, ill get on that tho.

The collision area for the obstructions are polygon, no custom polygon. For the player there is a custom polygon, which is a box containing about the lower half of the sprite (his feet). These both seem to work perfectly most of the time.

But say I disable the oncollision for one of the item/powerups, which would normally disapear as soon as it collides with the player. So the player can stand on top of the powerup. If the powerup is next to a wall/object that is suppose to be solid, the player will be able to step off the item and into the wall and get stuck about halfway before any collision is detected.

I'll try disabling oncollision callbacks for the items versus having an empty oncollision function for the items versus disabling collisions totally and see if I get any different results.

#5 I did some testing. And here is the problem, described much better than before.

If an object is colliding/ontopof two objects at the same time--picture one of those diagrams with three partially overlapping cirles--then the middle object does not register a collision with both of them at the same time.

It seems like T2D cant register two collisions on the same object at the same time ?

Imagine the middle circle begins overlapping/ontop of the left circle and then moves towards the middle/right circle. (All three objects are set to collide) While the object is ontop of the left circle it continuously registers collisions, then as it begins to overlap the 2nd/right circle "it continues to only register collisions with the first/left circle"! Untill the circle reaches around the mid-point between the two circles, then it switches to registering only collisions with the right circle and ignores the left!

If you want to test this yourself just create a new level put down three (G) logo static sprites with the middle one partially overlapping one to the left and one to the right, set the middle circle to send collisions and the other two to receive, turn on collision callback for all three, type middle/left/right in for the respective "class" fields, open up main.cs and add

function t2dsceneobject::oncollision(%thisobj,%otherobj,%srcRef, %dstRef, %time, %normal,%contacts, %points)
{
   warn("%this:"SPC %thisobj.class SPC "%other:"SPC %otherobj.class);
}

then save and reopen your level. Try positioning the center circle more to the left or more to the right or all the way to the left/right and notice what is really colliding in the console.

#6 Someone else please try this and tell me if they see something unusual as well.

#7 I duplicated these results with TGB pro. The sprites used in the example obviously have their center within the collision box and i tested it with setcollisionmaxiterations(3) and it made no difference

#8 Eric Talavitie:
What collision mode are you using? I have had somewhat similar problems, but
only when using \\\"Circle\\\" collision. So far I have had no collision
detection problems with \\\"Polygon,\\\" though maybe I just haven\\\'t tried
hard enough yet. :-)



Erik, to reply to your post, which seems to have been deleted....

Try following the instructions I give and see if it does it for you. I never change the detection mode so it should be on polygon.

As for in my game, it is also in polygon detection mode.

#9 Yah, I deleted my post because I noticed that you had specified that above and I had just missed it. I will try to reproduce your bug and tell you what I find.

#10 Yes, i'm pretty sure out-of-the-box TGB wont register more than one collision per object per frame. CollisionsMaxIterations doesn't affect this, though it can make your phsics responses much smoother.

#11 If this isnt a bug but just a limitation then it should be documented. I've wasted a lot of time.

#12 Does this apply to the torque 3d engine as well?

#13 Thanks for the report James. To answer your question, yes, TGB does pair-wise collision detection. In fact, most collision detection and physics systems operate this same way, not just TGB's.

To note, actually, having tick-based physics wouldn't affect this behavior at all.

Also to note, we are working on more docs for the physics system. To help give some context here... the physics system was originally designed to help people get cool, simple physics reactions up and running on their own, without having to go into C++ and code even simple kinds of reactions. It was never meant to be a general purpose, throw-anything-at-it-and-it'll-behave-just-like-real-life physics system. :) Indeed, any real-time physics simulation is only a gross, rough approximation of anything near reality.

We released this physics system back when TGB first launched (as "Torque 2D"), when it was an engine only. The problem we're seeing now is that since we've essentially made TGB way easier to use with the addition of editors and lots of docs overall, we've exposed it to a much wider audience (not just folks who are interested in working with a game engine, but rather making games with a game making tool). Accordingly, people are having a hard time grasping the physics. And for good reason, I think. Straight up: having the physics stuff exposed in the editor means the physics stuff should be totally easy to understand, and extremely stable and robust.

Unfortunately, that's very, very hard to do. And to be honest, I'm not sure if any physics system is ever going to be suitable for use in an editor like TGB. We're going to give it a shot though, by working both on writing docs to help people understand how to use the physics system appropriately, and on how we expose the physics system through the Level Builder.

To address this particular issue though... its perfectly valid to bring up. People run into this sort of stacking problem frequently. What I mean by "stacking problem" is a a situation where you try to detect collisions and potentially do physics responses on stacks of objects. To be clear, TGB does not handle stacking situations well; its physics system is not designed to stably handle stacks of objects (it takes special case code, such as "shock propagation" to do stacks very well, and even the most advanced physics SDKs such as Novodex / PhysX have to apply special code for detecting multi-way collisions and handling stacks).

#14 Thanks for the response, I was unaware stacked objects were such a problem, but I can probably avoid having them.

#15 I'm just reread this old thread of mine and I'm just curious...

Have there been any changes to how the physics system handles stacked objects with the more recent versions of TGB?