SUNROCK: SteamVR Knuckles Support for UE4

[RuneBerg]

@mordentral

That is a much better approach than prior, grats! It was very bloated with all of the extra controller setup before.

You don’t need to directly load the .dlls though anymore (in your modules primary source file), that is legacy behavior that they never switched away from back in an earlier version of steam that conflicted with the OpenVR module, you can directly reference it now just by calling into.

vr::IVRInput * VRInput = (vr::IVRInput*)vr::VR_GetGenericInterface(vr::IVRInput_Version, &Initerror);

As long as your include pathway for your module points to the new OpenVR.h source and not the engines than it should all work fine without conflicts (as of three or four engine versions ago I think, they just never updated the in engine module to change that).

I would also suggest that you stop naming everything knuckles too, for instance the finger splay values aren’t used for knuckles controllers and are there to future proof for controllers later on, also there may be multiple controllers that return the finger curl values in the near future. Its a generic input system from steam, not a knuckles specific one.

Throwing the curl / splay events as seperate input events also may be a bit overkill, considering that they generally are used in some combination or another and there is some overhead pushing all of those each tick to the graph. It also makes it more difficult to gather them together, maybe add an accessor to the function library that just returns the arrays? Then they also won’t be polled unless needed.

I was holding off on doing something like this as really all that the engine needs is the static skeletal actions to be added to the manifest…but that doesn’t appear to be happening. I’ll point people to your input device module to work with my skeletal controllers, there really shouldn’t be multiple versions of the same thing floating around if possible and I think that this newest version is good enough to not require any other methods.

Good work, this will save me a ton of time doing the same thing, I have a ton on my plate and appreciate not having to duplicate effort.

Hi Mordentral!

Thanks for the feedback and input, will take them on board.

This is the first iteration to “professionalise” the plugin for general public consumption as it’s now apparent that in-engine support won’t be coming in anytime soon, so am really glad to hear that you are on-board with the archi, I’ve mulled over a couple of designs taking into account possible future moves by both Epic and Valve along with expediency requirements, this I felt is a good “middle ground” and hopefully future proofs it a bit.

Need to profile the curls and splays as it is one of my concerns as well on the current implementation, I think I have a todo tacked on that bit of code actually. Agree on making the naming more generic as well, it’s a bit of a balancing act at the moment to ensure any naming won’t clash with whatever Epic is planning - I tried to stay as close as possible to traces of support in 4.21, even calling them “Grips”, but may need to diverge at some point based on direction of SteamVR.

Glad to have more devs playing with it and providing feedback/bugs/etc and certainly PRs directly to the code would be awesome.

Cheers from Down Under,
Rune.