Box2D Collision Normals Seem Reversed
by Meredith F. Purk II · in Torque 2D Beginner · 08/24/2015 (5:39 pm) · 11 replies
So in adding features to my platformer concept, I've decided to add platforms that are generated during gameplay. Trouble is that the collision normals from these new platforms seem to be the opposite of what they should be. For instance, the player lands on the top and is caught in a freefall and unable to jump again. If they hit the bottom of the platform they hang in the air but can run side to side. Gravity is switched off as if they are standing on the ground.
The platforms are otherwise identical to ones created when the level is first generated and just have a box collision shape and are passed through the same functions.
Is there a work around or an obvious fix I may have missed?
The platforms are otherwise identical to ones created when the level is first generated and just have a box collision shape and are passed through the same functions.
Is there a work around or an obvious fix I may have missed?
#2
08/24/2015 (6:28 pm)
Roger. I will experiment with that to see what happens with a cloned platform, or if the if the vertex order changes it.
#3
And creating a clone of a normal, working platform or block ends up with the same result - the newly added collision shape returns the wrong normal, so up is down.
I spattered a few different platform generation calls in the code, and the moment I add the player object to the scene, that's when the new platforms suddenly return the wrong normals.
It's worth noting that creating a passable, one-way platform (which uses those one-sided edge collision shapes that were drummed up) works as one would expect.
08/25/2015 (7:28 pm)
Well, did a little test and it doesn't seem to make any difference. First, I verified that the function I'm using doesn't actually create the vertices manually, it just passes a position (x,y) and a size (x,y) and uses them to create a sprite w/ box collision shape at the position matching the size.And creating a clone of a normal, working platform or block ends up with the same result - the newly added collision shape returns the wrong normal, so up is down.
I spattered a few different platform generation calls in the code, and the moment I add the player object to the scene, that's when the new platforms suddenly return the wrong normals.
It's worth noting that creating a passable, one-way platform (which uses those one-sided edge collision shapes that were drummed up) works as one would expect.
#4
@Meredith - Assuming you're using T2D and not TGB, here are my findings after a few hours of..."fun" :)
- Edges and ChainEdges : work as expected, the collision normal points Away from the face. One-way or not.
- Polygon Shapes (box & Polygon) work as expected, UNLESS the collision is strong enough to penetrate, in which case the normal points towards the inside of the shape. These shapes seem unaffected by winding (clockwise or counterclockwise).
- Circle Collision Shapes : Upon impact, collision normals always points towards the inside of the circle, regardless of impact velocity.
- Whether the player is a circle, box or polygon shape, they exhibit the same behavior regarding impact normals.
- Edge and Chain Collision shapes don't seem to work for moving objects...
- Strangely, collision between two moving bodies seems to work fine, normals point out of their collision shapes whether they are boxes or circles.
- Setting the physics type to "Bullet" changes nothing regarding the impact normals.
Hoping this might help shed a bit of light on the issue!
08/25/2015 (11:11 pm)
@Richard - Normals will point "out" if the vertices are created clockwise, so left to right. @Meredith - Assuming you're using T2D and not TGB, here are my findings after a few hours of..."fun" :)
Platforms
- Edges and ChainEdges : work as expected, the collision normal points Away from the face. One-way or not.
- Polygon Shapes (box & Polygon) work as expected, UNLESS the collision is strong enough to penetrate, in which case the normal points towards the inside of the shape. These shapes seem unaffected by winding (clockwise or counterclockwise).
- Circle Collision Shapes : Upon impact, collision normals always points towards the inside of the circle, regardless of impact velocity.
Player Object
- Whether the player is a circle, box or polygon shape, they exhibit the same behavior regarding impact normals.
- Edge and Chain Collision shapes don't seem to work for moving objects...
- Strangely, collision between two moving bodies seems to work fine, normals point out of their collision shapes whether they are boxes or circles.
- Setting the physics type to "Bullet" changes nothing regarding the impact normals.
Hoping this might help shed a bit of light on the issue!
#5
08/26/2015 (7:18 pm)
Naw, we had Edge and Chain working fine. What happened?
#6
The issue pointed out by Meredith has occurred to me 2-3 years ago; I just moved on to another project and never bothered investigating it so it's definitely been around for a while.
Disclaimer : I am using a modified version of T2D where the ShapeID of collision shapes are stored in a static hashtable. In stock T2D, the shape IDs are stored in a Vector, local to each shape. No change to the collision functionality has been made so it shouldn't affect the issue at hand.
08/26/2015 (7:31 pm)
Edge and Chain work fine on statics on my side. On dynamic/player object, it fails to collide with others. Didn't have time to see what was up with that.The issue pointed out by Meredith has occurred to me 2-3 years ago; I just moved on to another project and never bothered investigating it so it's definitely been around for a while.
Disclaimer : I am using a modified version of T2D where the ShapeID of collision shapes are stored in a static hashtable. In stock T2D, the shape IDs are stored in a Vector, local to each shape. No change to the collision functionality has been made so it shouldn't affect the issue at hand.
#7
I suppose it just never showed up because all of our test cases were with a static collection of scene objects - it seems to be puking on adding new stuff. I can't imagine why the path would be different for dynamically created objects after level load - I mean, level load is just a batch of dynamically created objects, right? Have to put on my thinking cap....
08/27/2015 (5:47 am)
Sounds like a non-breaking change (and time-saver - optimization?) and I concur that hashtable vs object-local vector shouldn't affect the outcome.I suppose it just never showed up because all of our test cases were with a static collection of scene objects - it seems to be puking on adding new stuff. I can't imagine why the path would be different for dynamically created objects after level load - I mean, level load is just a batch of dynamically created objects, right? Have to put on my thinking cap....
#8
I'm not sure how recent my build is, but I'm sure its at least a little behind. I'll probably see about merging the custom code into a more recent release to see if it changes anything.
08/27/2015 (3:33 pm)
Mmm... admittedly, my edge shapes are on static and kinematic (used for the moving platforms) bodies only, so I wasn't aware of anything squirrely happening with dynamic shapes.I'm not sure how recent my build is, but I'm sure its at least a little behind. I'll probably see about merging the custom code into a more recent release to see if it changes anything.
#9
For now, I can probably work around it by marking those items added later and using a logic check to return the inverse for those specific platforms... but it worries me that later on what would I do if some objects suddenly start returning the normals correctly again? ;)
09/13/2015 (12:26 pm)
So I finally had a chance to update to the newest version of the development branch and test some things. Still get the same problem with collision returning the normals incorrectly when the objects are cloned or created after the player object is added to the scene.For now, I can probably work around it by marking those items added later and using a logic check to return the inverse for those specific platforms... but it worries me that later on what would I do if some objects suddenly start returning the normals correctly again? ;)
#10
http://www.garagegames.com/community/forums/viewthread/134445
01/02/2016 (5:35 pm)
Could it be related to this issuehttp://www.garagegames.com/community/forums/viewthread/134445
#11
01/05/2016 (1:20 am)
The bug in the thread I mentioned has the effect of swapping the ObjectA and ObjectB identities in the collision information. This has the side effect of appearing to reverse the collision normal. The thread contains a fix. The collision engine is probably choosing A and B roles based on order of creation, hence the swap for objects created after your player. 
Torque Owner Richard Ranft
Roostertail Games
You could make one platform with a name, and then clone it as needed - might work.