castCollision() information (TGB 1.7.5)
by Dmitry Yanushkevich · in Torque Game Builder · 04/01/2011 (6:41 am) · 1 replies
Well, it appears that there's a lot of controversy to what this function does and how it does it.
I think it'd be good to collect all the information in one place so you won't need to read tons of woes about the way this function performs. :-) Please note that this info relates to version 1.7.5 only; other versions can implement different steps in a different manner or return different data.
Let's start with the return values first. The format is as follows (taken from official docs):
"object time contactX contactY normalX normalY"
where (again, taken from official docs)
object is the object collided with,
time is the number of seconds in the future the collision took place as a float (this number will always be less than the %time parameter),
contact is the position the objects collided at as a vector, and
normal is the normal of the collision as a vector.
The logic is as follows:
1. Find all potential collisions using object's AABB extended using its current linear velocity. Note that angular velocity is NOT taken into account.
2. Walk the potential collisions list and do a collision geometry based check. The actual checks depend on which collision detection mode is set for both collision source and destination objects.
3. From all the collisions detected, find out which occurs first in time and return it to the caller.
What is worth noting:
* The very first thing is that your object has to have "send collisions" enabled for this to work.
* There are two important cases of collision here: the objects are disjoint at zero time or they are overlapping. In the former case the time returned will be positive, whereas in the latter case it will be negative.
* The value of "contact" is in fact the position of the source object when the collision occurred, NOT the contact point between the two bodies. Even though contact points are actually calculated in the C++ code, they are not exposed outside.
The biggest frustration is inability to find a contact point, which you'd rather expect to be possible -- it can aid in different geometric calculations when, say, you want to levitate an object above ground at desired altitude. The position returned is of little use since knowing time and linear velocity finding the position is one add, one mul away.
If it is at all possible, I'd like to have contact point returned. It is not that much to do in code (just choose other return value), but it will expand the use of castCollision() method a lot. Of course, you can mod your Torque to do this (see t2dsceneobject.cc:7639), but really, it is the kind of functionality you'd expect to work out-of-the-box.
Hope that helps.
I think it'd be good to collect all the information in one place so you won't need to read tons of woes about the way this function performs. :-) Please note that this info relates to version 1.7.5 only; other versions can implement different steps in a different manner or return different data.
Let's start with the return values first. The format is as follows (taken from official docs):
"object time contactX contactY normalX normalY"
where (again, taken from official docs)
object is the object collided with,
time is the number of seconds in the future the collision took place as a float (this number will always be less than the %time parameter),
contact is the position the objects collided at as a vector, and
normal is the normal of the collision as a vector.
The logic is as follows:
1. Find all potential collisions using object's AABB extended using its current linear velocity. Note that angular velocity is NOT taken into account.
2. Walk the potential collisions list and do a collision geometry based check. The actual checks depend on which collision detection mode is set for both collision source and destination objects.
3. From all the collisions detected, find out which occurs first in time and return it to the caller.
What is worth noting:
* The very first thing is that your object has to have "send collisions" enabled for this to work.
* There are two important cases of collision here: the objects are disjoint at zero time or they are overlapping. In the former case the time returned will be positive, whereas in the latter case it will be negative.
* The value of "contact" is in fact the position of the source object when the collision occurred, NOT the contact point between the two bodies. Even though contact points are actually calculated in the C++ code, they are not exposed outside.
The biggest frustration is inability to find a contact point, which you'd rather expect to be possible -- it can aid in different geometric calculations when, say, you want to levitate an object above ground at desired altitude. The position returned is of little use since knowing time and linear velocity finding the position is one add, one mul away.
If it is at all possible, I'd like to have contact point returned. It is not that much to do in code (just choose other return value), but it will expand the use of castCollision() method a lot. Of course, you can mod your Torque to do this (see t2dsceneobject.cc:7639), but really, it is the kind of functionality you'd expect to work out-of-the-box.
Hope that helps.
About the author
Worked here and there, did both game and business development. Finally decided to start own business, and here we are -- a cutie Cat Paw Studio has been born! :D
Torque Owner Dmitry Yanushkevich
Okay, what I have done (oh my...) is the following:
* Changed the source code to return both source and destination contact points
* Created a "probe" object consisting of a line collision. The docs permit this and even single point collisions, which actually can be useful. UPD: What might be not obvious is that the probe is longer than the character's collision and actually overlaps the floor tiling.
* Modified the test scene from one of my projects to display the contacts with balls.
The results are as follows (small red ball is source contact, blue ball is destination contact):
I ran the character a bit along the ground here. We can actually see three different results being returned. I have no in-depth engine knowledge to interpret these results in any meaningful way though, except that I cannot say that it is what you'd expect to see.