koobas.hobune.stream
Is there a performance gain by checking if an object is active
if (remObjs[i].activeInHierarchy) { remObjs[i].SetActive(false); }
Similar to this code. I'm trying to figure out if unity already has a check to see if the gameobject is active before I set it active again and maybe cause a bunch of extra code to be run.
Activating an object calls OnEnable on the $$anonymous$$onoBehaviours attached, so I guess you can test this pretty easy. Try activating an already active gameObject and see if OnEnable is called again, or deactivating an already inactive gameObject and see if OnDisable is called twice.
I'm pretty sure it doesn't, but haven't tested that myself. I'm assu$$anonymous$$g Unity already checks if the state changes.
Also, note that "activeInHierarchy" and SetActive(true/flase) mean different things. activeInHierarchy can be false even if the object is active (if any parent is inactive). Also, SetActive(true) on an object that's not activeInHierarchy because of a parent being inactive won't make it active in hierachy (but will activate itself) and OnEnable will probably not be called. $$anonymous$$aybe you want to use isActive ins$$anonymous$$d of activeInHierarchy.
if (!remObjs[i].activeInHierarchy){
remObjs[i].SetActive(true);
}
I think I was a little unclear on this, say for example the object is active in hierarchy and I call SetActive(false) then the game object goes inactive no problem.
But if the object isn't activeInHierarchy and it's not activeself then does calling SetActive(false) incur a performance hit?
Is it better to make sure it's already active before setting it inactive, or is it better to set it inactive even if it's already inactive. That's the performance I'm concerned with.
Also Unity has deprecated isActive so we can't use that going forward.
No, there's nothing to worry about if you deactivated an deactivated object again or if you activate an already activaed object.
Im most cases however it's to consider if you can simply avoid a frequent updating of objects. You should rely more on events instead on polling a certain state if possible.
As a side note: activating a deactivated object or deactivating an active object can have quite a performance hit. However it depends on what components it has attached. In general activating / deactivating physics objects (objects with rigidbody / collider) is quite heavy. If you "pool" physics objects you might consider to just disable the renderer and move it far out where it doesn't hit anything until you need them again.
Also keep in mind when checking "activeInHierarchy" before activating an object doesn't really make much sense. The current "active setting" of an object should be read with activeSelf. activeSelf directly corresponds to the active state of the object itself. So if activeSelf is false and you call SetActive(true) it is guaranteed that activeSelf is now true. This might not hold true for activeInHierarchy if a parent is also deactivated. So a child can be activated but is still deactivated due to the "active state inheritance".
