koobas.hobune.stream
Computational cost of using many Triggers (occlusion culling)
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?)
what exactly do you want to optimize? object's function or rendering? or may be physics?
for rendering (i think you rather mean rendering) you simply can use camera far clip plane - all object that are far from camera will no render.
also, you can set far clip plane different for different layers. small objects can be clipped with less distance
you can use simple shaders and geometry (LODs) for big objects at far distances
you also can use lightmaps instead of real-time shadows
to optimize scripts performance you should disable everything you needn't at moment and to make simple functions anywhere you can. use cheap calculations, coroutines ins$$anonymous$$d of updates, etc
Yes! I'm aware of that fact, and that's why I'm trying to optimize my code now. But the problem with using draw distance alone is that in a scene with 200 NPC's around, I cannot have them all running at once if they're all within the draw distance. For big pieces of scenery, that's fine - they're just static meshes. But I need something to cull other 'active' objects so that Updates aren't wasted on them - I hope that by using triggers, I can keep objects next to the player active and then cull out the rest.
one more way to go:
make a something like 'WaitingFactory' class that will receive all active GameObjects and checks for distance between this GO and player. using a Coroutine once a second (5 second, 20 second - depends on gameplay) it should check for distance between GO and Player and disable/enable it.
