EditorXR and (new) Input System / input-prototype / XR Interaction Toolkit?

Version 0.3 of EditorXR comes with Editor/libs/input-prototype. Is that an old version of the new Input System that is now available as a Unity package via UPM? Or something else?

Also, how do EditorXR and the XR Interaction Toolkit (also from UPM) interact? It seems there are quite a few areas where both do the same thing, or similar things, but differently. In the recent blog posting it says that EditorXR will use customized controller models and interaction settings when they were set up using the XR Interaction Toolkit ... but how exactly does this work?

I have just spent a little while with EditorXR in Unity 2019.2.17, using Valve Index Controllers (weren't supported and showed Vive wands instead), Vive wands and Oculus Touch controllers (with the original Rift).

To be honest, I have very mixed feelings: On one hand, it does look like this might help a lot with a project I'm currently working on which is a content editor. On the other hand, things like Singlepass being broken (in 2020, where I believe most people have completely abandoned Multiplass ;-) ), or the lack of support for all relevant controller types (Valve Index, the various Windows MR controllers, the new Touch controllers, PS Move ;-) ) and using some very unusual UX conventions ("Blink" instead of "Teleport", putting it on a button instead of touchpad / joystick forward as is usual, and putting the spatial menu where teleport usually is) does scare me a little.

In this current project, I use SteamVR Input 2.0, which is awesome, and some hacky fallbacks for native Oculus support, and PSVR support. My main concern is having to deal with yet another input abstraction that does the same as Valve, just a little different (and maybe not quite as production ready, but also larger in scope).

 

Thank you for the update, this does sound promising! I know the troubles of working on old projects (we started developing Holodance in 2015 ;-) ). I may actually dive into EditorXR and send some PRs. If I understand the architecture correctly, it should be possible to add e.g. support for SteamVR Input 2.0 (without breaking support for the new Input System prototype ... but might be wise to coordinate with work being done on porting this to the new Input System by Unity), or also the SteamVR controller attach points to EditorXR controller abstraction bridge that I mentioned somewhere. I'm aware that the former is probably an area where the actual implementation doesn't perfectly match the idea but at least the second one should be comparatively straightforward.

I still have to look into Unity's new (XR) input system and whether or not it's compatible with the old VR plugins. I will stay on Unity 2019.3 and the old but properly working VR integrations until OpenVR is supported in the new XR Plugins and Systems approach, with full feature parity to what we currently have. In particular, I certainly won't give up SteamVR Input 2.0 or skeletal input, that stuff is just way too good to be replaced with something else ... and I would still love to see Unity collaborating more closely with Valve on getting the good stuff that Valve does natively into Unity instead of re-inventing the wheel and making it square.

The biggest issue for me with EditorXR, at the moment, is that Single Pass Stereo Rendering isn't supported because the project that I would integrate this into requires SPSR (not the instanced variant of it, just the "regular" one). I believe it's probably just one or two shaders that break - but my shader-fu is worse than drunken bar fighting, so that's not something I could fix easily. Also, I would primarily use EditorXR as a UI during runtime / in builds to edit proprietary content (i.e. not the scene). Scene editing is also interesting for our project but that's lower-priority / longer-term. So that recent blog posting was obviously what re-sparked my interest even though I was quite excited when EditorVR was first announced.

 

Could someone clarify the relationship between the New Input System and XR Input. Is there a road map for a unified input system in the works?

I've been experimenting a little with the XR Interaction Toolkit, and I like that it's got some support for uGUI, which I need. But, we support CAVEs and other projection displays that integrate separate (COTS) trackers and game controllers that aren't standard, well known VR systems (Oculus, OpenVR, WindowsMR, etc.). I need to figure out how to make the custom tracker/controller look like an XR InputDevice.

Is there anyway to bridge the new input system with the XR input system, if I can code the tracker interface?

 

Hi @Matt_D_work

Appreciate the feedback and looking forward to the XR Interaction Toolkit update. Got a rough idea when that might be?

I thought maybe I could create a proxy XR input device, but I don't see a way to do that without going the XR management / plugin route. Unfortunately, there's no Stereo non HMD plugin, and I'd like to stay on the managed side if I can.

 

That's great, thanks!

Not looking to hold anyone to a deadline. I've got lots of stuff I'm working on, so a rough schedule just helps me prioritize. It sounds like the new interface might help me out, so it's worth waiting a couple weeks and working on other stuff.

Really, I appreciate the feedback. Thank you.

 

@Matt_D_work

Did the IXRController interface make it in yet? I've checkout out 0.9.4 (07 Apr 2020) and I don't see it in there.
Just wondering.

 

@Matt_D_work

I'm also looking forward to this! Would love to have the new input system and xr-toolkit work together, or at least have a layer of abstraction (IXRController interface) to provide compatibility.

Is there a roadmap of this anywhere?

 

We also would appreciate this IXRController interface, hoping to write simulations that could work in both our cave and HMD's. We wrote code for that in the past, but it feels like inventing the wheel over and over again (We are building a new cave now). An abstraction layer would be of great value!