Object Pooling Implementation

I had originally posted this as a question in Unity Answers but it may be better suited for a discussion format.

I’m curious about people’s implementations of object pooling, particularly activating and deactivating objects. In the pooling section of the Unity manual they seem to advocate moving the object offscreen (to position (-999.99,-999.99,-999.99) or somethign) and disabling the key component on the object.

It seems to me that it would be better to simply use GameObject.setActive(false). What is the standard way of doing this and what are the drawbacks of either approach?

That’s interesting they recommended that. I would think setActive(false) would be better.

By default our in-house pooling code activates and deactivates the object. I personally feel that moving the object off-screen is a hack and not the “proper” way of doing things, but then again… if it works, then it’s correct!

You can use the OnEnable() and OnDisable() messages to call a Reset() function or whatever else you need to do.

There are some issues relating to de/re-activating objects; physics joints get reset, for example.

So since I posted this I’ve started implementing this via setActive(false/true) and I’m not really seeing the perforamce increases that I hoped for. It seems like calling setActive on an object is about as expensive as instantiating it but this may just be because of my unique situation.

I’m doing a 2d infinite runner so I have large modular pieces that contain a lot of children so maybe having to activate all of the children is slowing me down? Also I do have to move the piece to the correct postion before activating it so maybe it’s that function that’s slowing me down?

I think tonight I’ll reimplement it and instead of deactivating the gameObject I will disable the component and the renderer.

I agree that moing the object off screen seems hacky and I much prefer the completeness of deactivating it. Good tip on the OnEnable and OnDisable it’s very helpful for instantiate code that I used ot have in the Start function.

I will usually activate/deactivate, but from experience I’ve seen a few performance hits doing that with complicated physics and render components.

In particular, it seems that activating a renderer will sometimes cause some very expensive operation to do with texture caching on the GPU. It’s possible that’s only an issue in the editor.

I found another thread that touches this topic http://forum.unity3d.com/threads/191247-Object-Pooling-w-gameObject-setActive()-vs-Instantiate()

based on that OP’s results it seems as if disabling individual components and moving the object offscreen may indeed be more performant than deactivating/activating gameobjects. Again, I’ll have to try it before I know for sure.

The point of pooling within Unity is primarily around avoiding the GC, which is where the noticeable gains will be made.

Sure the speed of Instantiant/SetActive may be the same, but that’s irrelevant, because the speed of those two functions are not where unity (mono) fails.

Personally, I use setActive, then move them to a location below my terrain.

Just another thing to look for… Are you activating static colliders? I had a major stutter problem when activating static scaled mesh colliders as the Physics engine had to recalculate a ton of stuff.

I’m not directly activating static colliders but I am activating objects with children that have mesh colliders so I guess the answer is yes.