koobas.hobune.stream
Is Instantiating bullets/many objects always bad for performance?
I'm trying to understand exactly what it is about Instantiating many objects that gives the performance hit that is often mentioned here. Is it increased drawcalls, the loading/creation of each new object instance, or a performance limitation of the function itself, what exactly? I can't find detailed information about this and I would like to understand at least some of the key circumstances when to avoid Instantiation? I've only found two optimization videos from Unite which discuss Instantiation, but they don't actually explain why it can be bad for performance only that it is.
In my specific case I am firing projectiles from a weapon. The fire rate is quite fast (up to 1200 rounds per minute) with each round/bullet getting destroyed either upon impact or after a certain time, if it hasn't hit anything. I've tested the weapons in my scene firing at and above the maximum rate and with as many as 100 rounds at a time, but I haven't noticed a drop in performance at all. The frame rate is quite stable; and since my bullets are only empty gameobjects with a simple trail, most of them get batched giving no significant draw call increase either. So I'm confused as to whether in my case I should still try to avoid using Instantiation and attempt the less straight forward pooling solution?
Yes, it is always bad for performance and should be avoided in all but exceptional circumstances. The actual process of instantiation in Unity is slow due the allocation and construction of the game object and components and all of the .NET reflection happening with the serialization of attached components to get their settings copied. I'm guessing a bullet doesn't have many scripts and hence deals with it better than an enemy would in your case. In any circumstance there is likely to be a Garbage Collection after instantiation etc etc Avoiding instantiation has nothing to do with the number of draw calls.
You should have those bullets instantiated and invisible (actually I'm kinda surprised you actually model the projectiles anyway with such a rapid firing weapon), then activate them when you need them, because even if it is fast enough on your test rig it might not be on someone else's computer, it would be a dog on a phone. Really you are also wasting ms that could be improving your AI or adding some really visible effects.
You really should try to ensure that nothing gets instantiated at run time. If you really have an unavoidable case you need to minimise the number of components attached to the thing you are instantiating and add new ones after its built (because that doesn't serialize any fields).
When you fire tracer it's every "n" rounds normally right?
I should add that instantiating things with meshes is particularly costly due to the creation and upload of the new meshes/textures etc.
@Hamish, FWIW my lengthy how-to explanation, http://answers.unity3d.com/questions/321762/how-to-assign-variable-to-a-prefabs-child.html which I relentlessly promote as I now aim for THIRTY ticks on a question! :)
Also buy all the "pool" products on the asset store to experiment.
incidentally @whydo Something I always struggle with philosophically is, should you have a pool for each thingy (bullets, tanks, superbullets, megabullets, spaceships) or should you have one general purpose pool for - everything.
iI realise this question often has a specific-situation answer (eg .. "in fact, both items in question are just 2dT$$anonymous$$ sprites so it comes down to how long the T$$anonymous$$ routines take to swap one of those.." sort of thing)
But I've always wanted to know in life .. I just want someone really experienced to say to me "Oh, everyone does _ as a rule."
For me it's one of the greatest unanswered questions in let's say "standard" video game engineering
All video game projects, everything, line one, is a pool - and that's a basic question about them! Heh!
PS I keep secretly hoping you'll look at my Arcane Unityscript questions :)
http://answers.unity3d.com/questions/445535/class-test-extends-systemobject-copy-or-reference.html
Ah another point @Hamish when you have bullets specifically, I often struggle with whether it's best to disable them in some way (SetActive(false) in U4) or just sit the buggers offscreen. I feel it's fair to say both approaches are popular in say everyday side shooters. Of course you can and should test performance but it's an interesting general question. (If you are just learning about pooling, definitely just deactivate them.)
And finally there is the issue of how many bullets in your pool. Again I want some "universal" solution to this. Stuff I have done ..
during development, carefully analytic the max bullets ever used by test players, come to some conclusion
a "dynamic number" system where as end users play, it is aware of any times the pool count is exceeded, and self-modifies itself there and then and for future uses of the app
use essentially a list not an array and let it grow bigger if the max is touched
also what to do if the max is reached, with bullets i just erase the old ones, with spaceships maybe not
Thanks a lot for that detailed answer Whydoidoit. I did actually say that my rounds are empty gameobjects so the only mesh part would be the trail, either a particle or line renderer. I would consider modelling a simple bullet for slow motion effects, but that's about it. So it looks like I'm going to have go through my code and change all the Destroy and Instantiate lines to more appropriate things. Thanks again, really helpful
Would just like to add, I also found this answer particularly useful:
http://answers.unity3d.com/questions/196413/gameobject-pool-to-avoid-performance-issues-in-ins.html
