OpenVR OMNI Overlay

SkaarahSkaarah Posts: 35
edited September 2017 in HTC Vive
Hey guys. I am working on an OpenVR overlay to hopefully set some custom drivers and overrides to make more VR games compatible with the OMNI. My first goal is to use the OMNI to offset the standing position in the playspace. So far I have gotten it to change the position but the function I used doesn't seem to like updating as frequently as I need it to and causes the the playspace to freak out and bounce all over the place. Ideally I would like to have OMNI SDK access so I can add/modify the input modes (Gamepad/Keyboard). I'll be setting up a GitHub repo sometime this week. If anyone has any suggestions for functions to checkout in the OpenVR API that would be greatly appreciated.


  • Fan47Fan47 Posts: 25
    I have some development experience, I’d be interested in working with you on this once the repo is up.
  • SkaarahSkaarah Posts: 35
    edited November 2017
    I'm almost ready to open the repo. The current state of the project is for testing with pavlov. I took some things out of the notorious Input Emulator and I have successfully replaced the touchpad movement with my own inputs. By next week I hope to be able to walk around in pavlov using the omni. The next step will be making the overlay program so we can choose what input is replaced using the omni. Theoretically I think we can override the position of the vive itself but thats a test for a later date.

    Once I get the build steps readable I'll let you know.
  • JoeJoe Posts: 178
    @Evol FYI this sounds promising and along the lines of what I was attempting.sounds like Sakarah is having more luck than me so I’ll defer for now
  • This will essentially be my first open source project. After I open the repo should we get a discord goin so we can communicate easier? I'm certain theres a lot of things I'll have to explain/have explained to me.
  • JoeJoe Posts: 178
    I’m down for helping however I can. I had hooked into directinput and had that working, was about to wrap the input emulator in a full so I could bring it up to c# (I’m just faster making UI in a manged code). I got stuck trying to get openvrinput emulators command line’d hang for me. Evol came up with a tool chain using openvrinputemulator, freepie, and hydra drivers to get things working. He also has a list of games that work, and has debugged to find that unreal is throwing fits with his setup.

    Let me know what I can do to help/test etc. I have an Occulus based setup.
  • Yeah I tried the freepie route one night and the setup is so convoluted so I gave up. I'd rather have a native driver anyway. But I'd be down to have a c# overlay program to pipe configs to the driver.
  • If you want to be in charge of the overlay that'd be great. One problem I ran into with openvrinputemulator is the dependencies were horrendus. Could research/test making a c# program show up as an overlay program? This way we can change what inputs we want to override without exiting steamVR. That would be my next task after getting the omni to override at all. I almost got it tonight but now I'm just crashing steamVR.
  • JoeJoe Posts: 178
    I could take a look and see, never made a steam vr overlay. I agree freepie is not useful...I’m actually past that using the directinput method. So I see our software + openvrinputemulator as the solution currently.

    Do you have a drop of your solution for the openvr part? That’s where I got stuck...the console would hang on me so I was never confident I had that part working
  • Actually I'm only using openvinputemulator as a reference. I'm writing my driver from scratch but it does a few things similar. I'll open up my repo and put a link plus what I think are the build steps.
  • JoeJoe Posts: 178
    Ooooh!!!! Ok that’s clever and even more awesome, though we’d take a dependency on behavior in the current drivers...if they change you’d have to update your code
  • The link to the repo is
    I have added openVR and SubHook as submodules. You'll need to activate both of those after cloning. I use source tree which makes this really easy.
    Once you have subhook you need to build it using cmake. I'm a cmake novice so I used the gui and opened the solution to build release versions of the x64 dll.
    Copy the the lib and dll to submodules/subhoo/build/Release.
    After that you should be able to compile the driver.
  • Joe said:

    if they change you’d have to update your code

    Same thing would happen in openvrinputemulator. But at least I can read my code. ;)

  • x64 btw
    I haven't done **** for 32
  • JoeJoe Posts: 178
    edited December 2017
    thanks, good instructions, I got openvr hooked in via source tree (that's pretty slick, hadn't done that before!). Got subhook going, and was able to build a dll. Going to read through source and study up on the openvr sdk so I get how to use this. I won't be able to work on it much till next week, but in the mean time my dev environments up and running now and I can browse what you've done. Now that I see your approach I get what you're doing...and I like it. MUCH better than the openvrinputemulator approach I'd gotten it confused with (going openVR should make this really resilient..I believe)
  • Will you try adding a new c# project and try getting it to show up in steam overlay as an openVR overlay program?
  • JoeJoe Posts: 178
    Yeah I’ll look into it. I’m not clear on this feature though...wouldn’t you always (or 99%) want the Omni to emulate the thumb sticks? If there is per game customization wouldn’t having ini files be easier and cleaner? People could then share them. I’m wondering how much people will be in Vegas and decide they want to change what walking forward on the Omni does. Just trying to understand the vision. I’ll check out how the inputemulator made his work and such in the meantime
  • Eventually I would like to have game based profiles but everything should be configurable without leaving vr. In fact its pretty silly that OMNI Connect doesn't have an overlay program too. Maybe they will release information about that soon.
  • Oh I meant to ask the other night but how did you initialize directInput without a window?
  • JoeJoe Posts: 178
    C# with slimdx for init. When I’m home I’ll get you the code
  • EVOLEVOL Posts: 194
    edited December 2017
    I've almost finished going through all 101 pages of VR games on steam, compiling the list of possible games. I passed out at my computer several nights doing so... I've had to take a break. I got a TPCast and spent some days getting it fine tuned and installing OpenTPCast. I also got a second Vive on Black Friday and setup that up as well.

    I just want to say this is awesome I hope you both get this going. I completely agree that being able to modify everything inside a SteamVR overlay is the best solution. I have talked to the developer of OpenVR-InputEmulator he said that a FreePIE integration was the best option that he would be doing anytime soon. Though that may be months away or longer. I really hope you two get this going, good luck!
  • Thanks for the support EVOL. To be fair I probably won't have a anything fully playable for any less then a month either.
    I haven't tested it yet but I was going forward with XInput because Ive never initialized directInput from a dll. But I don't even know if the OMNI shows up for XInput anyway. I'd rather use directInput so that I can ensure that the inputs are coming from the omni.
  • EVOLEVOL Posts: 194
    If you get it working with XInput we could use FreePIE or possibly x360ce to convert the Omni DirectInput to Xinput. Obviously it would be better if it had DirectInput support natively though.
  • x360ce is a decent worst case scenario
  • Alright guys! I've made some progress. First off I figured out what was crashing steamVR. Apparently the vtable addressing can be the same even if the driver pointers are different. Which meant I was overriding an already hooked function. This is bad new for those who want to keep openvrInputEmulator because that is hooking the same functions too. But maybe there was some recursion or something happening. Secondly I successfully was moving around in pavlov using a 360 controller! The only caveat is that it requires you to hold down the trackpad. So it's apparently only updating the axis when that 'button' is down. So now I have to also hook into buttons but that shouldn't be too hard.
  • SkaarahSkaarah Posts: 35
    edited December 2017
    If you want to try it out for yourself youll have to change the deviceSerialToOverride string with the serial of the device you want to override and recompile the dll. Until we get the overlay program or until I setup some config file this is how it has to be done. Maybe I'll just go ahead and start setting up the config file for yall.
  • Well the button events didn't do it. Now I'm really unsure of what to do. I wish we could get the openvrInputemulator guy in here.
  • EVOLEVOL Posts: 194
    edited December 2017
    Ill see if I can get him interested he had mentioned not knowing a XInput driver to use maybe since you have made progress with that he will help you out.
  • EVOLEVOL Posts: 194
    Maybe this is helpful.. This guy is sending Vive wand controls to keyboard, the code looks pretty simple...
  • JoeJoe Posts: 178
    Please go a config file route. I can Frontend that no problem in c# and we can look at overlays afterward. From my research to overlay in steamVR I’d have to go raw c++ UI or bring in something like QT which is a heavy dependency. Your codes already small and clean, it’s be nice to keep that
  • EVOL said:

    looks pretty simple

    Unfortunatly, going the other way is significantly less simple. My current hypothesis is that I have to intercept all events / inject events even before the TrackedDeviceAxisUpdated is called.
    Joe said:

    raw c++ UI

    That is also unfortunate. I'll look into a lightweight c++ GUI. I would hate to have a QT dependency. That **** is way too big.

    Lastly I was wondering. Did the subhook submodule show up for you Joe? I checked out the project on a different computer and for some reason it isn't there. Not sure where that could have gotten splinched.
Sign In or Register to comment.