Construct Object from Class

At a glance

Creates: one runtime instance of a non-Actor UObject class · Returns: the selected class type (shown as Object until the Class pin is specific) — can be None · Outer: the new object's containment, naming, and context relationship — not Actor Owner · Does not provide: a world transform, component registration, viewport setup, replication, or automatic saving · Official page: Construct Object from Class

The one-minute version

• Use this node when you need a live instance of a plain UObject class: for example, a short-lived request model, an inventory item view-model, or project logic deliberately designed as a UObject instead of an Actor, Component, Widget, asset, or Struct.
• Class is a class reference, not an existing object. The node allocates a new instance initialized from that class's defaults and returns a reference to the new instance.
• The result pin specializes to a fixed Class choice. A class variable typed as a broad parent still produces an instance of its real runtime subclass, so class-specific work may require a Cast or a common parent/interface contract.
• Outer says which UObject contains this object in Unreal's object hierarchy. It contributes to the object's path/name and can provide context such as a World. It is not AActor::Owner, an Attachment Parent, an inventory owner, or proof that the result will stay alive.
• There is no Failed execution pin. A fixed invalid class is normally caught while compiling the Blueprint; a bad dynamic Class or unusable Outer can leave the Return Value invalid and may produce an engine diagnostic. Follow a dynamic construction with Is Valid before initialization.
• Store every object that must survive in a real object-reference variable or another reflected container. A temporary wire is not a lifetime plan, and Outer alone is not a substitute for a strong reference.

What it actually creates

UObject is Unreal's managed base object. Actors, Components, and Widgets eventually inherit from it, but those families need extra creation machinery. Construct Object from Class is the generic path for a class that needs none of that family-specific setup.

pseudocode of the useful contract — not engine source

validate Class and Outer
allocate one UObject instance of Class under Outer
copy the class-default property values into the new instance
apply exposed construction-pin values
return the live object reference

It creates an instance, not a new Blueprint class or Content Browser asset. Calling it twice with the same inputs creates two separate objects with separate mutable state.

It also does not call Actor lifecycle events. A plain UObject has no automatic BeginPlay, transform, collision, component registration, or ordinary Actor Tick. If the object needs runtime setup, give it an explicit function such as Initialize and call that after a valid return.

What exactly comes back?

The official page describes the output generically as an Object Reference. The Blueprint node is type-aware:

• choose BP_InventoryRowModel directly and the output pin becomes a BP_InventoryRowModel reference;
• feed a variable typed Object Class Reference and the declared output stays broad;
• at runtime the reference still points at the exact subclass selected by Class.

This is the same declared-versus-runtime distinction explained in the class hierarchy. The node does not copy an existing object and does not return the class default object (CDO).

Outer: the relationship the pin actually sets

Every UObject has an Outer chain. Read it as object containment/context:

PlayerController
└─ OptionsScreenModel          (Outer = PlayerController)
   └─ PendingKeyBinding        (Outer = OptionsScreenModel)

That relationship has several practical effects:

• Object path and name scope. Unreal gives the new object an automatically generated name within its Outer. The full path includes the Outer chain.
• Context lookup. UObject code may obtain services or a World through its Outer chain. Use an object from the intended play world when the class needs world-backed work, and verify the class has a usable GetWorld path.
• Grouping and teardown intent. Choosing the subsystem, controller, widget, or model that conceptually contains the object makes the hierarchy truthful and helps world teardown and object inspection make sense.

What Outer does not mean:

Relationship	What it controls	Is that the Outer pin?
UObject Outer	Containment, path/name scope, and possible context chain	Yes
Actor Owner	Networking relevance, owner-only visibility, and some remote procedure call permission	No
Component owning Actor	Component registration/lifecycle on one Actor	No — use a Component creation path
Attachment Parent	Transform hierarchy and sockets	No
Gameplay/data owner	Your project's authority to mutate an item or setting	Only if your design explicitly makes it so

Passing an Actor as Outer is allowed for an ordinary UObject; it still does not set that Actor's Owner property or attach anything to it. See Ownership and lifetime for the overloaded word "owner."

Outer is not a garbage-collection guarantee

Unreal's garbage collector (GC) keeps UObjects that remain reachable through tracked strong references. In Blueprint, an object-reference variable or an Array/Map property on a live UObject is the normal solution.

The safe pattern is therefore both:

1. choose an Outer that truthfully represents context/containment; and
2. store the returned reference on the system that needs the object.

Do not construct an object, leave it only on a temporary execution wire, and assume its Outer will preserve it indefinitely. Conversely, a stored strong reference can keep an object reachable longer than the gameplay relationship you intended, so clear model arrays and bindings when that relationship ends.

When construction fails (and what failure does)

Construct Object from Class has one execution output. It does not branch to a failure handler for you.

Input/problem	What you see	What to do
A fixed Actor, Component, abstract, or otherwise non-constructible Class	The class picker excludes it or Blueprint compilation reports the bad construction	Use the specialized factory or choose a concrete UObject class
A dynamic Class is None or resolves to a class that cannot be constructed	No usable object is produced; the Return Value is invalid and the engine may log a construction diagnostic	Validate the Class when it enters your system, then validate the result
Outer is None, stale, or already tearing down	There is no supported containing context for an ordinary success; construction can be rejected or the result can be unusable	Pass a known live Outer and stop creating children during teardown
Outer is valid but belongs to the wrong play-in-editor world	Construction may succeed, but later world-dependent work observes the wrong World	Derive Outer from the intended caller/player/world path
Your custom initialization rejects its inputs	Construction already succeeded; your Initialize function must report failure and release/clear the object	Give Initialize an explicit Boolean/result contract

A failed or unusable construction does not run a hidden recovery event. The single Out execution pin continues, so an immediate call on an unchecked None produces the usual Accessed None error. Use Is Valid whenever Class or Outer is data-driven.

For a fixed class and known live Outer, repeated defensive checks at every later use are noise. Validate once at construction, initialize once, store the typed reference, and let the owning system maintain that invariant.

The pattern everyone actually uses

Suppose an inventory component wants durable item objects for a virtualized ListView:

InventoryComponent receives plain replicated/saved item data
-> Construct Object from Class (Class = BP_ItemListModel, Outer = InventoryComponent)
-> Is Valid Return Value
-> Initialize(ItemId, Quantity, Icon, InventoryComponent)
-> Branch Initialize succeeded
-> Add object to ItemModels Array
-> Set List Items on the local ListView

The object is presentation/model state. The Inventory Component remains the authority for accepting Add/Remove/Equip requests. The item model can expose formatted local data and change notifications without becoming the inventory.

Initialize after construction

UObject constructors do not take arbitrary Blueprint arguments. Use one of these two deliberate paths:

• mark simple properties Expose on Spawn when they are safe independent assignments; or
• call one explicit Initialize function for values that must be validated together, bind delegates, or establish an invariant.

Prefer the explicit function when partial setup would be invalid:

Initialize(ItemId, Quantity, InventoryOwner) -> Success Boolean

reject invalid ItemId / Quantity <= 0 / missing InventoryOwner
copy validated values
bind once to InventoryOwner.OnInventoryChanged
return true

Do not put setup in an imagined UObject BeginPlay, and do not create fresh objects every Tick. Allocation, reference tracking, and later garbage collection are real work; construct on a lifecycle event and reuse the stored instance.

What the node does not provide

No Actor, Component, or Widget setup

• no World transform, collision, replication channel, Actor Owner, Instigator, construction script, BeginPlay, or EndPlay;
• no component owning Actor, registration, activation, attachment, or tick setup;
• no owning Local Player, widget tree initialization, input/focus route, or viewport membership.

Those are why the lookalike creation nodes exist.

No automatic asset or SaveGame record

The result lives in memory. It does not become a .uasset, appear in the Content Browser, or automatically serialize into a SaveGame slot. Save plain durable fields and reconstruct runtime helper objects after load unless your project deliberately implements a custom serialization layer.

For editor-authored shared definitions, use a Data Asset. For small copyable runtime data, a Struct is usually simpler.

No automatic network identity

Calling the node on the server creates a server-local UObject. Calling it on a client creates a different client-local UObject. Plain UObjects do not become replicated subobjects merely because their Outer is a replicated Actor.

Keep authoritative gameplay data on an appropriate replicated Actor or Actor Component, then build local helper/view-model objects from that state. Native projects can implement replicated subobjects intentionally, but that is a separate networking contract, not a feature of this node.

Lookalikes — which one do I want?

Need	Use	Why not Construct Object from Class?
A world entity with transform, collision, Actor lifecycle, or replication	Spawn Actor from Class	Plain UObjects do not live independently in a World
Reusable behavior/render/collision owned by one Actor	Add Component by Class (or an authored default component)	Components require an owning Actor and registration
A User Interface widget for one local player	Create Widget	Widgets need player/world context and widget initialization
Shared editor-authored read-mostly definitions	Data Asset	Runtime construction does not create a saved asset
Small copyable data with value semantics	Struct	A UObject adds identity, references, GC, and lifecycle complexity
Class defaults without a mutable instance	Get Class Defaults	Constructing an object only to read defaults allocates needless state
A plain runtime object with identity, functions, references, and explicit lifetime	Construct Object from Class	This is its actual lane

See Spawn Actor from Class, Add Component by Class, and Create Widget for the specialized paths.

The C++ twin

Original example code:

UItemListModel* Model = NewObject<UItemListModel>(
    InventoryComponent, ItemListModelClass);

if (IsValid(Model) && Model->Initialize(ItemId, Quantity, InventoryComponent))
{
    ItemModels.Add(Model); // UPROPERTY/TObjectPtr container keeps a strong reference.
}

The relevant difference is not Blueprint versus C++; both paths create a managed UObject. C++ makes the reference rule visible: a persistent owning field should be a reflected strong reference such as a UPROPERTY-tracked TObjectPtr.

Going deeper

• The gameplay class hierarchy — class references, real runtime subclasses, and Cast.
• Ownership and lifetime — UObject Outer, Actor Owner, component ownership, attachment, and garbage collection.
• Blueprint World Context — why a valid object can still lead to the wrong play world.
• Blueprint variables and references — strong stored references versus unassigned typed variables.
• Data Tables vs Data Assets and Structs, Enums, and Switch on Enum — when identity and UObject lifetime are unnecessary.
• Engine source (requires an installed source build; we do not reproduce it): UK2Node_GenericCreateObject::EarlyValidation and ExpandNode in Engine/Source/Editor/BlueprintGraph/Private/K2Node_GenericCreateObject.cpp; UKismetSystemLibrary::ConstructObjectFromClass in Engine/Source/Runtime/Engine/Private/KismetSystemLibrary.cpp; and NewObject in Engine/Source/Runtime/CoreUObject/Public/UObject/UObjectGlobals.h.