Interactor Class

The implications of this are complex, and depending on or modifying this value is not recommended.

This is the TInteractable with which this interactor can, but may not yet have begun to, interact. The candidate is primarily used by the interactor itself (as the thing it knows it can interact with next) and by containing interactor groups, which frequently use the availability or unavailability of a candidate in a given frame to assess which interactors should perform the interactions of which they're capable.

This may or may not be the same as the Candidate

This must be the same as Interactable, and neither SelectedInteractable nor Interactable will change value until this interactor unselects.

In terms of InteractorState, this occurs when the interactor begins hovering a new interactable.

In terms of InteractorState, this occurs when the interactor ceases hovering an interactable.

In terms of InteractorState, this occurs when the interactor begins selecting a new interactable.

In terms of InteractorState, this occurs when the interactor ceases selecting an interactable.

ComputeCandidate is part of the core processing flow of IInteractors and is the primary way that individual interactors decide what they want to interact with. Computing a new candidate does not actually do the interaction because not all interaction candidates will result in interactions: an InteractorGroup might decide that one interactor's candidate cannot be acted upon because another interactor in the group is already interacting, for example. Managing this nuance, and the state associated with it, is why direct calls to methods like IInteractor.Hover cannot safely be used to force an interactor into a desired state, as attempting to do so violates the interactor's processing flow and may cause it to have invalid internal state. SetComputeCandidateOverride, however, can serve a similar function by arbitrarily controlling candidate discovery in the interactor. In this way, while an interactor still cannot be generally forced to interact with a specific candidate, it can be forced to consider a specific candidate within its proper processing flow, which unless prevented (by an intervening InteractorGroup, for example) can be made to result in the desired interaction.

This is called when the interactor force releases an interactable.

For similar reasons to those discussed in the documentation for SetComputeCandidateOverride(Func<TInteractable>, bool), an interactor cannot be directly forced to select an interactable (except in special, bespoke methods such as HandGrab.HandGrabInteractor.ForceSelect(HandGrab.HandGrabInteractable, bool)), but the logic it uses to decide whether or not to select can be overriden so that its normal processing is guaranteed to result in selection (again, absent intervening forces such as an InteractorGroup).

This is called when the interactor force releases an interactable.

See SetComputeShouldSelectOverride(Func<bool>, bool) for relevant details

This is called when the interactor unselects an interactable.

Runs before Process and Postprocess. This method should never be invoked directly except by either this interactor instance itself or the InteractorGroup to which it belongs.

Runs after Preprocess but before Postprocess. Can be called multiple times per interaction frame, with the number capped by the value of MaxIterationsPerFrame. This method should never be invoked directly except by either this interactor instance itself or the InteractorGroup to which it belongs.

Runs after both Preprocess and Process. This method should never be invoked directly except by either this interactor instance itself or the InteractorGroup to which it belongs.

Called when an interactable is currently selected or hovered but a PointerEvent of type PointerEventType.Cancel occurs.

Despite its name, this method is not a part of the interactor processing flow alongside ShouldSelect and Select; both of those refer to things that respectively should and do happen now, as part of processing. CanSelect does not specifically test whether or not an interactable can be selected right now; for example, a grab interactor can only select interactables that are spatially nearby, but proximity is not taken into account at all by CanSelect. Rather, CanSelect assesses whether an interactable can be selected more generally, such as whether there are any special rules which should prevent the selection even if every other condition were satisfied. InteractableFilters are the primary form such selection-blocking rules take, but descendent classes can introduce any other type of selection blocker they wish by overriding CanSelect.

This method should never be invoked directly by anything other than this instance (when IsRootDriver is true) or the IUpdateDriver serving the role of root driver. This method encapsulates the entire processing flow of the interactor, invoking many of the core methods from IInteractor (Enable, Process, etc.) in the correct order and with the appropriate state management. Modification to or deviation from this flow very fundamentally changes how interactors work and is likely to result in undefined behavior. Consequently, neither directly invoking nor overriding this method is recommended.

This method exists to support Interaction SDK's dependency injection pattern and is not needed for typical Unity Editor-based usage.

This method exists to support Interaction SDK's dependency injection pattern and is not needed for typical Unity Editor-based usage.

This method exists to support Interaction SDK's dependency injection pattern and is not needed for typical Unity Editor-based usage.

This method exists to support Interaction SDK's dependency injection pattern and is not needed for typical Unity Editor-based usage.