I am curious about the reasons and background behind adopting the current design structure for the interaction part of XRI (XR Interaction Toolkit).
In the current XRI, the main flow is implemented in the InteractionManager class, and the Interactor and Interactable cannot function independently—they are dependent on this flow. In particular, actions that change states such as hover and select are also implemented in the InteractionManager, and the Interactor and Interactable only implement what should happen when the state changes. Because of this structure, assigning an Interactable to an Interactor is also carried out primarily by the InteractionManager.
I would like to ask what reasons and background led to adopting this design structure.
and i also want to ask about Definition of the “Interaction” concept and the resulting structural differences.
I’m curious how this SDKs define “Interaction” as a conceptual unit.
How did this way of defining “Interaction” influence the implementation of Interactors and Interactables, and what do you see as the core differences?
I understand that there is no single “correct answer” in design. The design structure adopted by XRI must have had both advantages and disadvantages, so I would like to know which factors led you to judge that this structure was more beneficial. Additionally, I would like to ask how you defined the responsibilities, authority, and roles of each class, and how you defined the concept of “interaction,” and how that definition influenced the design structure.
Thank you for taking the time to read this long message, and I hope you have a great day.
I truly want to understand this topic clearly. I would be very grateful for your help.
please help me unity…T.T
i really want to know this…
Hey @airkdrpdyd3,
Sorry for the long delay in getting back to you on this, but hopefully this will satisfy some of your curiosity. As a disclaimer, this is mostly my personal interpretation and experience from my time working on this package at Unity.
I can say that a lot of the design decisions came from folks on our team building similar systems in their past experiences, plus learnings from past Unity explorations such as EditorXR or Slices. We also built many of the components based on some initial foundational needs for interaction in XR that the Input Manager and new Input System just didn’t have at the time. Some of these were driven by the needs of some internal projects and prototypes that needed to behave in a specific way, such as the XR Design Framework that was showcased at SIGGRAPH in 2022.
So to jump right into the first question about the Interaction Manager class. We chose this approach and continue to support it because we needed a way to handle conflict resolution between multiple Interactors and interactables and reason about their state and priority. This also had to be done without each interactor or interactable having to know about every other part of the system or context. Using a manager pattern also allows us to control the processing loop and order of operations when dealing with input, interactions and physics, which in turn drives resolution of interaction states of each object participating. The Interaction Manager is key to ensuring the correct order of operations, especially when it comes to parenting interactors to interactables (such as sockets on a hand-held interactable) so that objects higher in the tree are processed before the children. This is done to ensure any movement or updates are done in the correct order and removes frame delays on updates in cases where the object transforms may not be directly parented to the interaction parent transforms.
As for the definition of Interaction, that’s definitely a bit more ambiguous. I guess we would define it in more concrete terms, so something like “a system in which objects can influence or change the state of other objects or each other.” This is how I personally would represent our interpretation of the term, but we add constraints to what objects (interactors) can directly influence the state of another object (interactable), where those objects (interactables) in turn indirectly influence the state of the original object (interactor). I think we stick to these foundational elements to keep the concepts and implementation details simpler for developers to grasp. It starts to get messy when you don’t have rules about what can/can’t influence other objects in a scene and much harder to optimize the processing of all the potential interactions. I wasn’t around for the inception of the XR Interaction Toolkit, so I am unsure if there was a definition of interaction that influenced the design more than the concepts that were built, but there was definitely an element of a natural human-to-object interaction. I am not as familiar with the Meta iSDK, but the core concepts I would say are roughly equivalent
In terms of your last question around design and what classes are responsible for different things, I think a lot of the decision making around how we continue to build things now are different than when the project first started. We now look at the needs of projects and input-related use-cases to drive a lot of ongoing feature development. The authority of certain parts of the system are well-established at this point, but sometimes it comes down to modularity of code and a lot of internal discussions and technical design. There are many moving parts within the Unity Editor and the way things like UI, input or physics can shape where and how we determine interaction and logical decision making by the different components. We try to keep concerns separated where it might make sense, or build in abstractions where we see flexibility in the engine, such as with UI or input frameworks or even different input modalities.
I hope this helps understand XRI a little bit better.