Question Any way to temporarily didable CompositeCollider2D to enable testing of individual colliders?

It is often useful to do tests on individual colliders that make up a CompositeCollider2D, but the composite obviously overrides them, and cant be disabled at runtime (the option exists in script, but doesnt seem to do anything). I've also tried destroying the composite, testing, and then replacing it, but the tests still fail; I'm assuming it takes time for the destruction to be recalculated, or something to that effect.

So, just wondering, if anyone would have an idea how to achieve what I am after; the ability to interact with colliders that have been made part of a composite? (at specific moments)

Many thanks in advance.

 

Have you tried just disabling the CompositeCollider2D?

I imagine that might do what you're after... but I am pretty sure all colliders are destroyed and rebuild afresh, which might have implications for messages coming from them.

Or I suppose you could use each individual collider and Overlap() it yourself in code...

 

Although the option exists in script to enable/disable composites, it doesnt seem to do anything, as far as I can tell. There is no enable checkbox next to the composite component in the inspector, so I think this reflects the fact. (or could be unrelated; I'm just guessing.) I just tried again, and that seems to be the case. Setting enabled to false via script seems to have no effect.

Individual colliders do not seem to react when set as part of collider. They return no results when addressed directly. I also just tried setting the individual collider "usedByComposite" to false, and that makes no difference. The collider returns no results when queried by overlapcollider, and if I run a test on the composite, it still returns results including the individual that I just removed from it. Changes to composites seem to not take effect immediately. There is a "synchronous/manual" setting for changes to the composite...I might try changing to manual, triggering, testing...then changing back. Worth a shot I suppose./

 

What about disabling it, then triggering an update, then seeing what happens?

If it still behaves same-same when disabled, this would kinda mean it is behaving counter to the way most other colliders behave in Unity.

I take your point about the lack of checkbox but it DOES have the .enabled field, which is something that (for example) a Rigidbody does not have. I think the lineage of the Rigidbody is slightly different from most other Behaviour-ish stuff.

Perhaps again it might be time to page @MelvMay to see what he might think of your original question?

 

Updating the compositecollider2d (I used SyncTransforms2D...which I presume is what is needed) does disable the composite as you suggested. Unfortunately, individual colliders still each need to be unset as "used by composite" or they dont seem to be detectable on their own.

So my solution became: detect overall composite; trickle through composite and turn off all "used by composite" settings in each and every individual. SyncTransform2D. Detect individual. Then turn everything back on again.

It works, but not the most elegant. Still hoping for a "ignore composite" kind of solution. I will return to it after a breather.

Thanks again.

 

Hi. Thanks for the response. In essence: I am trying to detect collisions between large shapes all comprised of smaller shapes; sometimes I need to know that a big shape has hit things; sometimes I need to know which smaller shape has hit things. Indeed, I am looking for a solution whereby I have both the composite collider and the individual colliders at once.

You are right, that the SyncTransforms didnt do anything. It was my imagination that it was somehow having an effect, and I just took it out and everything kept working as usual.

I guess it boils down to: is there any advantage to using a composite in this case at all? I have no reason to use composites, except I thought it might be a wise thing to do in terms of performance. (A few colliders bumping around, verses several hundred...maybe a thousand down the road.) If it makes little difference to how much work Unity does, I may as well just keep with individual colliders.

Many thanks.

 

"any collision events (OnCollision/OnTrigger) are reported on the collider gameobject but also on the rigidbody gameobject (if that's different)"

Wow. That's the Eureka moment. I had no idea, although it perhaps explains some curious results I've had previously. Thanks so much. I think armed with this I can get the end result I am chasing.

I would post a video, but I have no idea how to do that.

 

On this exact topic:

I only learned just a few short years back ("Eureka!") that the OTHER GameObject's colliders would ALSO get pinged upon collision, as long as at least one side of the collision had an RB/RB2D. I had read the docs strictly and assumed that I had to handle all the messaging only on the RB side.

You would not believe the knots that I had tied my code into to just to learn which base my lunar lander had touched!

 

Yes, just realising that I can cycle though my contacts of Collision2D is a big deal. Worse, I've read it many times, but a lot of stuff just doesn't click until I use it.

Wow. Both of you hitting 10 years on this forum. Impressive.