Item Collision question
by Steve Lamperti · in Torque Game Engine · 06/30/2005 (1:52 pm) · 8 replies
I have created a type of object that is decended from Item, and am having a problem when I try to collide two or more of these items.
I'm working with C++, not with the scripting environment.
What happens is that when I collide two items horizontally, the collision works perfectly, but when I drop one item from above onto another item, the collision never happens, and the two items wind up occupying the same space on the ground.
I've traced this to the following, and must confess I am in over my depth in the collision code;
In updatePos, the collision gets past the early out code, and goes into the loop where it is checking the extruded polylist for the collision.
That loop never sets collisionList.t to be less then 1.0 in the vertical case, but does set it to be less then 1.0 in the horizontal case.
I've traced this further into the BoxConvex::getPolyList function, and from there into the ExtrudedPolyList::end function. In that code, the cFaceCount variable never gets set to greater then zero.
I was wondering if this has something to do with which faces are set to active, but I can't figure out how or where this is controlled.
If anyone has any information that might help me, I would appreciate hearing about it.
I'm working with C++, not with the scripting environment.
What happens is that when I collide two items horizontally, the collision works perfectly, but when I drop one item from above onto another item, the collision never happens, and the two items wind up occupying the same space on the ground.
I've traced this to the following, and must confess I am in over my depth in the collision code;
In updatePos, the collision gets past the early out code, and goes into the loop where it is checking the extruded polylist for the collision.
That loop never sets collisionList.t to be less then 1.0 in the vertical case, but does set it to be less then 1.0 in the horizontal case.
I've traced this further into the BoxConvex::getPolyList function, and from there into the ExtrudedPolyList::end function. In that code, the cFaceCount variable never gets set to greater then zero.
I was wondering if this has something to do with which faces are set to active, but I can't figure out how or where this is controlled.
If anyone has any information that might help me, I would appreciate hearing about it.
#2
06/30/2005 (10:40 pm)
Is your collision mesh closed and convex?
#3
07/01/2005 (9:00 am)
The object, in this case, is just a simple sphere that I created in MilkShape. I exported it using the shipping Milkshape DTS exporter, and specified the bounding box as the collision mesh. As I mentioned, collision is working fine horizontally, and also vertically when I make my change.
#4
07/01/2005 (10:31 am)
There is a little more going on here then I thought. The removal of that check, while it does seem to correct my issue with vertical collision, causes a problem with horizontal collision. Specifically, in the case where the collision is happening on some face other then the front face, the collision is still being reported, so if an item collides with my moving item from the side, or the top, and my item should not care, because the obstacle is not in front of it (in the direction it's moving,) it still stops, because it thinks it's being blocked. This makes sense, and clarifies for me what that check was doing, but now I need to figure out why in the vertical case that check was causing me trouble. (Perhaps it has something to do with the calculation of frontMask and backMask.)
#5
07/01/2005 (4:37 pm)
When I drop a player on top of another player, collision works fine. Which means that I was quite wrong about the reject above being the source of my problem. However, the fact that commenting it out made vertical collision work for the item objects is still a hint as to why this is not working. I still think that I am going to find some kind of issue that might be useful for other users, although I am now looking at the differences between the Player and Item collision code. I will post if I find anything that seems useful. 
#6
I have incountered problems that seem to involve the code you commented out in the testPoly function.
My original problem had to do with intermittent collision problems with bot objects,
that use the player class as a base.
I found that when I commented the code out, the bots would no longer move
and eventually the game entirely locked up.
I see you got virtually no response to your query.
Have you come to any conclusions regarding the cause?
Thanks,
Norm
04/09/2006 (11:50 am)
Hi Steve,I have incountered problems that seem to involve the code you commented out in the testPoly function.
My original problem had to do with intermittent collision problems with bot objects,
that use the player class as a base.
I found that when I commented the code out, the bots would no longer move
and eventually the game entirely locked up.
I see you got virtually no response to your query.
Have you come to any conclusions regarding the cause?
Thanks,
Norm
#7
I no longer have the problem I described above in my project, but this was almost a year ago, and I'm afraid I have no idea exactly what I did that fixed the problem. I think in general, that the fix was overridding much of the behavior of Item with other code that was largely snagged from other objects. (Player, and so forth.)
The trivial reject is not commented out in my project, and things are working well, so I think, as I stated above, that my initial thought that there was a problem with this code was wrong, or at least incomplete.
Sorry I can't be more help, but I don't really have any more information.
04/10/2006 (9:28 am)
@Norm,I no longer have the problem I described above in my project, but this was almost a year ago, and I'm afraid I have no idea exactly what I did that fixed the problem. I think in general, that the fix was overridding much of the behavior of Item with other code that was largely snagged from other objects. (Player, and so forth.)
The trivial reject is not commented out in my project, and things are working well, so I think, as I stated above, that my initial thought that there was a problem with this code was wrong, or at least incomplete.
Sorry I can't be more help, but I don't really have any more information.
#8
Thanks for the reply.
Oh well, back to figuring out what I am doing wrong or not doing.
I tried to merely change the dts file to replace the bots in a standard AI game with a steer(cow) dts and added modifications to make them walk and respond to proximity of the player and other bots. I added no new collision code. It works ok but only responds to collisions part of the time, for some reason. As a result, when I herd cattle into a corral, they sometimes walk right through the fence to get out. At other times, they they stop when they encounter the fence.
THe collision response of the the base class object (player) is solid, works every time.
Norm
04/10/2006 (9:46 am)
Steve,Thanks for the reply.
Oh well, back to figuring out what I am doing wrong or not doing.
I tried to merely change the dts file to replace the bots in a standard AI game with a steer(cow) dts and added modifications to make them walk and respond to proximity of the player and other bots. I added no new collision code. It works ok but only responds to collisions part of the time, for some reason. As a result, when I herd cattle into a corral, they sometimes walk right through the fence to get out. At other times, they they stop when they encounter the fence.
THe collision response of the the base class object (player) is solid, works every time.
Norm
Torque Owner Steve Lamperti
Imagine That!
Here's where I tracked the code down to:
As above, UpdatePos calls BoxConvex::getPolyList, which calls ExtrudePolyList::end
At that point, the code is checking each of the faces to find a face that is involved in the collision.
I had thought that the active flag might be the source of the problem, but it turned out to be the ExtrudedPolyList::testPoly call that was rejecting the face that should be colliding.
I looked into the testPoly function, and found that the 'trivial reject' on line 363 of ExtrudedPolyList.cc was the code that was rejecting the face that should be colliding.
I believe that there is something wrong in the logic of this trivial reject, as when I comment it out my items are colliding vertically just fine.
If someone who understands this code better then I could confirm this, I think that this could be useful to the community.
// Trivial reject if any plane not crossed has all it's points // on the front. U32 crossMask = frontMask & backMask; if (~crossMask & frontMask) return false;