General idea. Want to help develop? Want to be paid to help develop? about openvr-motioncompensation HOT 33 CLOSED

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

from openvr-motioncompensation.

@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?

from openvr-motioncompensation.

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

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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...

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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

from openvr-motioncompensation.

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

from openvr-motioncompensation.

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!

from openvr-motioncompensation.

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.)

from openvr-motioncompensation.

@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!

from openvr-motioncompensation.

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...

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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

from openvr-motioncompensation.

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

from openvr-motioncompensation.

@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).

from openvr-motioncompensation.

@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.

from openvr-motioncompensation.

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

Sorry, I probably missed something: Go your DCS cockpit inputs by way of your physical switches or by way of the virtual hands?

from openvr-motioncompensation.

Video link should be fixed. I agree with you both, as I said in the first message of my post I don't expect you to include this, I just wanted to mention it for conversations sake since we are basically branching OVRIE and it's OVRIE I'm using.

It would be much better to get Valve to add controls to their native tracker software to tweak the pose of the Tracker anyway.

Trip

J-1775 I'm not sure I understand the question. If you are unsure why I need OVRIE for this, I need it to adjust the pose so that my virtual hand in DCS is in the same position and orientation as my real hand.

from openvr-motioncompensation.

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

Sorry, I probably missed something: Go your DCS cockpit inputs by way of your physical switches or by way of the virtual hands?

It will be by way of the switches. Virtual hands are only to make it is to find the real switches.

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

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.

from openvr-motioncompensation.

Updates:

• @pottedmeat7 has put forth the first major PR #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.

from openvr-motioncompensation.

I have finally added 4-DOF from PT-Actuators (and also TL platform which I havent added). I tried the current iteration of OpenVR Input Emulator and zip tied one of my Vive Wand controllers to the back of my seat. I was getting some slight drifting in my headset, and the movement seemed a bit exaggerated. For example on Laguna Seca in iRacing on the new TCR cars, the view was moving correctly it seemed but it was moving way too much. going up the hill on that track and the view becomes so shifted that i could only see the dashboard of the car. Then going downwards on the carousel turn (which is a really sharp drop), i was blocked by the view of the roof of the car on the inside.

I used a temporary fix to get the vive wand attached to the seat through the 2 holes using zip ties. It seemed VERY tightly set on the back of the seat, next to the neck area. I have 3 base stations. 2 in corners of my room near the ceiling in front of the rig, and 1 behind in the corner/ceiling facing downwards which is looking directly onto the vive wand.

Was I doing something wrong or is motion compensation prone to drifting and exaggerated changes like that which can block my view?

from openvr-motioncompensation.

@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.

from openvr-motioncompensation.

I thought this community was taking over OpenVR Input Emulator to further make progress for Motion Compensation made by Matzman666. If so, are there any further updates on the software that was released by him or we're still trying to find someone willing to work further on it? If so, my comment was meant to find out if there's any progress towards the issue that I have been having with the last release from matzman666.

from openvr-motioncompensation.

@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.

from openvr-motioncompensation.

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.

from openvr-motioncompensation.