4.3 Physics2D.Raycast and Tilemap/Edge Collider 2D

[micky]

So I noticed that Physics2D.Raycast now hits colliders it starts within, or maybe my boxes (Edge Collider 2D) are just considered 4 "edges" to be hit. My character used to jump through my platforms and land on the top no problem, but with 2D Physics, he can land "inside" a box and stand on the bottom of it.

Is there something I should be doing to prevent this and obtain the Physics.Raycast behavior?

The docs mention something about the fractions being 0, but they are always > 0 for me.

Thanks,

[unikronsoftware]

The 2 ray cast behaviours are fairly different. There isn't a single thing to do to make it work consistently over both the engines. Edge colliders, as you've found, are pretty different to volume based poly / box colliders, but they are required for large static meshes. You'll have to tweak specifically to get this to work - sorry I can't provide specific advice, I only know as much as you do, I've never had the need to actually fix this.

[micky]

So whats the benefit of edge collider 2d vs polygon collider 2d? Perhaps polygon would allow the physics2d.raycast to realize it's inside of something as the docs suggest?

I was really excited for 2D physics but there seems to be several crippling aspects to it, such as kinematic rigidbody2d not firing trigger events like kinematic  rigidbody does.

[micky]

So I changed your code to use PolygonCollider2D instead of EdgeCollider2D and ignored hits with fraction == 0 and it seems to have restored the Physics.Raycast behavior! You land on them just fine but it properly ignores jumping "into" them.

If there's some reason to use Edge's still, you may want to give serious thought to supporting (at least an option for) PolygonCollider2D, as it makes or breaks the Tilemap editor imo.

I appreciate all your hard work on this thing, just trying to help out since all of this stuff is new.

[unikronsoftware]

There is a reason to use EdgeColliders over PolyColliders and that is performance. Edge colliders are built specifically for static worlds and there is a huge performance gain to be had from using them. Also, poly colliders can only be convex (they get broken up into multiple convex ones if you feed them a concave shape internally), and while this may work if your world is predominantly convex, it will fail to scale.

Having said that though, I haven't really put this to the test to see how big it would have to be to make a difference, but the box2d docs do recommend edge colliders for static world geometry... I'll have to do that at some point to determine what the best approach for this will be.

[micky]

I figured performance was probably the reason but I haven't thought of a single way to get around building world geometry with tiles where you can jump through floors properly with edge colliders. Far as the raycast is concerned, you are just slapping any ole flat surface, so there's no information to go off of in terms of what's above you. I thought I would have to make separate layers for floors, walls, ceilings, etc... veeery messy.

I'm all ears of course if anyone out there has figured this out though.

"Having said that though, I haven't really put this to the test to see how big it would have to be to make a difference, but the box2d docs do recommend edge colliders for static world geometry... I'll have to do that at some point to determine what the best approach for this will be."

I appreciate that you take the time to make this the best 2D package out there, it was worth every penny and I've been trying to get as many people as possible to buy your product because of that.

[Rirath]

I figured performance was probably the reason but I haven't thought of a single way to get around building world geometry with tiles where you can jump through floors properly with edge colliders.  I'm all ears of course if anyone out there has figured this out though.

I'm speaking well above my experience level here, so apologies if I've misunderstood, but this thread has a few techniques for one-way collisions that may help you out, and a custom 2d character controller that has implemented it.  Around here he talks about one-way collisions jumping onto a platform.  Particularly this post has a few techniques, and the foot collider method mentioned a few times seems most accepted and easiest to me.

Put all of the one-way passable objects onto a single layer.
Whenever your character's y speed is <= 0, enable collisions with that layer.
Otherwise disable collisions with that layer.
(Might want to add an additional check for overlap when re-enabling the collision check)

Though I hope Unity adds things like rigidbody2d.ignoreCollision soon enough.

[FZGames]

I know this is an old topic, but I have to add my opinion in here. I'm encountering a tonne of bugs due to the generation of 2D edge colliders instead of 2D polygon colliders, and feel there should be an option to choose polygon instead. Several times some physics event has pushed my player through the edge, and he's ended up stuck inside of the tiles, unable to get back out, and this often happens with physics objects, too. I can't really think of any way around this other than hard coding 2d Toolkit to create a polygon collider instead, and I'm not sure how to do that.

[unikronsoftware]

Creating a fully supported polygon collider solution that works in all circumstances is not straightforward, hence us not supporting it yet. Supporting a subset that most people want is pretty straightforward and people have posted code on the forums of how they've done it. I recommend looking for the other solutions people have posted - in some cases depending on what you're trying to use it in, that might just be enough.

[FZGames]

I have to insist, edge colliders aren't good enough for how the tilemap in this product is advertised (the main reason I bought it was for this tilemap). There's no way to tell if an object is in the ground, for example. I could put some hacky solution in here, but surely this should be a feature, even if it just creates individual box colliders for every tile as an option (without having to create a new prefab for every tile). This edge collider method assumes that nothing will ever need to pass through an object or detect if it's overlapping one or not.

[unikronsoftware]

This isn't going to happen in the near future. All my allocated time for the project is spent on support at the moment and I don't have the time to add and support a new (and large) feature like that right now. If it isn't doing what you want / need it to, email support and I'll sort out a refund.

[FZGames]

I don't want a refund, I'm just trying to make it clear that edge colliders really aren't an adequate solution, it's fundamentally broken if you aren't able to tell whether something is inside of an obstacle or not.

[FZGames]

I just wanted to come back and add a bit of an apology for my impatience here before. I didn't really fully understand how the physics engine worked, and having learned a lot more about it I now realise that edge colliders are probably the best solution here, and that I should have coded my enemy collisions differently to avoid being pushed through the edge colliders - as if the tilemap generated polygon colliders (or box colliders, or anything else), it'd actually have fared far worse, with the character probably being pushed right through the wall, potentially right out of the level.

The cause of my problems was my decision to ignore all collisions between the player and enemy layer when the player was damaged and flashing invincible, then re-enable them again, and sometimes the collisions were re-enabled whilst the player's collider was inside an enemy's collider, and the physics engine would decide that the best way to push the player out of that collider was through the edge colliders generated by the tilemap. So I basically re-programmed how the flashing invincibility (and enemy collisions in general) work, and now the edge colliders are perfectly sufficient.

As I mentioned before, I now realise that, in certain situations, this would have resulted in the player being pushed not just into a wall, but right through one, potentially all the way out of the level, if it had been done with polygon colliders or box colliders.

So apologies for my impatience, I thought it was the fault of the edge colliders.