Internal Edges, collision detection

Link to .capx file (required! If link is blocked remove the http and www parts):

*dropbox*.*com*/s/f45szxyb0pl3gjr/problemrender.capx

Steps to reproduce:

1. Enable physics behavior on an object and environment

2. create a tile map with square and triangle collision tiles

3. roll a ball ( physics object) around the environment

Observed result:

depending on what tiles are nearby, the circle will catch on internal edges. Depending on how the tile map is set (with respect to how many tiles and whether the collision polygons are square or otherwise) dictates where an object will catch an internal edge. In many cases it seems random, but when the game plays it is always in the same places. I have elasticity and friction set to 0 which means the ball object should not bounce off of a smooth surface. This allows the problem to be more apparent as no objects colliding with 0 elasticity should bounce apart.

Expected result:

Internal edges should be ignored by collision.

Browsers affected:

Chrome: yes

Firefox: yes

Internet Explorer: yes

Operating system & service pack:

windows 7 64 bit, service pack 1

Construct 2 version:

Release 158.2 64 bit

I have elasticity and friction set to 0. This allows the problem to be more apparent as no objects colliding with 0 elasticity should bounce apart.

There are several concurrent tests in the project. Starting from the left side- The first wall is made up of perfectly aligned objects repeated to make a wall. The ball is being launched at the wall at random speeds. When the ball hits the wall it bounces off of whichever internal edge it hits first. This is predictable. It can be solved by doing what is done in test #2. Simply use one physics object so there are no internal edges. Test 3 shows a wall made of a tile-map's various tiles (all with square polygon collisions). The wall behaves perfectly expected. The ball hits the wall and slides downwards unobstructed. However, not test #4 the ball is colliding with an internal edge, seemingly triggered by the neighbor tiles. I moved the tiles around and it very much has to do with what surrounds the tile. The final test shows how if you put a ramp tile at the end of a bunch of square tiles (this works outside of the tile map as well) The ball will "trip up" on the internal edge between the two and rather than smoothly gliding off of the ramp there is a noticeable pop in the upwards direction.

Is there something that can be down about this? I know internal edges is a huge problem in collision detection, depending on what method is used (such as speculative contacts) I have used box 2d in other applications, including simply as a library in my own xna games, and did not come across this problem. I was wondering if there was perhaps a problem in contruct2 when it is setting up the collision polygons.

Any insight and or help would be greatly appreciated. It is possible that I could make a work around but that means I loose the ease-ability of using tile-maps. It also means I will have to make alot of extra objects to avoid any internal edges (and since my game is quite ramp heavy, that is alot of objects, some of them quite large)

Your .capx does not appear to reproduce the described problem. Could you attach one that does?

I am so sorry, I posted the wrong file.

*dropbox.*com/s/20rwcuvnrzfeh2p/CollisionsProblem.capx

Sorry about the mix up.

Does it happen when using ordinary objects (e.g. sprites, tiled backgrounds) instead of a tilemap?

If so it's probably just how the physics engine internally handles collisions. I'm not sure there's much we could do about it.

The test has ordinary sprites lined up on the left side. objects predictably collided with every internal edge in this case. Tiles maps work well in some cases but it seems that the context of the tile influences whether or not an internal collision occurs. I know there are ways to avoid this, such as using edges to border an object, but I don't know how contruct2 interacts with box2d. It may be entirely box2d or not. I have worked with it in other cases and avoided problems but that was in c# and I wasn't trying as many complicated things.

I think this is just how box2d calculates collisions internally. I don't think we can change it at all I'm afraid. A workaround could be to use invisible objects without edges for collisions.

Hey thank you though. I really think construct 2 is an amazing tool. I appreciate the time you take to help us users out. I switched to it quite recently form xna and though sometimes I wish I could just code events, everything is well worked out and the flow is quite smooth. Thank you for all your hard work. It's fantastic.