General idea. Want to help develop? Want to be paid to help develop?

[rosskevin]

Summary

I have no idea what I'm doing in this realm but I am an experienced software developer and entrepreneur with plenty of experience in open source (check my profile).

I'm looking to put together, in any way possible, something stable for the community to use for all of us using SteamVR with motion compensation. Whether it is to try and organize several people to contribute, or to try and raise funds to pay someone, let's get this done.

Problem

The original OpenVR-InputEmulator project has been abandoned, and while the old compiled code is currently still working with the runtime, it is compiled against IVRControllerComponent which has been removed (in https://github.com/ValveSoftware/openvr/releases/tag/v1.0.12). At any time the SteamVR runtime can drop support because this api has been deprecated for quite some time, and everyone with motion simulators could no longer use their VR headsets with openvr/steamvr.

Concept

Reduce the surface area of the original code, limit it to motion compensation only and support this limited use case.

More than you might want to know

I am actively seeking to shrink the scope and get a minimal motion cancellation project maintained with up-to-date dependencies. If you are interested in:

• developing for pay
• developing for free
• contributing funds for a developer

to support this work, please comment or contact me via email to discuss. I am not looking to get paid, but I am looking to get the right people motivated to work on the project.

I'm an experienced developer but not with c++ for quite some time, and not with the ms tools or openvr libraries. It may be best for me to try and organize the project or pay to get the right people working on the project. @matzman666 is certainly welcome to contact me - I would love to collect support funds and pay him - but it seems like he is no longer active. Regardless, it is important functionality that many of us with motion simulators need.

Want to discuss?

Comment here or

• discord https://discord.gg/r7krmSd

[mikeymwonggmail]

I would like to support this as "contributing funds for a developer"

[rosskevin]

@pottedmeat7 or @r57zone both have projects on github and related experience. Would either of you be interested in contributing or being paid to work on this by the community?

[rosskevin]

I see @SuperEvenSteven did some similar work, any interest here or know of anyone I might contact?

[pottedmeat7]

Hello, I would be willing to help out. Might be a little busy with my day job. Also would take me some time to fully understand the requirements of a motion compensation system.

[TripRodriguez]

I have very low income, but having working motion compensation is critical to one of the things that matters most to me so I will definitely chip in what I can.

[apointner]

In! I would trust my Money to Noorbeast any time! Also i can offer to do testings for new Versions and Changes. @rosskevin I would like to extend the concept: Reduce the surface area of the original code, limit it to motion compensation only and support this limited use case FOR ALL MAJOR VR HMDs!
Or at least for all HMD using Lighthouse 1 and 2 Tracking

[TripRodriguez]

I guess you saw my other post as well eh? =)

What you suggest sounds very much like what @rosskevin suggested.

I know that making Oculus headsets work can be an issue because of those evil Facebook bastards and their closed ecosystem. I think the reasonable request would be "guaranteed" functionality for lighthouse (native SteamVR/OpenVR) systems, and "best effort" on making alternative equipment work. I say this only because asking too much often results in getting nothing at all.

By the way, this is absolutely the reason I went with Index. Native SteamVR/OpenVR equipment means almost guaranteed functionality for any working SteamVR plugins etc. I still want that Pimax 5K, but I had to play it safe.

[pottedmeat7]

I have less knowledge of motion compensation itself. However I would say one of the larger development issues with motion compensation, is that currently it's not natively supported by openvr.
Best solutions would be for some sort of direct support for modifying HMD poses. However I think that could be very complicated to do with support in openvr, as the driver system works now as isolated devices with access to tracking data. OpenVR supports that you can create any devices and create your own driver for it, say a new HMD, but there isn't really a way,a supported way, to alter that driver outside the driver itself.
I don't know if it would be fruitful to contact the openvr developers, but the they did help with support with the input API to allow support for an extra input device, kind of a third hand. Which greatly improved support for my project and I'm sure helped allow development of other treadmill devices as inputs.
Other solutions may involve a bit more ingenuity or some reverse engineering to get solid supported motion compensation. What I'm not sure about is the process to recreate a manufacturers OpenVR driver completely, which may be possible but could be quite a task...

[TripRodriguez]

Might you look at the OVRIE functionality and see how that goes about modifying the HMD pose? You should be able to install it and fiddle with it even if you want, just set one controller as the motion compensation device and move it around with your hand.

[rosskevin]

Thanks for that explanation @pottedmeat7. With this codebase, is it possible to replace the IVRControlledComponent with the new IVRDriverInput or is there something missing?

We are looking to drop all extraneous functionality - input mapping etc, we only need to support selecting the reference device, the algorithms applied, and try to supply the manipulation through IVRDriverInput instead of IVRControlledComponent - unless I'm misunderstanding.

Please correct any misunderstanding I have - I've just started researching it (and collecting links in the wiki).

@JoeLudwig if you would be willing to advise or confirm the proper course of action, I would very much appreciate your opinion.

[rosskevin]

I've created a gitter room to chat in and discuss https://gitter.im/OpenVR-MotionCompensation/community#

[rosskevin]

@pottedmeat7 - fyi have been collecting points of interest in the wiki https://github.com/rosskevin/OpenVR-MotionCompensation/wiki/Background-issues-commits

[J-1775]

Very good idea, thanks. I'm a (soon to be) user of OVRIE and unfortunately can't contribute much apart from money and maybe some ideas. But count me in when it comes to that!

[JoeLudwig]

OpenVR Input Emulator and it's ilk (basically anything that hooks vrserver to intercept calls from other drivers) cause many, many crashes on end user machines. They prevent the driver back-compatibility code in vrserver from working properly whenever changes are made to the driver interface. Then they cause vrserver to crash in ways that users don't tend to understand. If you hear someone complaining about "safe mode" in SteamVR it's almost always because of one of these drivers.

I strongly suggest that you come up with some way to accomplish these goals without taking that approach. Many of the tools you need are likely already present in the input system. What are you missing?

See also ValveSoftware/openvr#1153 (which I'm working on a fix for.)

[TripRodriguez]

@JoeLudwig Thank you for joining the conversation. Though I have been using OVRIE for quite some time and only once had a short stretch where I was getting crashes your point is well taken.

It seems you have significant knowledge of the system. Do you understand what it is that we require? I'll try to give a very brief explanation just in case you are coming in from outside without knowledge of the problem:

We need to subtract the movements of the motion simulator from the movements of the HMD and controllers so that the head and hand tracking is relative to the moving cockpit rather than relative to the real world. This must be done on all 6 DOF, three positional axes, and three rotational axes.

OVRIE works for many of us, but as a general rule we are unable to use our bass shaker systems because the vibration confuses the tracking on the device we are using to measure the movements of the motion simulator.

Do you have any suggestions on how this could be tackled using the "tools already present" that you mentioned?

If you have any questions please ask!

[pottedmeat7]

Hi @JoeLudwig what motion compensation needs is the pose updates.
However this needs pose updates for the HMD device.
I don't believe there is currently any other way to support direct pose control without recreating the HMD driver completely or by using hooks.
Maybe because these are just the openvr drivers there would be a way to get the source and create modified versions of them...
Unless there could be added support to openvr to have a way to modify poses of active devices within another driver...

[ilimo]

I'm mainly a VR sim-racer and will be adding motion to my rig soon. I have been reading about the motion cancellation stuff for a while and I'm a real noob at this stuff, but I would GLADLY donate to have a dev work on it and get a working system for motion rigs and for motion cancellation.

[JADsterr]

↑↑↑ Me too,
Just voicing my support as a future user and willing to contribute a fee.

[TripRodriguez]

I don't mean to throw a wrench into the works, and I totally understand you aren't going to change the scope of the project just for me but tonight I had a very very successful proof of concept test that requires the OVRIE functionality for swapping controllers and setting offsets. Going forward, I'm really going to need that functionality for my sim unless Valve adds the ability to fully customize the tracker offset in their software.

Here is a (REALLY CRAPPY!) video. Don't mind the mess around the sim, parts, sawdust, and tools everywhere.... For this video to really be worth anything I'd need to have captured the gameplay to put up side by side. I'll try to get that done later in the week. For the first bit of the video you can (just barely) see the monitor in the background so you can see my DCS hand.

Explanation: For several years on and off I've been trying to find a satisfactory solution to using VR in a full simulator cockpit. I find that my immersion is completely ruined by having to fumble blindly to find the buttons and switches that are right in front of me because I can't see my hands.

In this video, I have the beginning of my Huey sim cockpit, an (unfinished) complete forward console. I'm wearing the VR headset thorughout the video. I have used OVRIE to have a tracker attached to my hand emulate an Index controller, and I've used the OVRIE offsets functionality to get my hands orientation and position matched up pretty precisely.

The hand is not animated at all, but the 3D model is in a pretty standard relaxed hand pose so it's easy to just relax my hand so it matches. I have aligned the real switches and knobs so that when I put the middle knuckle of my VIRTUAL index finger on the right side of the switch or knob the same joint of the same REAL finger is in the same place.

In the video I demonstrate how quickly and accurately I can find my knobs and switches. It's very satisfactory. Now the only problem is I have to worry about OVRIE getting broken. =(

https://youtu.be/lFVy-YkQq7U

[rosskevin]

@TripRodriguez that sounds very cool - your video is unavailable for me in the U.S..

That is not within the scope of motion compensation as you mention and it is not something I would support expanding this project into. It is important for the maintainability of any piece of software (especially open source) to remain in-scope and heavily used for it's designated purpose - otherwise it may easily be dropped as a burden. While we have some pledged financial support, such support is not a full time equivalent and depends very much on the good will of any developer to continue supporting. So it is very important that we make it a pleasure (as much as possible) for the right developers to contribute.

OVRIE was very ambitious in scope, and I believe that is one reason why it was interesting and developed at first, then subsequently abandoned.

As such, I support the creation of an OpenVR contrib or extras or ? github organization to collect these purpose built projects, but I definitely want to reduce each project to a minimal amount of code for the designated purpose. If any particular project fails, I wouldn't want to see all of them fail (or fall into disrepair).

[pottedmeat7]

@TripRodriguez I agree with @rosskevin . If you require modifications to controller poses, or controller input, it is much more flexible to create simulated input or simulated poses with a another driver devoted to that purpose. Think of another device that renders two hands where your index controllers are, and can supply any input that you'd like.
This would be much more stable as a separate project, and is fully supported by openvr's input API.
Its better not to mix an issue that could be succeeded separately, then be merged within a more complex motion compensation solution.

[rosskevin]

Let's keep this issue on topic to keep information and attention on motion compensation. Some people cc'd here get a lot of notifications, let's hope they stay engaged and don't ignore due to off topic messages. Please feel free to to use discord or I can create a separate channel on request.

[RadSteve]

Hi @JoeLudwig!
Thanks for joining this conversation.
We would need a openvr_driver API that allows us to override or modify another tracked device's pose from within our own custom drivers.

That would allow for so many useful applications:

• MotionCompensation for Racing Seats - Would allow to counterbalance the seats lateral and angular offset.
• MotionCompensation for Omnidirectional Treadmills (e.g. OmniDeck) - Would allow to zero out the users lateral offset from the center of the device.
• Z-Scaling for Seated Locomotion Devices (e.g. Cybershoes) - Would allow to calibrate the HMD to standing height while scaling down the virtual height to be able to reach the floor.
• HMD authority for Seated Locomotion Devices (e.g. 3D Rudder) - Would allow to rotate the HMD natively.

[peroht]

Personally I like the idea of having a compensation mechanism.

However, I think that overriding the intended/default values originating from official drivers will lead to much headache, for developers and users alike. The history of matzman666 project speaks to this scenario with multiple devices/software breaking without any warning or heads up.

Would it not be better to just use the Input system as it is basically architected to allow for this scenario? A user would then have a proper "motion compensation device" in a driver, which is able to take input from any controller/action and then output the compensation as a new action. The user would then bind to the compensated data/action in the intended application. This way users would clearly know that it is compensated data that they are using.

Consider the "motion compensation device" to be analogues to a derived class where the base class is whatever openvr officially supports.

Personally I'd not be too happy if someone did motion compensation on the Omnideck by all of a sudded making the hardware run 3 times faster while maintaining the in game speed - causing a major discrepancy between the physical and virtual speed.

[rosskevin]

Updates:

• @pottedmeat7 has put forth the first major PR Mass prune #6 to prune code unrelated to motion compensation and I'm working with him to get it verified/merged (other technical reviews/help welcome)
• I have moved the repository to the openvrmc organization as a better signal that this will be a community owned project

I have had trouble building/testing due to work constraints, so if there are other technical users that can review/build/test it will be a welcome role to help @pottedmeat7 verify changes.

[rosskevin]

@ilimo we have not put out a release and this is not a support channel for past releases from a different repository. You might chat with others on discord to see if you can get help.

Please keep focus on the issue topic.

[rosskevin]

@ilimo - your comment was a personal support request for something we did not release. Github is a for developers, we focus on the issue defined by the subject General idea. Want to help develop? Want to be paid to help develop?. Even if we accepted user support issues, it should be a separate (new) issue - do not tack your situation onto another - this is not a user forum. If we had user updates, they would be listed on https://github.com/openvrmc/OpenVR-MotionCompensation. As is mentioned explicitly on the main page DO NOT USE THIS OR EXPECT ANYTHING AS A USER.

When we have updates for the general user community, you will see them on the main page. Feel free to watch but this issue is targeted at gathering developer support, please don't create additional noise here.

[rosskevin]

I'm going to close this issue now.

• @pottedmeat7 is putting forth development effort
• we will be moving forward towards a release (hopefully)
• there is nothing to release at this time, please watch releases at the top, check periodically or check the #announcements channel on discord.

If you would like to create a PR, be a maintainer, or chip in with technical work (must be able to create your own builds and hopefully test), please connect with us on https://discord.gg/r7krmSd #development.

For other issues/discussions/research, please open a new dedicated issue on a well defined topic.