Open cheddle opened 8 years ago
Are you running on the SteamVR beta or non-beta. I believe the steamvr beta recently added a fix for the hand assignment. Also do you launch the games from inside VR or from the desktop? This issue might fix itself for you if you launch from inside VR. See issue #94 for details about what I believe is the same issue people were experiencing for "The Thrill of the Fight".
EDIT: specifically this update: https://steamcommunity.com/games/250820/announcements/detail/616248720992058805
"Fixed an issue where controller hand assignment would not happen right away when launching a game with the headset and controllers idle."
I was running non-beta - I will try the beta tonight.
I launch games from within VR
I have swapped between the lab and space pirate trainer a few times without any change in hand assignment behavior.
The Nvidia Funhouse does bring up the oculus health and safety warning so Ill try out the windows 7 compa mode trick later as well.
Might be related/unrelated but my controllers positional tracking 'pulses' every second and snaps back to roughly head level for one or so frames and then returns to normal traked position - the center line in steamVR menu also pulses at the same time.
Just to chime in on this, I've been using the newest SteamVR beta, and it doesn't seem to have fixed the issue entirely. Sometimes I load into games and only one controller is working.
What I have noticed though is if I just start playing the game with the working controller (as best I can), the 2nd one will eventually just pop in and start tracking. I haven't noticed a consistent amount of time that it takes for this to happen, but it has worked more often than not lately.
Nvidia funhouse issue was fixed with windows 7 compat mode trick. both controllers are tracked.
I've played space pirate trainer for an hour or so with one controller
still not getting two controllers in space pirate trainer or waltz and in all instances the controllers are still pulsing as shown in the video linked.
That's crazy. I don't understand how it's so inconsistent.
Did some more testing - setting all my VR games to windows 7 compat mode.
In the pose calibration tool the tracker origin is overlayed with a symbol to confirm its being tracked - this tracker overlay pulses in the same way that the controllers are pulsing in the video I linked above. This happens with controllers plugged in or unplugged (I think they still use bluetooth even when plugged in anyway).
confirming two controllers present in: VRMultigames Realities
Not so sure that the support flag is appropriate here - might be more of a bug... I'm also not sure that these two problems are related however as with that video I found of the pulsing controllers issue I see that the one-controller problem is also present.
Happy to provide logs or anything else required.
after carefully reading #94 I am definitly getting the same problem - @n8rockerasu do you still get the controllers 'pulsing'? I noticed in your video that your controllers drop tracking for a frame or two every second. I only see some PSmove service users are getting this problem. Maybe this is related?
@cheddle I think I found the flicker problem. After looking at the tracking code I found a mistake I made. If a new video frame isn't available when I'm updating the controller's position the controller is flagged as having lost tracking. But in this case I should just use the position from last frame (since this is different from the case where we do get a new frame and can't see the controller in it). I'll push a new release late tonight with this fix.
@HipsterSloth Any potential downside? e.g., if someone accidentally unplugs their camera or it freezes for whatever reason then the controllers are stuck in a given position. I think you should do the change that you suggest, I just wanted a quick brainstorm for any consequences to anticipate.
@cboulay All good points. I do have a time stamp of when the last new frame came in. If it's too old (>=50ms?) I can consider the controller untracked again.
@HipsterSloth Once sensor fusion is working properly then I think we can get away with much longer than 50 msec between optical tracker updates, which means that very slow cameras can be useful, though faster is still preferred. So I'd probably make the timeout much higher. It's probably worth testing how much positional drift we'll get in IMU-only mode before we decide on the optical tracker timeout before setting the flag.
(that also applies to the case where we do get a new frame and can't see the controller)
Hello There,
As many others, I'm also having the same "pulse" problem as @cheddle . @HipsterSloth , if you can send me the alterations in the code, I could test several different values of the timeout parameter. I'm also willing to participate actively in this project soon, I just need to organize my schedule first :).
@marcoseduardopm @cboulay I have a fix for the flicker issue checked into master here 6d05d7a96ef67647b3aa0b2e13d0351323204dfa.
I'm hoping to get a new release out by the end of the week so this fix will be included in that. In the mean time I'd love feedback/testing on the change.
@HipsterSloth I though I'd have a go at building 6d05d7a but I don't have the option for x64. I did the following steps:
@zelmon64 There should be two batch files: InitialSetup_Win32.bat and InitialSetup_X64.bat. The old InitialSetup.bat went away when we added support for 64-bit builds. Unfortunately cmake will only let you generate a solution for either 64-bit or 32-bit, but not both (I can't figure out out how to make it do otherwise). If you are still seeing InitialSetup.bat that makes me think that you still have old code. My recommendation would be to do the following from GIT bash:
1) Go to a folder to want to download the master branch into
2) Run: git clone --recursive https://github.com/cboulay/PSMoveService.git PSMoveService_master
3) Run InitialSetup_X64.bat
BEGIN HACKY WORK AROUNDS - Fixed in x64 branch
4) Copy contents of C:\...\PSMoveService_master\thirdparty\protobuf\vsprojects\x64\Release
to C:\...\PSMoveService_master\thirdparty\protobuf\vsprojects\Release
5) Run C:\...\PSMoveService_master\src\psmoveprotocol\RunProtoCompiler.bat
END HACKY WORK AROUNDS - Fixed in x64 branch
6) Launch and build C:\...\PSMoveService_master\build\PSMoveService.sln
in MSVC 2013
Glad you guys have some thoughts on what the cause is.
I have zero experience with compiling these myself.
I'll sit tight until a new release is available that incorporates this fix (or if I get enthusiastic ill have a stab at compiling) and hope to see the new sensor fusion in action.
@HipsterSloth Thanks for the help (there's no way I would have figured to do the hacky work arounds). I can confirm that this fixed the flickering and did not notice any new problems (just did a quick test though).
@cheddle It's quite easy to build, just takes a while to install all the dependencies at first. I don't know if I'm allowed to post my build if you'd like to try it instead.
EDIT: @HipsterSloth I just wasn't sure if you were happy for people to post unofficial builds or if there were any rules against it. Here's my build. The zip file is over 30MB and it says the limit is 10MB so I had to cut it up and also added the extra ".zip" on the end (which will need to be remove) because github doesn't like the .001, .002, ... extension. (My upload speed is so slow!) PSMS-6d05d7a.zip.001.zip PSMS-6d05d7a.zip.002.zip PSMS-6d05d7a.zip.003.zip PSMS-6d05d7a.zip.004.zip
@zelmon64 You should be able to zip up the build and add it to this issue. I think issues allow zip files up to 20MB.
EDIT: Also thanks a bunch for giving that a test!
Would appreciate you providing the zip - and yeah getting the right dependencies in the right place are the challenge...
Not an impossible task, i think ill just stick to grabbing the releases
@cheddle Did you see I added the zip file parts to my previous post? Have you managed to unzip it okay?
Ill give it a go in about 6-7 hours when I am home :-)
@HipsterSloth Your fix has indeed solved the main problem. Somehow, I was also finally able to proper calibrate my room with 4 cameras after your fix (the "virtual" cameras positions are almost perfect in steam now). But, in my end, there is still one problem: even though I'm able to play games and the controllers position are very accurate, the controllers movement are not "smooth", giving the impression that the number of samples per second are too low. Thinking that it could be a bottleneck problem, I tried with just one camera and 1 controller and still got the same problem.
Then, I modified the "ServerControllerView::updatePositionEstimation" method in order to make the controller to move automatically around the room and also to prompt the executions per section of the method (got about 200-300 per section). I also checked the functions ServerControllerView::updateStateAndPredict() and update_filters_for_psmove(), and both seems to be working just fine. And still, the problem is there.
So the problem isn't in the tracking, and also isn't in the samples being passed to the updatePositionEstimation function. I will continue to look into it tomorrow, but I appreciate any tips you might have. Where else I could look to help to find this bug?
If you want to, can you try to suggest tests that I could make to narrow down this problem?
Tks
confirming that the fixed verion uploaded by @zelmon64 has resolved the pulsing!
still getting one controller behavior in waltz of the wizard and in space pirate trainer. confirmed that it usually assigns the "right hand object" in waltz of the wizard but it will do it a controller seemingly at random.
@cboulay - any progress? any chance at all of a remedy being implemented in the next release?
@cheddle I assume you're referring to the single-controller problem?
There are some more fundamental PSMoveService problems to work on first before we look at specific client implementations like the openvr driver. Even though it accounts for 90+% of the issues posted here, I only consider the openvr driver to be a bonus for hackers and modders but not something we should worry about perfecting, at least until PSMoveService itself is solid.
Just some feedback
only my right-hand controller is presented in Space Pirate Trainer/Waltz of the Wizard - I can confirm that both controllers are being tracked, If I press the PS button the SteamVR overlay shows both, but in game I only have one.
Interestingly, In The Lab I have both controllers.
The only other application with tracked controllers I have tried is Nvidia Fun House however tracking does not work at all in that app.