koobas.hobune.stream
Is it cheaper to deactivate a game object or change its alpha, or other?
Hi guys,
I am making a space shooter and want a simple optimization question. I have a pool of flame particles that trail behind the ships, and when a ship is destroyed, I'm wondering if it would be cheaper for me to se their alphas to 0 and let their animations continue, or just deactivate the game objects?
The ships themselves are also part of the field and get re-used, so they will keep the flame particles with them.
The question really is, is it cheaper to turn the alpha on and off of a bunch of objects, or to deactivate and reactivate a bunch of objects?
Or is there a third and better solution, ie, turning off the sprite renderer or some other option?
Thanks for your time
It would be better to deactivate the gameobjects because at start they will assign memory and according to your need you can enable and disable. If you destroy your gameobject then when you re-instantiate gameobject it will assign memory block again and during game running instantiating is bad way and sometimes it makes your gameplay leggy. so i think deactivating will be good technique.
i think the question was disable renderer vs SetActive, not SetActive vs Destroy/ instantiate
usually toggling specific components is cheaper than changing the state of the whole gameobject. the question is if you're die not to forget anything, especially scripts which can make use of OnEnable/ OnDisable.
I consider SetActive safer, but in cases of particles that should have their time to fade out, out either needs a delay or a separate particles object. otherwise they just get cut off.
but overall, it's easier to use the profiler to find out of it's even an issue.
ah ok. In this specific scenario I have a pool of particles. It was screweing up their animation when I deactivated them and tried to restart it all again, and was wondering whether it was a good idea just to turn the sprite renderer off and leave them being moved via their script, so that when I turn the renderer back on they will still be there.
But, that would mean I would be leaving it on for all of the space ships, as they will all be created as a pool at the start of the level and intended as a webGL game.
Destroying an object releases its memory, means it no longer uses any CPU time (since none of the Update() functions on its attached components will be called), but causes the garbage collector to have to reclaim the memory and, if you want to use it again, means it will have to be reinstantiated. Only use this for objects that you're certain you don't want to instantiate again.
Deactivating a gameobject keeps its memory allocated, but no longer uses any CPU time (Update() etc. on deactivated objects is not called), and creates no additional work for the garbage collector. Reactivating it is a trivial operation.
Disabling the sprite renderer keeps the object's memory allocated, and continues to use CPU time since Update() etc. will still get called, but doesn't cause any work for the renderer since nothing gets drawn to screen.
Setting alpha to zero continues to use all the memory, CPU, and rendering resources as normal - it's just you can't see the object. Transparent objects still generate just as much work for the rendering pipeline - it's just that at the point a pixel is drawn to the screen (normally at the very last step of the fragment shader), the blend mode means it has no influence on the final colour. I can't think of any situation where you'd want to do this.
Unless you have a very specific reason to keep your memory footprint to an absolute minimum, I'd recommend deactivating the object for the vast majority of cases.
Thanks so much for that insightful response! It's very helpful. Deactivating objects was causing other weird issues for me so I was hoping to find a way around it, but guess I'll just have to try and solve that. Thanks very much!
Does deactivating an object also deactivate it's components?
Update()/OnTriggerEnter() etc do not get called on an inactive object, and you can't grab a reference to an inactive object using Gameobject.Find(). But you can still explicitly call methods in components on a deactivated object if you already have a reference to them.
