I have a game, where I use multiple tilemaps with composite colliders, to be able to distinguish between those. Problem is, sometimes, when I try to walk over a composite collider of another tilemap, I get stuck at that area. Here is something I drew, so you can better understand my problem:
Making my collider rounded won’t work because my player would jump at that clipping point, because my player is physics based. I also tried to make a parent of my tilemaps, to make all of my tilemaps into one whole collider, but then the problem is, that I can’t distinguish which tilemap was hit. I need to know which one of those tilemaps were hit in the OnCollisionStay/Enter etc. methods. How would I fix this problem? Any help is greatly appreciated
This is known as a ghost collision/vertices and can only be removed by using continuous edges (either EdgeCollider2D edges or CompositeCollider2D Output). Two colliders next to each other are not a continuous edge and during solving it’s possible to catch edges.
Only when you use Outline mode in the composite will it work for those continuous edges but putting two composites next to each other is not the same. Basically it comes down to the fact that collisions do not happen across multiple colliders (shapes in the physics engine). They happen one at a time.
As you’ve already hinted at, often the use of Capsules means that the effects of hitting (in your example above) the vertical side or corner vertex is reduces. The collision normal for that type of collision is no longer upwards but will point opposite the direction of motion so the physics engine will apply a force as if you’re hitting something.
There are no fixes for this because it’s just how it works and I can understand that if you didn’t know about this it seems like sillyness but as developer of Box2D states in one of the links above, it’s a tricky and somewhat complex problem. It certainly is frustrating and there are things coming that will help remove this issue including contact modification.
Hey, thank you for your answer, it does clear up things a bit
That does leave me to a concern though, does that mean there is no way to fix this problem? Or atleast bypass it? My composites could be all one big composite, but I just need to know which tilemap was hit, maybe there is some other way to accomplish that.
Also, how do games from bigger companies fix this? In those plattformer games e.g Ori and the blind forest, there are platforms with different attributes, so how do they fix this clipping issue while still also being able to know what was hit?
I will add that we implemented the CompositeCollider2D to get around this (Outline mode) beause you can merge multiple colliders to produce a single continuous surface. I cannot then stop devs creating multiple composites and then wanting them to work side-by-side because that is then back to square one.
It’s a difficult problem and as I said, there’s things coming to help this. In the end, it comes down to using continuous surfaces (edges). Multiple EdgeCollider2D can be joined together to work as a continuous surface so multiple colliders using its adjacent edge feature.
There is no “fix” though to make two arbitrary colliders act as one continuous surface though.
I think a very useful method to add to a composite collider would be something like, GetOriginalCollider(idOfCollider). For example, lets say I have combined multiple colliders into one, but now I need to know which of those combined colliders were hit.
With this new method, I could then simply say
to know if the player is touching that specific collider.
I don’t really know if that’s the case, but I do think, that implementing a GetOriginalCollider() method would not be that hard. But what do I know
Anyways, I do think that’s a good idea to fix problems people like me are having and also think the implementation of that fix should be easy. Then we could just have one collider for everything, and still be able to differentiate between all of them. I would suggest considering to add this to Unity.
Edit: I just realized, this makes no sense, lol. It wouldn’t work because the composite is getting touched and not the original collider. But still, something in this manner could work.
Absolutely, spot on. An edge could be a composite of many colliders. This is the problem. If it were possible, trust me, it’d already be there.
The thing is, if you have a contact point in space, you can easily convert this to a tile position via the Tilemap/Grid. It has world-space to logical tile-position conversion methods.
There is work going on in this space and we’re very aware of this being a problem. This will be solved!
Just to reiterate, the only way you’ll not get these “ghost” collisions is by using edges the physics system provides. There is no other solution and there’s no fix because it’s not broken, it’s how physics systems work including the 3D physics system.
The main thing we want to do is provide features that can do some automagic work with such edges for you.
I detailed it above so I’d just be repeating myself. CompositeCollider2D in Outline and the EdgeCollider2D both produce continuous edge-chains (edges) that don’t have this problem.
More importantly, even separate collider edges can solve this problem because of the feature I posted above in the video. It can do this because alongside the edges, on either end, you can hint to the solver where the next logical edge will be (on a different collider). This stops it hitting side edges etc.
What I’ve done is have a method that stores each collider in a given radius and adds it to a singular composite collider & takes it off when it exits that radius. depending on how your chunk information gets stored this can be very simple. if its small enough you could just take the chunk you’re in, & the adjacent chunks & add that to 1 composite collider. As long as that composite collider remains small in terms of tiles processed to it, you won’t experience any lag spikes. if everything is stored by variables including chunk size, just make chunks processed by a smaller amount like 8 instead of 16. This will allow for a much smaller processed range when computing which is a great optimization imo. It worked perfectly for me, hope this helps. (execution was a bit hard as I had to re-arrange how my information was stored as you can’t access a tile according to position or using the OverlapBoxAll method as all information is lost when converting from an individual collider to a a composite collider. I’d recommend using scriptable objects to store chunk information)
Thanks! This seems very promising. That’s a very interesting solution you got there. I would just expect Unity to already have a built-in solution, since it’s an Engine that is already pretty old and very popular.
Anyways, once I have time, I’ll take a look at your solution, thanks!
I have no idea what you mean by “built-in solution”. There IS a solution and that’s to use continuous edges as outlined above as those are the ONLY continuous surfaces supported. Individual physics shapes are NOT a continuous surface. Use PhysX or Box2D or Havok, it’s the same thing.
It’s easy to throw the “hey, let’s have a built-in solution”, when you don’t understand what the problem is. There is no general solution for all project types possible here.
The CompositeCollider2D let’s you blend physics shapes together and produce continuous surfaces. That’s a solution but then it’s taken to the extremes by compositing hundreds or thousands of colliders together then wanting to change it all in real-time. It’s a solution that’s being pushed too far.
There is only so much that a “general, built-in solution” can do without taking in the specific considerations of the project it’s being used in.
We introduced the CustomCollider2D and PhysicsShapeGroup2D that let’s you create your own colliders and can contain as many as you like of any of the primitive physics shapes. You could write your own composite collider there or make a collider that only uses continuous edges. This is the most general built-in solution you could use. It’s raw access!
The above idea of using multiple composites in chunks doesn’t address continuous edges. They are still separate and will not solve the issue.
