![]() ![]() Allowing users to use their own webcams for tracking keeps the prices low while still giving people the opportunity to improve their tracking, or even opt for a higher quality webcam for even better tracking. People seem to forget that if they added a camera elsewhere on the HMD it would most likely have to be identical to the ones in the front, which means it would make the device bulkier, heavier, and more expensive. Another problem would be the polling or framerate of the webcam, if it were low it would cause jittery tracking. There is some documentation for other VR controllers but I can't seem to find any for the index controller. These programs require that key bindings be set to button mask numbers. This style of tracking would get better and better with time as you gather more data, but if the camera moves or play space changes, the calibration would be lost. Hello, I'm new to the Index and am trying to get some OpenVR programs working with the index controllers (Input Emulator, play space mover, ECT.). Then when those controllers are in the same place but not in view of the HMD, they can still be tracked because we saved the positioning data from earlier. If the controllers are in view of the HMD, then the webcam knows exactly where the controller is and that data can be saved. A webcam could track the controllers and triangulate their position by comparing itself to the HMD's tracking. Thinking about it, additional cameras on the headset really aren't necessary. Not the best solution as we will lose the inside-out tracking but for testing purposes this will suffice for now. If I'm understanding correctly as long as we can keep using the gyro/accelerometer inside the controller and override the positional tracking using Open VR's tracking overrides I'm fairly certain this is possible within SteamVR. ![]() It's possible that through some combination of OpenVR and OpenVR-Input-Emulator this might be circumvented but it probably also means losing the excellent tracking WMR provides when tracking state is in "High Accuracy". If anyone has any other ideas in how to accomplish this please contribute. Microsoft will need to give some accesible API to hook into various calls and events within the positional tracking system for WMR. This would require four wiimotes with two ir leds attached to each of the WMR controllers. There was also work done by Johnny Lee several years ago to accomplish this same task. The wiimote's IR camera is used to track the passive ir led. There are multiple papers written on using wiimotes the inverse way to track an ir light in a 3D space. Use driver4VR to infer better position of controllers in playspace. This would require cooperation from Microsoft to open-source the current drivers. Virtual reality is the process of simulating an environment for a user, using a variety of peripherals, head mounted displays or CAVEs, and trackers.Instead of showing you a static viewpoint from a screen, it renders your viewpoint relative to where you are standing, on a head-attached or projected surface, to give an effect identical to your own eyes. Use more low-light cameras and adapt the pre-existing tech for WMR for position outside of visible headset space. I'm hoping that people see and read this thread and jump in with whatever they can offer, be it suggestions or whatever else they can put in to help.Have external tracking technology "take over" when WMR loses "high accuracy" tracking state. ![]() I'm no programmer and thus do not have the means to repair the software myself, but I want to do whatever I can to help those that do. That is why I created this thread, so we as a community can seriously discuss how we can restore the program back to it's former condition. This is what I used OVRIE for, but I know the program was capable of much more than just that. SteamVR's native input remapper doesn't let me do what I want to do either. OVRAS has some PTT functionality as well, but it's more of an awkward and highly cumbersome workaround. I relied on this feature to make a genuine push-to-talk function for Discord when using my Vive. Most notable in my case is the loss of the ability to remap any of my Vive wands' inputs except the trackpad and trigger axes.īefore it was broken by SteamVR updates, I was able to use OVRIE to remap any button on my Vive wands, including the system button, to a multitude of alternative functions, including keyboard input. Unfortunately, despite OVRIE having also been forked by SharkyH20 to a state where it can technically be used again, it is still missing important functionality. As far as I can tell, OVRAS is in a good place right now thanks to the efforts of IceWind and Ykeara creating their own forks of the original program. As likely everyone knows by now, OpenVR Advanced Settings (OVRAS) and OpenVR Input Emulator (OVRIE) were negatively affected by SteamVR updates since the last time they were updated by their creator, matzman666. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |