Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice

Feature Request Does a Destroy()ed rigidbody carry out preloaded instructions?

Discussion in 'Documentation' started by benjmitch, Feb 24, 2023.

  1. benjmitch

    benjmitch

    Joined:
    Nov 27, 2019
    Posts:
    17
    If a GameObject has a rigidbody component, and in FixedUpdate that component has MovePosition() called on it, and then Destroy(), does the MovePosition() take effect before the Destroy()? My understanding is that it does, based on how my system is behaving, but the documentation says only:

    "The object obj is destroyed immediately after the current Update loop"

    https://docs.unity3d.com/ScriptReference/Object.Destroy.html

    It would be helpful if the documentation were clearer on this issue. "Update loop" is ambiguous, isn't it? Or is that term defined somewhere? Does that mean "the current one of FixedUpdate()/Update()/LateUpdate()"? Or "the next Update()"? When I google (Unity "update loop") I get my first hit on the most likely page to have a definition, perhaps:

    https://docs.unity3d.com/Manual/ExecutionOrder.html

    but it has a definition only of the "Animation Update Loop". This page:

    https://gamedevbeginner.com/how-to-destroy-an-object-in-unity/

    suggests that "update loop" might mean "the current one of FixedUpdate()/Update()/LateUpdate()", but even if that's the answer, that still leaves open the question of what exactly "after" means. "After" the user code? Or "after" every part of the *Update() set? Or something else?

    I realise this won't usually matter much, but I've now met one case, at least, where it does.

    Cheers
     
  2. halley

    halley

    Joined:
    Aug 26, 2013
    Posts:
    1,959
    Instead of pondering the nature of undocumented internals, how about measuring? Throw some
    Debug.Log()
    wherever you think you need to know. If you ever open up the Profiler, you can zoom into the order in which everything flows to a pretty high degree. You will get a better understanding of the overall loop and structure of the Unity engine's master loop.

    The only situation I think the life and death of a Rigidbody vs other parts of the master loop might be in collisions. If the Rigidbody dies mid-collision, it will have to invoke OnCollisionExit behaviours. If you muck with a Rigidbody position, it will only transfer the new position to Transform.position at the end of physics processing.
     
  3. benjmitch

    benjmitch

    Joined:
    Nov 27, 2019
    Posts:
    17
    @halley - Thanks, but I'm not asking about internal behaviour, I'm asking about how a GameObject moves under the described condition (MovePosition(), then Destroy(), within the same frame). I can debug to determine a particular case, but I presume there is a general rule that determines when components are destroyed, and that's what I'd like to understand - and see documented. When is destruction actually executed, and do components (including rigidbodies) continue to play their normal roles (such as moving GameObjects) right up until that point. I'm guessing the answer to the latter is yes, in which case the question is just exactly when destruction occurs.

    I agree that the profiler gives plenty of insight, but I'm not aware of a way to determine when a particular component is destroyed using it, and I'm sure I couldn't determine if MovePosition() had taken effect using it, and in any case I can't see that it would be straightforward to determine a general rule from this approach, given the number of variables.

    Presumably there is a simple enough rule, and it would be helpful (to me, at least) to have a statement of it, is all :).
     
    Last edited: Feb 27, 2023
  4. SF_FrankvHoof

    SF_FrankvHoof

    Joined:
    Apr 1, 2022
    Posts:
    780
    That's a great presumption.
    I'd also presume that it could be dependent on WHEN you call for it to be destroyed (e.g. in Start() vs in OnPreRender()).
    So again: Log it. Easiest & quickest way to find out.
     
    halley likes this.