Big Triggers caveats and alternatives

I’m getting ready to make my AI system and the first problem is defining the best method to process the closer objects only. For example, things of interest for the AI are doors, buttons, the player etc, so it has to check for everything that enters his cone of vision. I was thinking about using as cone a trigger collider and let the physics engine sort out all the distances for me. However, I did some testings earlier (unrelated stuff) and realized that objects instantiated inside a collider won’t trigger any of the relevant functions!

I don’t know of other possible traps with triggers, but I’d like some opinions on the subject or if someone advises some other approach, like keeping track of all objects that could interact with itself and calculate distances every frame etc.

  1. I would avoid checking stuff every frame. Use InvokeRepeating so that you can control how often you search. 10x/second is probably more than enough.
  2. You can use Physics.OverlapSphere to check for colliders within a radius

Other than that you could write some kind of manager that knows about all the doors/triggers/switches/etc then just check the range from the player there as you mentioned. This is potentially a lot more work.

We have that? :-o
If within radius, test if within cone. That sounds like a good candidate! Thanks :slight_smile:

Update: I was testing here and found that if the object is a rigidbody or character controller it will call the ontriggerenter and ontriggerstay functions, even if they start inside the volume I want. This is great news!

I’m a little embarassed, because I read so much of the documentation and yet this is the sort of information I’m certain it’s there. Oh well.

yes, objectes need to have a rigid body to even register.

I guess if the cone has the rigidbody it will be easier (make it Kinematic).