Search Unity

GameObject.Setactive(false) or if(Gameobject.activeinhier...SetActive(false)

Discussion in 'Scripting' started by BadSeedProductions, Sep 18, 2020.

  1. BadSeedProductions

    BadSeedProductions

    Joined:
    Dec 26, 2014
    Posts:
    144
    Is there any reason to use an if statement here (assuming not required by any other circumstances)? Is one method considered correct of the following? Is it a case of good practice or is there a functional reason to use one over the other?


    Code (CSharp):
    1. gameObject.SetActive(false);
    2.  
    3. //or
    4.  
    5. if(gameObject.activeInHeirarchy){
    6. gameObject.SetActive(false);
    7. }
     
  2. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,911
    They're just different things...

    The first one will deactivate the object no matter what.

    The second one will deactivate the object only if it's currently active in the hierarchy. Note that the object may itself be marked as active, but it may be currently considered deactivated because one of its ancestors in the hierarchy is deactivated. (See also: gameObject.activeSelf).
     
    MrUndead and BadSeedProductions like this.
  3. BadSeedProductions

    BadSeedProductions

    Joined:
    Dec 26, 2014
    Posts:
    144
    So if "not required by any other circumstances" including that for example the game object has no parent, then is there a reason to use one over the other? (for example could deactivating a game object that is already deactivated take more draw calls than reading the if statement first?, or on the flipside would it take more to read an if statement first rather than just directly deactivate it)

    If there is no downside to deactivating a deactivated object then I suppose my answer would be not to use the if statement.
     
  4. PraetorBlue

    PraetorBlue

    Joined:
    Dec 13, 2012
    Posts:
    7,911
    Deactivating an already deactivated object won't do anything. It's basically a no-op.
    • If the object has no parent, or all of its parents are already active, deactivating the already deactivated object will do absolutely nothing (other than waste a handful of CPU cycles).
    • If the object does have a parent that was already deactivated, then calling SetActive(false) will only set the activeSelf flag on the object to false. That means that if the parent were to be activated, this object would not be activated along with its parent.
    There would certainly not be any effect on draw calls in one case over the other. The only way you could affect draw calls here is if you are actually activating or deactivating the object and thereby adding or removing its renderer from the workload.

    If you look at Unity's game loop you can see that the "Game Logic" section and the "Scene rendering" section are isolated from one another. Rendering only cares about the final effective state of the scene at the end of the Game Logic section. It doesn't care if you took 50 steps to get to that state or 51 steps to get to that state. The effect on rendering will be the same.

    If your object has no parent and you therefore don't expect activeInHierarchy and activeSelf to be different for any reason, there's not really any good reason to check activeInHierarchy before deactivating the object.
     
    BadSeedProductions likes this.
  5. BadSeedProductions

    BadSeedProductions

    Joined:
    Dec 26, 2014
    Posts:
    144
    @PraetorBlue Thanks for the further explanation.

    I had also not realized the difference between activeInHierarchy and activeSelf
    which activeSelf would have been better fit for my question, but answered nonetheless thanks!