I made some changes in the default SteamVR module. I don’t know if (or when) Epics approve my pull request, and this fix is important for developers using my Vive Mocap plugin, so I’d like to publish it here as a patch.
List of changes:
bug fix: crash at the engine startup with 4+ Vive Trackers
bug fix: with 3+ Vive Trackers: any input event from the left motion controller cause crash
bug fix: Steam_Generic_Trigger, Steam_Generic_Touchpad, Steam_Generic_Grip, Steam_Generic_Menu events for Vive Trackers declared, but not initialized
bug fix: bad mapping of Vive Trackers to EControllerHand after turning off and on one of the trackers (multiple trackers could be mapped to the same Special_N key)
Make a backup copy of the [Program Files\Epic Games\UE_[engine version]\Engine\Plugins\Runtime\Steam\SteamVR] folder!
Copy with replace [SteamVR] folder from the archive to [Program Files\Epic Games\UE_[engine version]\Engine\Plugins\Runtime\Steam]
Important! Input from Vive Trackers doesn’t work with SteamVR Beta (v1.0.15). I can’t fix it via SteamVR plugin only, because it’s necessary to add support for the lastest OpenVR SDK (Engine\Source\ThirdParty\OpenVR) and to add actions manifest file which would affect all UE4 projects and the Editor itself.
So, this also works while using multiple Trackers? with 8 I’m still using 4.16.2, so if this works with 4.18.3 without crashes, well my friend, I owe you a beer
Added: 4.19.0 Preview 5 version. Was tested with 4 and 6 trackers.
By the way. Unfortunately, I don’t see a plans for controllers input unification in the UE4 Roadmap. Does anybody interested in a patch for a whole VR system refactoring with unificated input from SteamVR and Oculus controllers (i.e. Touch, Vive wands and Knuckles) and support of discrete input from different Vive Trackers? My idea is to put this input to event deletages and functions inside of Motion Controller Component and send them from VR plugins via IMotionController/XRMotionControllerBase interface.
I wouldn’t worry about input refactoring if I were you, OpenVR just overhauled input entirely in the .10 and .11 versions, so its likely that anything you change will get changed anyway by Epic when they start porting over to newer OpenVR binaries.
Also your input idea kind of breaks the intended input methodology of the engine, not really sure that is a good idea, better to leave the inputs as global events.
Edit They also upped the number of max tracked devices I believe in OpenVR .11
It’s not a good solution IMO. It requires a special set of events for every new tracked object. Motion Controller (R) Trigger, Motion Controller (L) Trigger, Motion Controller (Special 1) Trigger, Special 2, Special 3 and up to Special 11. And the same for grip, touchpad, fingers, face buttons. With new tracked devices from new VR companies they’ll need more then hundred of events.
And developers using Knuckles and Oculus Touch need to duplicate input handling for different systems which goes against the idea of unification.
You are still going to need separate global events unless you lock all input notifications to the motion controller component, which is pretty terrible. You can also use events as Actions instead of button events and just rebind the calling button (ie: action_grip, rebind as trigger / grip based on platform). There is also some attempts at the SDK level to abstract input and the XR layer should end up handling it in the end.
Better to keep the global inputs but with a “tracked device ID” attached to it and the capability of setting input events tied to a specific id.
Regardless 12 trackers all adding button inputs is a use case that isn’t ever going to be needed except by extreme outliers, who can re-factor input themselves to accommodate for it.
Edit Even if you move input into the controllers, how are you going to keep it from bloating there too? You’ll have it easier in device by device events, but now you still have to support Oculus specific inputs and Knuckles capacitive inputs and other manufacturer input events. It still ends up being a platform by platform configuration, except with less flexibility since you don’t have re-binding and have the un-used events sitting in there.
Don’t get me wrong, current input is a mess and far from ideal, but I’m not sure that is the solution.
Idea to prodive a full support for some input devices and incomplete support for absolutely similar devices is werid.
VR-plugins could be responsible for binding their custom button events to unified keys.
ed. To be clear: For me it’s more or less theoretical discussion, I don’t have any plans like this. But I do think that tons of events - wrong solution.
Yes, the input key structure would just have to have an id given, possibly a secondary list for tracked devices to not bloat the primary one.
You are talking about up to 14 input devices at once, that is as far outside of standard requirements as you are going to get.
It would almost be better to support trackers specifically in a component like that.
Which is what they currently do…just with some per plugin overlap that can be fixed up.
Edit Dunno, its a mixed bag when dealing with something like this, but I wouldn’t want all input events routed through the motion controllers for the controllers themselves.
Not 14 devices. All vive trackers now generate the same events and devs can’t separate input from first and second tracker. Unreal supports - in theory - 11 trackers, developers I know use up to 8 (some probably more, I don’t know), but there is no separate input from trackers at all. If I understand you correctly, you suggest to add events for a reasonable number of trackers. But it’s kinda weird to have events for tracker #3 and don’t have events for #4.
No, I suggested either a dedicated component for the dedicated hardware or an extension to the global input mappings to handle arrays of tracked device inputs.
Just not routing all tracked device input events through a component base, would make Player controller / character input handling really unwieldy.
It could also be done with dynamic mapping to events.
Is this known/expected? Does the patch only fix the Editor crash, or is it supposed to also prevent the too-many-vive-trackers crash in a build version, too?
Is it normal that if I run the project in the editor on 4.18.3 everything works as expected, with no crashes, but if I package the project and try to run it, as soon as the 5th tracker is enabled it crashes again?
So frustrating…please tell me that there is a solution for this
Thanks for the reply, infact it just works in-editor, but I’ve recently upgraded a project from 4.16 ( where even in the packaged project there is no crash ) to 4.18.3, and I had a really bad surprise when I tested everything, mostly because I’m doing a tech demo for a potential customer, and the crash makes the entire upgrade worthless…also because I can’t switch to 4.19 right now due to plugin compatibility, so I’m stuck with 4.18.3 or going back to 4.16, but doing half of the job again.
It would be possible for you to compile also the 4.18.3 version dlls? I would try to do that by myself, but I’m not that familiar with coding
Download UE4 sources and copy my fixed SteamVR plugin there (or just SteamVRController.cpp file), also, if you want to use it later with launcher version, copy EngineVersion.h from the launcher version sources to custom sources folder. Then package in non-editor configurations.
Upd. And don’t copy Binaries/Win64/UE4Editor.modules file to the launcher version of the engine. It’s important.
Thanks for the quick update, glad to receive those advices
Can you clarify what you mean about “package in non-editor configurations”?
I usually just build for win64 leaving all the options by default ( except for the Start in VR ), so I’m not sure if I’m doing something wrong, or if the crash happens no matter what.
Anyway I’m waiting for a reply for the plugin I’m using for 4.19, and since you already answered to another person that it does work with 4.19, I can just update the project to 4.19 and everything will be good to go ( hopefully ).
