- Home /
Should static duplicates be pooled?
Would there be any benefit from pooling objects that are duplicates if they are never moved or destroyed anyway?
For example. Let's say you've got a prop, and that prop is all over in your game. So you could either pool it, into its position needed, or you could just always have all of them "in place" but only the ones you can see are rendered.
So, I'm not really sure if there would be anything to gain from pooling duplicate static objects? I mean, besides maybe loading time, and if that was the only benefit, I would think pooling might put more stress than just having the duplicates present.
The only benefits you would "gain" from doing this are already gained by the use of shared$$anonymous$$esh
and batching. Also you can't move static objects. That would destroy other optimisations.
I think you can move them so long as you move them by the static objects root gameobject
maybe this would be a reasonable alternative to batching them? I think batching creates one big mesh from all the parts. So maybe you would save a bit from not having that mesh in memory? Hm....
Well you can technically, but you definitely shouldn't. The whole point of static objects is that they never move, and they are optimised so that movement checks are never performed. $$anonymous$$oving them just breaks this optimisation.
Batching would probably give you more of a performance boost than object pooling. Batching also has no overhead unlike the pooling you're suggesting.
Colliders on objects marked as static are also very optimised using trees to significantly reduce the amount of comparisons. If you constantly move objects, that tree will have to be rebuilt, causing even more overhead. If you're objects don't have colliders this isn't a problem of course.
Answer by Benproductions1 · Jan 25, 2014 at 12:01 PM
By pooling you basically want to reduce the overhead by introducing another overhead that scales better. It's impossible to tell without a very intricate knowledge of how Unity works under the hood, whether or not it can give any performance benefit. The same goes for losing performance of statics when moving their parent. It might be that the tree is on a per object basis along the parent-child tree, ot it might just be one whole tree for the entire scene.
In any case, I don't think it would be a good idea to try some hack like this to maybe possibly get a little bit of a performance benefit. There are much better optimisations (such as batching) you should be using.
Your answer
Follow this Question
Related Questions
Create an Instance? 2 Answers
Should I pool thousands of box colliders 0 Answers
Avoid NullReferenceException with Singleton 3 Answers
Having trouble with static references. 1 Answer
Instantiating a Coroutine? 2 Answers