Develop

Pointer Events in Interaction SDK

Updated: Apr 15, 2026

The interactions managed by the Interaction SDK follow a unified Pointer Lifecycle contract. The contract defines states for interactions and the order in which they can be traversed. This unified contract enables Pointer handlers to work with multiple interaction types without being coupled to specific implementations.

For example, a UIsdkGrabbableComponent is a Pointer handler. It consumes a set of Pointer updates from an Interactable and produces a transformation change on an object. Because Ray, Poke, and Grab interactions all adhere to the Pointer Lifecycle contract, UIsdkGrabbableComponent can work with any of them.

What is a Pointer Event?

The Pointer Lifecycle is fulfilled by a set of Pointer Event objects. Despite their name, Pointer Event objects aren’t events. Instead, they are payloads that represent the result of an interaction. Each Pointer Event object consists of the following:

Item	Description
Identifier	A unique integer that identifies which interactor in the scene triggered the interaction.
Type	One of the following types of events: Hover, Unhover, Select, Unselect, Move, and Cancel.
Pose	A data structure that provides the 3D coordinates and the orientation, or rotation, of the interaction point (ex. the grab point on an object or the poke point on a surface).
Interactor	A reference to the interactor - in the form of a `USceneComponent` - that initiated the interaction.
Interactable	A reference to the interactable - in the form of an `IIsdkIPointable` - being interacted with.

How do Pointer Events work?

An IIsdkIPointable broadcasts a set of Pointer Events every time it changes state. To enable your application to react to these events, you can bind to the pointer event delegate for the interactable.

In C++:

if (IsValid(Pointable.GetObject()))
{
    Pointable.GetInterface()->GetInteractionPointerEventDelegate().AddUniqueDynamic(
        this, &UIsdkPointerEventAudioPlayer::HandlePointerEvent);
}

...

void UIsdkPointerEventAudioPlayer::HandlePointerEvent(const FIsdkInteractionPointerEvent& PointerEvent)
{
    UAudioComponent* AudioToPlay = nullptr;
    switch (PointerEvent.Type)
    {
        case EIsdkPointerEventType::Hover:
            AudioToPlay = HoverAudio;
            break;
        case EIsdkPointerEventType::Unhover:
            AudioToPlay = UnhoverAudio;
            break;
        case EIsdkPointerEventType::Select:
            AudioToPlay = SelectAudio;
            break;
        case EIsdkPointerEventType::Unselect:
            AudioToPlay = UnselectAudio;
            break;
        case EIsdkPointerEventType::Move:
            AudioToPlay = MoveAudio;
            break;
        case EIsdkPointerEventType::Cancel:
            AudioToPlay = CancelAudio;
            break;
    }

    if (IsValid(AudioToPlay))
    {
        AudioToPlay->Play();
    }
}

in Blueprint:

Pointer Lifecycle

An IIsdkIPointable must adhere to the Pointer Lifecycle contract. This contract defines the order of events the IIsdkIPointable can broadcast in order to transition a Pointer through three conceptual states. For more details, see Interaction Lifecycle.

None <-> Hovering <-> Selecting

Any Pointer must start with a Hover event (transitioning from None to Hovering).

Any Pointer must end with an Unhover event (transitions to None).

A Select event transitions a Hovering Pointer to a Selecting state.

While Selecting, no Select or Unhover events may occur.

From a Selecting state, an Unselect must occur to transition back to a Hovering state.

Any number of Move events can occur during Hovering or Selecting states.

A Cancel event may occur once during Hovering or Selecting states. If in a Selecting state, it must be followed by an Unselect and then by an Unhover.