Multi-Position BoundingBox Bug
by CSMP · in Torque Game Engine · 08/02/2009 (10:13 pm) · 7 replies
I've been trying to debug as much as I can in my engine however I've just ran into this bug, and its a strange one at that, this is going to be a bit difficult to explain, but here I go.
I've Installed the "Multiple Positions", "Multiple Position Enhancements" and the "Pseudo Auto-Bounds" resources, in which the Pseudo Auto-Bounds was installed only to try and remedy the bug mentioned here.
When I switch to the Prone position and crawl forward into the Y-Axis of an interior(with the Y-Axis of my player) the player stops where it should according to my BoundingBox dimensions.
However, When I crawl forward into the X-Axis of an interior(again, with the Y-Axis of my player) it seems the character stops inside of the interior.
Now it seems when I run into interiors depending on which side (X/Y Axis) I collide with is the side it uses for my Players BoundingBox dimension.
More Examples:
player crawls (forward=Y-Axis) into interior Y-Axis, interior uses players Y BB dimension.
player crawls (forward=Y-Axis) into interior X-Axis, interior uses players X BB dimension.
Now the problem is, forward will always be the Y-Axis on my player(and should always collide with the Y BB dimension) and sideways will always be the X-Axis...
And the collision problems happen in vice-versa as well.
(for ex. player crawls sideways (X-Axis) into interior Y-Axis, interior uses players Y BB dimension, in which should only be used if crawling forward, therefore stopping short of colliding with the actual interior)
I hope you all can understand this, as I confused myself many times trying to get this problem in writing. :)
I've Installed the "Multiple Positions", "Multiple Position Enhancements" and the "Pseudo Auto-Bounds" resources, in which the Pseudo Auto-Bounds was installed only to try and remedy the bug mentioned here.
When I switch to the Prone position and crawl forward into the Y-Axis of an interior(with the Y-Axis of my player) the player stops where it should according to my BoundingBox dimensions.
However, When I crawl forward into the X-Axis of an interior(again, with the Y-Axis of my player) it seems the character stops inside of the interior.
Now it seems when I run into interiors depending on which side (X/Y Axis) I collide with is the side it uses for my Players BoundingBox dimension.
More Examples:
player crawls (forward=Y-Axis) into interior Y-Axis, interior uses players Y BB dimension.
player crawls (forward=Y-Axis) into interior X-Axis, interior uses players X BB dimension.
Now the problem is, forward will always be the Y-Axis on my player(and should always collide with the Y BB dimension) and sideways will always be the X-Axis...
And the collision problems happen in vice-versa as well.
(for ex. player crawls sideways (X-Axis) into interior Y-Axis, interior uses players Y BB dimension, in which should only be used if crawling forward, therefore stopping short of colliding with the actual interior)
I hope you all can understand this, as I confused myself many times trying to get this problem in writing. :)
#2
Obviously this is mainly a problem when Prone and not so much when Standing or Crouching, as they have about the same X and Y dimensions.
08/02/2009 (10:41 pm)
The actual BoundingBox is rotating and scaling correctly with the player(according to "$GameBase::BoundingBox=true;"), however the axis in which I collide with an interior is determining the BB collision axis of my player.Obviously this is mainly a problem when Prone and not so much when Standing or Crouching, as they have about the same X and Y dimensions.
#3
Then I tried making the Y-Axis bigger (only in prone) to stop the player from getting so close to the building.
However, I then found out it was actually only going through on two sides of the interiors (X-Axis) and stopping where it was supposed to on the other two sides (Y-Axis). (All the demonstrations given in this reply are based on forward movement = Y-Axis)
08/02/2009 (11:13 pm)
At first I thought it was just the BoundingBox Y-Axis being too small, because I was looking and shooting "through" my interiors...Then I tried making the Y-Axis bigger (only in prone) to stop the player from getting so close to the building.
However, I then found out it was actually only going through on two sides of the interiors (X-Axis) and stopping where it was supposed to on the other two sides (Y-Axis). (All the demonstrations given in this reply are based on forward movement = Y-Axis)
#4
I'm not sure exactly what the fix is... as a simple experiment, I'd try renaming all instances of OrthoBoxConvex in your Player code files to just BoxConvex. The two classes are similar, but OrthoBoxConvex does some stuff to make sure it stays aligned.
Now, I'm not too sure about that solution, but I'm pretty sure I know what the problem is you're describing. Your player's bounding box is not rotating properly.
08/03/2009 (2:38 am)
Okay, I read everything again and I think that in fact the collision box is not being oriented correctly. When you render the boxes with the console variable you mentioned, they may look correct, but I don't think the collision box is actually rendered the same way as it is used. I had to deal with this when I got Players to use quaternion rotation - the default Player bounding box is designed to remain axis-aligned, it is even named 'OrthoBoxConvex' because its box remains orthographic (aligned to the principal axes).I'm not sure exactly what the fix is... as a simple experiment, I'd try renaming all instances of OrthoBoxConvex in your Player code files to just BoxConvex. The two classes are similar, but OrthoBoxConvex does some stuff to make sure it stays aligned.
Now, I'm not too sure about that solution, but I'm pretty sure I know what the problem is you're describing. Your player's bounding box is not rotating properly.
#5
I am trying your "experiment" right now to see what results I can get.
Edit: No deal, However, I've just tested the CSK Prone position and it seems that Duncan Gray has fixed this somehow.
Though I am not using the CSK Core and much of the code was not commented well enough, I will try and find what Duncan has modified to fix this problem.
08/03/2009 (10:00 am)
Ok, well if the BoundingBox graphics don't truly represent the players dimensions then what your describing sounds logical.I am trying your "experiment" right now to see what results I can get.
Edit: No deal, However, I've just tested the CSK Prone position and it seems that Duncan Gray has fixed this somehow.
Though I am not using the CSK Core and much of the code was not commented well enough, I will try and find what Duncan has modified to fix this problem.
#6
08/04/2009 (10:25 pm)
Try using WinMerge to diff the player.cc file from stock and CSK, specifically looking at the updatePos method.
#7
(even though there are a couple functions that I would love to have... and have tried multiple times to extract)
I will return to this problem soon, however I would like to make some progress in other areas before getting back to trying to Merge this over as the CSK has given me many hours of WinMerge hell.
08/05/2009 (3:19 am)
I'm not that experienced when it comes to c++ and even with WinMerge I have been able to extract very little usable code from the CSK's source.(even though there are a couple functions that I would love to have... and have tried multiple times to extract)
I will return to this problem soon, however I would like to make some progress in other areas before getting back to trying to Merge this over as the CSK has given me many hours of WinMerge hell.
Torque Owner Daniel Buckmaster
T3D Steering Committee