Since I’m using Unity Basic and developing for iOS, I need to make sure to optimize the rendering of my scene. Since I’m too lazy to deal with octrees and other correct ways of culling the objects on the screen (plus I’m still relatively new to Unity!) I’ve decided to use many, many triggers.
Here’s my setup:
- Create two layers, “Player” and “Optimization”
- Set layer collision matrix so that “Optimization” can only collide with “Player”
- For each GameObject in the “Optimization” layer, add a Trigger Collider to it with a script
When my player collides with an object, “OnTriggerEnter” gets called and I activate the GameObject’s immediate children.
When my player exits an object, “OnCollisionEnter” gets called and I deactivate the GameObject’s immediate children.
With how Unity allows parenting and children, I can increase/decrease these Trigger boxes in size. So, I could make one really big trigger that contains several smaller triggers, which then in turn, turn on and off when the player moves between them. Since this only works when the player hits a collider, it doesn’t rely on Update or any other frame-intensive processes. Basically, this is a way to do octree-searching and culling through the physics engine, and not through algorithms and other code.
So — what are the possible problems with this? I’m thinking script management might be a nightmare compared to other methods, but I think I got it down pat with a basic abstract class for everything so I can extend the functionality for various types of objects without having to rewrite completely new and unrelated scripts.
That being said, what drawbacks are there to relying on Triggers so much (or is this kinda what they are for?)