I recently upgraded to 2023.1.8 because there is new feature called composite operation.
I expect this feature can be used as collider mask but unfortunately i still don’t really understand to use it properly and can’t make it work as i expected.
I created two tilemaps with composite collider component and make the collider in both tilemap overlap each other. The idea is to remove the collider in the overlap area, so i use Flip (XOR) operation in the first tilemap.
Here are my settings in both tilemap :
I actually did some trivial approach to use other combination of composite Operation in each tilemap but still no difference. I also tried to change the layer overrides settings trivially to see if there is a difference, but still nothing.
The CompositeOperation is used to control how compositing works for each composite. Two separate composites are just that, separate! In the example above, you’re not compositing any colliders together. You’ve just got two TilemapCollider2D and they are the only thing being used by each composite.
If you want to perform composite operations on two TilemapCollider2D then they need to be using the same CompositeCollider2D so place the composite on their parent GameObject and remove the ones on the Tilemap GameObject.
Layer overrides are nothing to do with the composite as the docs state.
You should try to understand how it works on a trivial example before moving forward. Get two colliders, add them to the composite using various composite operations.
How can I show the collider shape in color, like in your example? I downloaded it from your GitHub, and it works there, but I can’t seem to display the shape in my own project. I can’t find the code to make it show up.
Quick question for you, sir! How efficient is this CompositeOperation during Runtime?
For instance, let’s say I have a big boxcollider2d (merge)
And inside, i have a small boxcollider2d (difference)
If i move the small boxcollider2d around during runtime, is this inefficient?
Imagine everywhere is LAVA. And the small box inside is the only safe zone that the player must stand on… and there is more than 1 small box where player can go to. That’s where I am getting at.
I cannot give you an answer on “how efficient” it is; the compositing isn’t meant to perform thousand of operations in realtime but it’s certainly fast. It was original meant for authoring but allowed to be changed in runtime because, why not?
Is it good for what you want to do? Maybe. Try it in a prototype and run the profiler on it, also on the device(s) in question; it’s the only way to really know.
The size of a collider isn’t relevant. a Box has 4 vertices to deal with no matter how they’re positioned. The composite has to deal with all the vertices of all the colliders in the composite; it’s this that changes how much time it takes. When devs use it on TilemapCollider2D, those have 10s of thousands of vertices to deal with so a single change is expensive.
The problem is, all a CompositeCollider2D is doing is generating collision geometry. By changing this, any existing contacts will be reevaluated and it’s easy to cause overlaps with enemies, players etc. The solver will solve these but it isn’t movement. Caution is advised.
NOTE: Please create your own threads rather than hijacking existing ones please.
