I have 2 objects. Player and Tower set to layers Player and Armory respectively. Both have rigidbodies. Each one has a child called Vision which is a sphere collider set to trigger and both visions are in a layer called Trigger. In the Physics inspector, I set the collision matrix NOT to collide between Trigger/Trigger but collide between Player/Trigger, Armory/Trigger.
So, I assume that those Vision triggers are not going to collide with each other. But they do. I get OnTriggerEnter/Stay/Exit between these 2 colliders which are in the same layer Trigger. Which is set not to collide.
Is the physics engine pretending that the Vision child of Player to be in the same layer of Player? And the same for the Vision child of Tower?
So far I haven’t even used trigger functions whatsoever. Perhaps they will save you time if you use them properly but in my experience so far they are not necessary.
If you are having trouble getting them to work properly you could try something like this:
void OnCollisionEnter(Collision theCollision)
{
//get the script for the object which you are checking collisions for example:
ArmoryScript otherObjectsScriptArmory = theCollision.gameObject.GetComponent<ArmoryScript>();
if (otherObjectsScriptArmory != null) //the script IS on that game object
{
//your desired behavior
}
}
Using something like that has allowed me to detect all collisions between objects as expected. In this example you would put this in your Player’s script to detect if a collision occurs with a game object containing your Armory Script.
This method allows you to check for as many different collision types as you want all within one function.
Triggers may actually be the superior method but right now I prefer this.
This example is assuming the script attached to your tower is called ArmoryScript. You will need to adjust all the names to suit your project.
As far as I can tell, a script attached to a trigger will not get the 3 OnCollision events. It will get the 3 OnTrigger events. I don't know if I want to check the components like that either. That can be fine if you have a small number of component types to check against. But if there are a bunch, this can be very costly, especially for mobile.
I agree the downside to this method is that it could be costly on performance. It seems like checking 3+ different components on my current Android project is not causing issues yet though. I think if you use: return; within the different object checks and start with the most likely colliders it won't be to bad. I just like this method because it's very easy to set up. I am curious how much of a performance difference it actually is with the trigger events.
@unity_1905612 - you should post your own question, but you can achieve this by using both triggers and colliders. For the huge box, when the small objects are on the way in, use triggers, then swap to colliders once inside.
I not familiar with the internals, but I would assume trigger would be quicker since they are mostly ignored by the physics engine since they don’t react to each other.
Debug.Log your objects’ layers and names in your trigger functions, to be sure everything’s in the layer you expect.
You could also try making your player and its vision object children of a new, default-layer object, and see if that brings up collision issues.
If your player has a rigidbody/Controller, and your vision does not, AND your vision is a child of the player, it’s possible that the entire collision tree is being set to the same layer as the rigidbody. The fix to that should be as simple as adding a kinematic rigidbody to each vision objects.
As far as I can tell, a script attached to a trigger will not get the 3 OnCollision events. It will get the 3 OnTrigger events. I don't know if I want to check the components like that either. That can be fine if you have a small number of component types to check against. But if there are a bunch, this can be very costly, especially for mobile.
– FilippopotamusI agree the downside to this method is that it could be costly on performance. It seems like checking 3+ different components on my current Android project is not causing issues yet though. I think if you use: return; within the different object checks and start with the most likely colliders it won't be to bad. I just like this method because it's very easy to set up. I am curious how much of a performance difference it actually is with the trigger events.
– RyanZimmerman87@unity_1905612 - you should post your own question, but you can achieve this by using both triggers and colliders. For the huge box, when the small objects are on the way in, use triggers, then swap to colliders once inside.
– hjc