Player only updates its collision box on the Z-axis?
by Stefan Lundmark · in Torque Game Engine · 09/17/2006 (7:07 am) · 13 replies
Basically, the bounding box rotation is not updated other than in the z-axis. This makes sense because a player never tilts, but does anyone have a clue where this optimization is enforced? I want to remove it.
A quick check trough updateWorkingCollisionSet () didnt give me any ideas. updatePos () sounds like a place where it might happen, but I couldnt find it for the life of me.
I appreciate any advice that you can give and thanks for your time.
A quick check trough updateWorkingCollisionSet () didnt give me any ideas. updatePos () sounds like a place where it might happen, but I couldnt find it for the life of me.
I appreciate any advice that you can give and thanks for your time.
About the author
#2
I said the bounding box of the player does not update, not the player model itself.
I *have* full rotation on the player (setTransform, setPosition, updateMove and their render equivilents) and the player rotates in all axis.
But the bounding box still does not rotate in any other axis than Z. If you look down (and rotate around the X axis) the box dips into the ground without colliding. When turning around (and rotate around the Z axis) it doescollide with objects that get into the path of the box.
Edit: Thanks for your hint about the vehicle class but its not what I need :)
09/17/2006 (1:13 pm)
Thanks Ben but I'm not sure you understood. (no offence btw!)I said the bounding box of the player does not update, not the player model itself.
I *have* full rotation on the player (setTransform, setPosition, updateMove and their render equivilents) and the player rotates in all axis.
But the bounding box still does not rotate in any other axis than Z. If you look down (and rotate around the X axis) the box dips into the ground without colliding. When turning around (and rotate around the Z axis) it doescollide with objects that get into the path of the box.
Edit: Thanks for your hint about the vehicle class but its not what I need :)
#3
void Player::buildConvex(const Box3F& box, Convex* convex)
bool Player::buildPolyList(AbstractPolyList* polyList, const Box3F&, const SphereF&)
bool Player::castRay(const Point3F &start, const Point3F &end, RayInfo* info)
?
There are comments all over those indicating the collisions are axis aligned in world space - you'll probably have to update.
09/17/2006 (1:23 pm)
Did you look at void Player::buildConvex(const Box3F& box, Convex* convex)
bool Player::buildPolyList(AbstractPolyList* polyList, const Box3F&, const SphereF&)
bool Player::castRay(const Point3F &start, const Point3F &end, RayInfo* info)
?
There are comments all over those indicating the collisions are axis aligned in world space - you'll probably have to update.
#4
I also cannot see what that has to do with it aligning with world space, but that's my inability rather than anything else and I do thank you for answering my questions, Ben. :)
09/17/2006 (2:10 pm)
Aye I have, and I cannot spot where it limits to only the Z axis.I also cannot see what that has to do with it aligning with world space, but that's my inability rather than anything else and I do thank you for answering my questions, Ben. :)
#5
09/17/2006 (2:41 pm)
It's an OrthoBoxConvex - check the transform code for it. :)
#6
Thanks again.
09/18/2006 (6:04 am)
OK this is over my head. I purchased the Tank Pank to take a look at their code, instead. Not that it looks like it will help, but its cool.Thanks again.
#7
I checked out the Tank Pack, and tankShapes *do* update their bounding box rotation, however - buildConvex () and buildPolyList () are 99% the same as the stock Player. This leads me to believe I should dig somewhere in updatePos ().
My first guess was that it had something to do with the collisionMatrix, but it's all greek to me. Can anyone throw me a bone?
09/20/2006 (8:06 am)
Turns out the box rotation is not updated at all, only its position.I checked out the Tank Pack, and tankShapes *do* update their bounding box rotation, however - buildConvex () and buildPolyList () are 99% the same as the stock Player. This leads me to believe I should dig somewhere in updatePos ().
My first guess was that it had something to do with the collisionMatrix, but it's all greek to me. Can anyone throw me a bone?
#8
09/20/2006 (9:57 am)
The ortho box convex is always axis oriented, Stefan.
#9
Besides, I previously switched to BoxConvex and there was no visual difference (though I do see the former overrides setTransform ()).
Even if that was the problem, then how come the TankPack uses OrthoBoxConvex, but still the collision bounds rotate? It doesnt make sense.
09/20/2006 (10:08 am)
Are we talking about the same thing, Ben?Besides, I previously switched to BoxConvex and there was no visual difference (though I do see the former overrides setTransform ()).
Even if that was the problem, then how come the TankPack uses OrthoBoxConvex, but still the collision bounds rotate? It doesnt make sense.
#10
Well, have you tried dumping the transforms that are bring set, or manually applying a rotation to them?
09/20/2006 (10:22 am)
Ah - good, we are talking about the same thing. I thought you were totally missing my point vis a vis ortho box convex. :)Well, have you tried dumping the transforms that are bring set, or manually applying a rotation to them?
#11
Aye, I manually applied transforms in a few key places but no difference. I'm rendering the polyLists and object/world boxes in renderObject () to make it easier to figure it all out, but I'm kinda stuck for the moment :)
Am I correct in assuming that the polyList type (early-out, extruded, etc) has little to do with this, and it's the implementation around it (in my example, the Player class) that controls how the collisions are passed before they get to the polyList?
09/20/2006 (12:07 pm)
Glad we do :)Aye, I manually applied transforms in a few key places but no difference. I'm rendering the polyLists and object/world boxes in renderObject () to make it easier to figure it all out, but I'm kinda stuck for the moment :)
Am I correct in assuming that the polyList type (early-out, extruded, etc) has little to do with this, and it's the implementation around it (in my example, the Player class) that controls how the collisions are passed before they get to the polyList?
#12
Have you read MattF's collision tutorial? It explains how the collision system works in some detail.
09/20/2006 (12:10 pm)
Yes, the type of polylist is irrelevant for you.Have you read MattF's collision tutorial? It explains how the collision system works in some detail.
#13
The text file is also of great help, but where it mentioned this very topic, it didnt touch on the specific part of the code or where it was.
Edit: OK I got it. By reading alot of posts by JW. Hardwitser and Manoel Neto + some others, I managed to make the box rotate with the player (check out the collisionMatrix) but that brought alot of other problems to the table which has to do with how the collision code assumes the box extends in all directions and not just one (I think). This makes the object pass trough geomatry easily. I'll have to work on that.
Thanks again Ben for your help!
09/20/2006 (12:25 pm)
Yeah, I have used Mattf's tutorial since I found it a few weeks ago. Great stuff.The text file is also of great help, but where it mentioned this very topic, it didnt touch on the specific part of the code or where it was.
Edit: OK I got it. By reading alot of posts by JW. Hardwitser and Manoel Neto + some others, I managed to make the box rotate with the player (check out the collisionMatrix) but that brought alot of other problems to the table which has to do with how the collision code assumes the box extends in all directions and not just one (I think). This makes the object pass trough geomatry easily. I'll have to work on that.
Thanks again Ben for your help!
Associate Kyle Carter
If you want to allow full rotation then you may as well just subclass from Vehicle - I originally went to add tilt/pitch to the player and found that I was just reimplementing it. :)