Documentation

Unity Engine

User Manual

Script Reference

Unity Engine

Object

UnityEngine.Object is the base class for all objects the Editor can reference from fields in the Inspector window.
Read time 3 minutesLast updated 12 days ago
The 
UnityEngine.Object
class acts as a base class for all objects that Unity can reference in the Unity Editor. You can drag and drop classes that inherit from 
UnityEngine.Object
into fields in the Inspector, or pick them using the Object Picker next to an Object field.

An example of an Object Field in the Inspector window. The Object Picker is the circular icon to the right of the field.

Rather than inheriting directly from 
Object
for your own custom classes, it's often better to inherit from a class designed to be more specific to your goal. For example:
  • Inherit from 
    MonoBehaviour
    if you want to write a custom component which you can add to a 
    GameObject
    , to control what the 
    GameObject
    does or provide some functionality relating to it.
  • Inherit from 
    ScriptableObject
    if you want to create custom assets which can store serialized data.
Both of these inherit from 
UnityEngine.Object
but provide extra functionality to suit those purposes.
Note
UnityEngine.Object
is different from .NET's base 
System.Object
, which is not included in the default script template so that the names don't clash. You can still inherit from .NET's 
System.Object
if you want to create classes which you don't need to assign in the Inspector.
The 
Object
class provides methods for instantiating and destroying Objects and for finding references to Objects of a specific type. For more information on the API for the Object class, refer to the script reference page for Object.

Special behavior of UnityEngine.Object

UnityEngine.Object
is a special type of C# object in Unity, because it's linked to an unmanaged (C++) counterpart object. For example, when you use a Camera component, Unity stores the state of the Object on the Object's C++ counterpart, not on the C# Object itself.

Two containers side-by-side represent the unmanaged and managed layers of the Unity Engine. Each container has its own representation of UnityEngine.Object. Connecting lines between the two layers demonstrate the link between the managed Object instance and its unmanaged counterpart.

Unity doesn't currently support the use of the C# 
WeakReference
class with instances of 
UnityEngine.Object
. For this reason, you shouldn't use a 
WeakReference
to reference a loaded asset. Refer to Microsoft's WeakReference documentation for more information on the 
WeakReference
class.

Unity C# and Unity C++ share UnityEngine Objects

When you use a method such as Object.Destroy or Object.DestroyImmediate to destroy an object derived from 
UnityEngine.Object
, Unity destroys (unloads) the C++ counterpart object. You can't destroy the C# object with an explicit call, because the garbage collector manages the memory. Once there are no longer any references to the managed object, the garbage collector collects and destroys it.
If your application tries to access a destroyed 
UnityEngine.Object
again, Unity recreates the native counterpart object for most types. Two exceptions to this recreation behavior are MonoBehaviours and ScriptableObjects: Unity never reloads them once they have been destroyed.

Custom equality operators

For types that inherit from UnityEngine.Object, Unity uses a custom version of the C# equality and inequality operators. This means the null check 
myGameObject == null
can evaluate 
true
(and conversely 
myGameObject != null
can evaluate 
false
) even if 
myGameObject
technically holds a valid C# object reference. This happens in two cases:
  1. The object can be a so-called fake null or placeholder object which Unity uses in the Editor only to populate uninitialized MonoBehaviour fields. These objects store useful debugging information to help you locate the source of these fields if you try to reference them.
  2. The object can be a managed (C#) object which has not yet been garbage collected but which should be considered null because the unmanaged (C++) counterpart object has been destroyed.
Because you can't overload the 
??
and 
?.
operators, they aren't compatible with objects that derive from 
UnityEngine.Object
. The operators don't return the same results as the equality and inequality operators when you use them on a destroyed 
MonoBehaviour
or 
ScriptableObject
while the managed object still exists.

Additional resources