I’m making a VR game with XR Interaction Toolkit (3.0.7), and I want to move the player over to a new scene along with all items they are holding. Seemed like it should be simple to do, but I’ve run into so many problems with seemingly no good solutions that I’m assuming the problem is with my usage of XRIT.
Since interactions are managed by the XR Interaction Manager (duh), I assumed that I’d want to move the existing manager over to the new scene as well, since I’d otherwise have to manually reinstate the player’s interactions after switching scenes. However, this ended up not working, as any existing interactable in the new scene would fail to find a manager upon being awoken and would create one. This meant that there would be two managers in the new scene after the old one was moved over, and all interactables in the scene would be paired to the new manager while the player was still paired to the old one and therefore weren’t able to interact with anything in the scene.
I’ve also been running into a problem where any Ul interactions from the previous scene (Specifically the Ul button that switches scenes when pressed) would cause the player’s near-far interactor to get stuck selecting the UI element that now doesn’t exist anymore, blocking the interactor from being used .
I can think of solutions to the first issue, but all of them rely on manually reinstating interactions, which is a lot of extra work for something I don’t imagine should be much work. The second issue I’m not as sure how to fix, although I assume it is also caused by the interaction manager, so maybe it would be fixed for free by fixing the first problem.
Hey @ExR-torm,
We have seen both problems you have outlined. For the InteractionManager issue, we have seen this as well and a few other developers have run into it. We have been looking into a way to support existing functionality, but introducing a way to treat the InteractionManager as a singleton which does not get destroyed on load. To handle the case where a scene is loaded with an existing interaction manager, we would transfer the registered interaction objects and remove the extra manager. We feel like this is how most people want to use the framework.
It was built the way it was so that objects and interactors could be paired together to save on processing time, or by scene. For example, RayInteractor could be paired with distant objects, DirectInteractor with nearby GrabInteractables, or gaze interactor could be paired with interactables that are intended to respond only to eye-based interactions. Those are admittedly more complex use-cases which make it more difficult to develop for the simpler/standard use-cases.
In any case, we are looking to move the FindOrCreate call in the XRBaseInteractable class out of Awake so that it doesn’t trigger this unwanted behavior. There is still value in having it auto-find the primary interaction manager in the scene since objects loaded in get registered for interaction. @BlackPete called this out in a recent thread as well, so we are looking at options.
As for the UI issue you are seeing, this was supposed to be fixed in XRI 3.0.6, so we will look into it and make sure a fix goes out in the next release. Thank you for bringing it to our attention.
2 Likes
I love the idea of making the Interaction Manager into a singleton. I can’t think of a reason why I’d want to have multiple instances of it.
Trying to group things by near vs distant vs whatever object also sounds like it’s just asking for trouble. A distant object likely isn’t going to stay distant as you move closer to it. Who’s responsible for moving that object into another group then? I feel like this is stuff that’s better solved using interaction layers.
Right now it’s too easy to have wires get crossed between interactables and interaction managers. That’s been largely solved by keeping the interaction manager in a persistent scene that’s always loaded and additive scenes are always loaded and unloaded afterwards. However we devs still run into trouble sometimes when we just play in editor without having the persistent scene loaded first and made the active scene. This also doesn’t handle the case of unloading a scene with an interactable that’s still being selected/grabbed/etc.