XR Input API or Input System Actions? I want to interface with a range of cross-platform inputs

Target Platforms XR
, , , , ,
1

I’m trying to figure out how to pull input data from Unity the right way, and I’m not too sure which is the preferred/suggested way to go about getting and reading XR input data:

  1. The InputDevices.GetDevices & device.TryGetFeatureValue(UnityEngine.XR.CommonUsages, out value) methods/structure that interfaces directly with the UnityEngine.XR.InputDevices API

  2. Reading from Input System’s Actions

Because the actions seems to all be available for all the supported feature groups that UnityEngine.XR.InputDevices would find also, and this page: Unity - Manual: XR input options says “You’ll probably want a combo”, yet I see both methods have separate Controller samples under the OpenXR package, and two types of TrackedPoseDriver, one for importing data from either method^. I’m just wondering, in your experience, is one more preferred for use over another?

I’m wanting as much info as I can, so thinking maybe leaning towards the XR Input APIs rather than the Input System Actions, but maybe the Actions are more supports by Unity updates? I’m not too sure…

2

Keep input gathering separate from input processing.

Make a data structure to contain all your possible input.

  • clear that data
  • gather the new input
  • process it

That way you can swap out step #2 above as much as you want, add to it, add an entire new kind of input, etc.

3

Sorry if it wasn’t clear, those aren’t sequential steps. Those are my two different options.

4

I don’t know your exact input needs and I would venture a guess that you don’t either, unless you have pre-defined 100% of your UX.

Thus when you write this:

… it isn’t something you can presently do.

The “right way” is axiomatically “the way that works best” and since ALL ways can work, there isn’t really an answer.

Moving forward, you can interleave your input gathering throughout your program and when you realize you want to switch to another way, you have to unwind and untangle it all.

Or you can do the approach I suggested, picking one of the two ways of input, moving forward to understanding and developing your specific UX, and if at the last minute you have to switch to another input source, it’s trivial to do because it is all in one blob of code.