koobas.hobune.stream
Checking frustrum against Bounds per Object VS Player&List?
Would it be better to check if the bounds of many objects are in frustrum by:
A) Putting a script on each object to be checked
B) Using one script with all objects in a List attached to Player, and iterating through them with loop
?
I guess another way of looking at the question is, would there be a big difference in overhead using GeometryUtility.CalculateFrustumPlanes in a lot of objects, since in a list, you only need to define this once for the entire loop of object bounds in a list? With a little script attached to each object, this would be calculated for each one of them. Is the performance difference little enough to justify using either method(lets say 500 objects with the script)?
If you're trying to do visibility testing, you can just use renderer.isVisible. http://docs.unity3d.com/Documentation/ScriptReference/Renderer-isVisible.html
(Note that this will return true if it is visible in the scene view)
Are you disabling the renderer for performance reasons? You shouldn't have to do that, Unity will automatically cull it.
In that case, I think you would be better off iterating through a list rather than attaching a $$anonymous$$onoBehaviour to each object. As long as you aren't using something expensive to generate the list, I believe it should be slightly faster.
Renderers also support OnBecameVisible() and OnBecameInvisible() messages. They'll only be called if the renderer is active, but your scripts will get the message whether they're enabled or not.
If you're really set on calculating this yourself, I would just try both methods and see (empirically!) if there's a significant performance difference. If not, just do whatever's easier to maintain.
One situation where I would perform additional culling of scene objects is with large chunks of terrain. In this scenario, you don't want to load all terrain data into the scene, you only want to load terrain chunks which would be visible, and unload terrain chunks which become invisible. This is used to reduce the amount of data in memory, which is especially important on mobile.
I would do additional culling of data being thrown at the engine only if you have large objects and if you're concerned with memory footprint. Otherwise, Unity already does visibility culling very well.
