Some SteamVR games (most notable Valves own) have single actions instead of left/right hand specific actions in the SteamVR binding UI. These inputs have the ability to detect which hand fired them and keep track of multiple overlapping activations of the same input, for example having a single Grab action that lets you grab independently with both the left and right hand. This helps reduce clutter in the user facing binding interface, so it would be nice if it was supported in UE4.
From my experiments, there are a number of issues with implementing this in UE4. First, there is no runtime agnostic way of reading which hand or controller triggered the action, so there is no sure way of routing the input to the right logic. It’s possible to manually call the SteamVR Input API in OpenVR to find out the device, but that doesn’t work with other runtimes and it’s not integrated into the UE4 XR system.
Second, when an action is triggered, it can not detect other keys being pressed until the first key has been unpressed. This seems to be by design, so AFAIK the only way around it short of redesigning the action system, would be to separate the 1:1 mapping between XR inputs and UE4 actions.
Does anyone have any ideas on ways to get this working? This is not only relevant to SteamVR, but also to OpenXR if/when SteamVR or other runtimes starts supporting user bindings.
You should use interface to pass hand reference across all object, so you will know which hand are interacting. For the input, you should disable consume input so that the first input can not block the other.
Unless I’m missing something, neither of those things would help here. There seems to be no way to get the hand enum or motion controller ID from the action event, so it’s not possible to filter out events that are meant for the specific hand, apart from doing manual string parsing on the key parameter. Turning off the Consume Input option does not seem to have any effect on allowing multiple keys to fire the the same action concurrently.
This seems to be a limitation in the design of the XR and action systems stemming from them not having been used for any first-party VR games. If Epic were to release a polished VR game using the new systems, they would have to iron out issues like this first.
From your experiment, so are you new to game dev? You can check ue4 template for vr to know how they do it. Dont expect yourself so high, as the problems you are facing are very basic. We are developing game with ue, not some kid running around and crying about ue4 dont have this, ue4 dont have that. The problem is yourself, not ue oke? Your comment really made me crazy. Make a hand master class, make 2 childs class of it and name it right hand, left hand. Make an interface, make a function call grab object, make a var call hand ref there. So whenever you interact with object, call that function interface and pass the hand that is interacting.
The action binding key is 1 action - how many keys you want to do the action. It just like key binding for multiple hmd platforms, and some controllers always consume input so that it will block the other key unless the first key release(valve index, vive). So disable input consume is the way to make it work.
Ah sorry, I probably wasn’t clear enough with my problem formulation.
I can get everything working just fine when set up as separate handed actions as with the VR Template. This is more about getting the data needed to the master blueprint in the first place.
This is more about reducing clutter in the SteamVR binding interface and having a nice abstract interface for action events. Having to make separate actions for the left and right hands makes it harder for users to bind inputs in the SteamVR UI, and you get a lot of duplicated nodes in the blueprints that handle input.
As an example I’d like to be able to have a grab input set up like this:
Instead of this:
With a lot of optional inputs you end up with lists like this in the binding UI.
](filedata/fetch?id=1866739&d=1614437653)
With OpenXR starting to get deployed and the responsibility of binding inputs to the hardware shifting to the runtime, having a good working abstraction for the inputs is becoming more and more important.
Reading through the code for the input system, the code at Engine\Source\Runtime\Engine\Private\UserInterface\PlayerInput.cpp:1194 is set up to block firing events on multiple overlapping key presses if the event listens for both presses and releases. Testing it with events fired in Blueprint, it works just like that, adding connections to both the Pressed and Released outputs (even if you add multiple nodes for the same action in the blueprint) will cause only the first key press to register. This seems to be intended behavior.
I guess it might be possible to work around by writing a class that sets up multiple InputComponents that only register delegates either for the Pressed or Released events, but that seems to be a lot of work for a subpar solution that might break other things.