Closed sjpt closed 7 years ago
Thanks for filing, @sjpt. I can confirm that I'm having the same problem and have heard from at least one or two others in WebVR Slack.
Any idea where to get the old version?
I've put a copy on Dropbox for now https://www.dropbox.com/s/acmlkinnm9lrwbz/SteamVROLD.zip?dl=0 May well be an older copy than really necessary, but at least it works (for me). May take a few minutes to upload, it has lots of stuff in that I am sure is not needed; like room setup is 460MB uncompressed.
This issue seems like same as #125
I have faced this issue a month ago, uninstall + reinstall steam solved the problem back then. But its back again now.
I now have a much more cut down patch, and have removed the one above https://www.dropbox.com/s/xfydwr4mea0fvsx/SteamPatch.zip?dl=0
I believe that this is fixed with the most recent build at https://webvr.info/get-chrome
Thankyou for the quick update. It helps in many cases, but still fails for me with some examples, for example https://threejs.org/examples/?q=webvr#webvr_vive_dragging
Also fails with my own code. I will investigate a little further to see if I can narrow down the cause.
The issue appears to be with navigator.getGamepads(). If this is issued before entering vr, chrome crashes on entering vr.
Sample sequence:
Steps 2 and 3 illustrative, 1,4,5 will also cause crash.
More details in case they help. Note .. do NOT use my Steam patch with this latest ChromeVR.
Old Chrome = 23 Dec 2016 version New Chrome = 1 Feb 2017 version Old steam = 8 Dec 2016 version New Steam = Jan 26 1017 version
New chrome, new steam. Works for cubes, crashes with crashes for navigator.getGamepads() as above New chrome. old steam. Does not crash, but no display on headset (***) Old chrome, new steam Crashes Old chrome, old steam. Works
(***) not an issue as nobody will probably want to run that combination, but included for information
The issue appears to be with navigator.getGamepads(). If this is issued before entering vr, chrome crashes on entering vr.
That does not appear to be the entire problem, as using JavaScript to avoid calls to the real navigator.getGamepads()
unless presenting in VR only delay crashes slightly rather than eliminating them.
<script>
// try to avoid steamvr crash when accessing navigator.getGamepads() then entering VR
window.realNavigatorGetGamepads = navigator.getGamepads.bind(navigator);
window.useRealNavigatorGetGamepads = false;
window.addEventListener('vrdisplaypresentchange', function (evt) {
window.useRealNavigatorGetGamepads = evt.display.isPresenting;
});
navigator.getGamepads = function () {
return window.useRealNavigatorGetGamepads
? window.realNavigatorGetGamepads.apply()
: [null];
}
</script>
Me i used the patch since yesterday, it works for me. Thanks a lot for this.
To machenmusik More delving (apparently) shows that it is indeed related to navigator.getGamepads(). The bad effect of this call is not limited to a visit to a given page, but to an entire Chrome session. So
Adding a patch such as yours does prevent the examples crashing if you take that into account. At least, it seems to for me; making sure of testing all combinations is almost impossible.
I am glad the patch helped.
For me there is one positive outcome of all this, which is I (think I) now know how to run openVR on a machine without Steam; and to run determined versions without risk of being broken by Steam updates. Searches on the web had indicated a little what was going on, but not made it clear to me.
This is important to us for running exhibitions, and may be useful for others as well. This may not be complete/correct; any updates or corrections welcome. I have not been able to test it 100% as I haven't access to a machine powerful enough to run openVR that is not already polluted with a Steam install. (I tested as far as I could on a very old laptop, and it seemed to work as far as I could expect anything to work on that machine.)
A few points
if using latest steamvr and latest experimental Chromium, that javascript wrapper does avoid the instant white screen and aw-snap, but in video examples, the aw-snap still happens about ten seconds later, with a dxva2 related error message visible when --enable-logging is provided on the command line
Clarification on my comments above: the version of ChromeVR that is working for me (with the Steam patch above) is that from 'WebVR Builds/Archive/Oct 29 2016' (Why do you write your dates inside out? Our back to front is silly enough.)
https://drive.google.com/open?id=0BzudLt22BqGRRElMNmVqQjJWS2c
p.s. this issue should not be reopened as the 1 Feb fix did not fix it.
I managed to get old Chrome working with old SteamVR as @sjpt describes above - thanks for that!
However, my Vive controllers do not show up at all when running old SteamVR - and they are not only missing in Chrome, but everywhere, including in the default "This is real" environment. As soon as I switch back to current SteamVR, I have the controllers working, but Chrome is obviously also crashing.
My primary reason for desperately needing ChromeVR to again for my Vive is the controller support, since Firefox doesn't have it. Is the fix here really that the Vive controllers have been disabled in the old SteamVR shared by @sjpt, or do others have controllers working with old SteamVR?
I can confirm that I have Vive working with controllers on that older Chrome and older SteamVR.
@RSpace how are you trying to access controllers? if using A-Frame 0.4.0 and not latest master, you may be running into a rAF timing bug with the older build of experimental Chromium that is fixed in Feb1 build and worked around in A-Frame
also, Nightly does in fact support Vive controllers via OpenVR, but I believe you need to enable it in about:config - more info at webvr.info
@sjpt Thanks, can you link to an app where it's working for you? A-Painter, Puzzle Rain, a Codepen?
@machenmusik I'm using A-Frame 0.4.1 in my own app. Also tried with the Superhands Vive example, but I guess that's probably using outdated code too. Can you link to a page where it's working for you so I can test with the right version? And sounds great with Nightly - I'll try that tomorrow when I'm back at the office with the Vive. Thanks!
@machenmusik Btw, when you reference webvr.info, I assume you mean https://github.com/Web-VR/iswebvrready/wiki/Instructions%3A-Firefox-Nightly-for-HTC-Vive-on-Windows which is it pointing to? That page specifically say Vive controllers are not supported. However, I do see 4 gamepad related about:config settings, all which I have already enabled except for "dom.gamepad.test.enabled" - is that the one?
@RSpace
I'm using A-Frame 0.4.1 in my own app.
Yeah, that's actually 0.4.0 with a npm-specific fix, you need newer.
So if you're using npm and package.json, you can reference github commits like so:
"aframe": "aframevr/aframe#8d88a5b"
Answering on phone so can't check details but for working app see threejs.org/examples , go to Webvr and it's something like Vive dragging
On 8 Feb 2017 21:03, "Casper Fabricius" notifications@github.com wrote:
@sjpt https://github.com/sjpt Thanks, can you link to an app where it's working for you? A-Painter, Puzzle Rain, a Codepen?
@machenmusik https://github.com/machenmusik I'm using A-Frame 0.4.1 in my own app. Also tried with the Superhands Vive example, but I guess that's probably using outdated code too. Can you link to a page where it's working for you so I can test with the right version? And sounds great with Nightly
- I'll try that tomorrow when I'm back at the office with the Vive. Thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/toji/chrome-webvr-issues/issues/135#issuecomment-278460827, or mute the thread https://github.com/notifications/unsubscribe-auth/AEubbPk1WHv5dg6Zc997i38HK0nonECUks5rai2vgaJpZM4LzJSZ .
consolidating the instructions graciously provided by @sjpt https://github.com/toji/chrome-webvr-issues/issues/135#issuecomment-276635154 and https://github.com/toji/chrome-webvr-issues/issues/135#issuecomment-278285528 in one spot...
Download this SteamVR patch containing an older version of vrserver.exe https://www.dropbox.com/s/xfydwr4mea0fvsx/SteamPatch.zip?dl=0
Extract the patch to the directory of your choice. Make sure nothing Steam or SteamVR is running. Then, launch the vrserver.exe executable in the patch directory .\SteamPatch\openvr\bin\win64\vrserver.exe
Download the October version of experimental Chromium 'WebVR Builds/Archive/Oct 29 2016' https://drive.google.com/open?id=0BzudLt22BqGRRElMNmVqQjJWS2c Extract it to the directory of your choice, and run the chrome.exe browser executable it contains.
NOTE: per the instructions at https://webvr.info/get-chrome/ you may need to enable WebVR and/or Gamepad API Extensions before using WebVR sites.
NOTE: Do NOT use the newer Feb 1 2017 version of experimental Chromium with this SteamVR patch
https://chenz.org/aframe-arcade/ is working (at time of writing) with both Rift/Touch (both older and newer Chromium) and Vive/wands (older Chromium with patch as described)
Apologies for bringing up Firefox here again, but for anyone else having trouble with getting Chrome working (with or without controllers) at this point, I managed to get the Vive controllers working with the newest Steam VR and Firefox Developer Edition with all the usual VR flags enabled plus all gamepad flags enabled, including dom.gamepad.test.enabled
.
I don't generally use them but I haven't had new issues with Nightly or Developer Edition and recent Steam updates. I have a long standing issue that some of my code does not behave correctly (no image) which I have not had the time to track down; this applies in VR or not. I'm not at all sure it is a Firefox issue, rather than an error of mine I am getting away with in Chrome.
What would be a reliable way to detect this specific version of chrome to be able to avoid calling getGamepads()
?
@RSpace https://github.com/aframevr/aframe/pull/2191 -- according to several, just started happening last night
@sjpt should this bug be reopened?
I think it should be reopened (I mentioned it above somewhere), but I don't think I can do it myself; I certainly don't know how to.
For anyone doing WebVR development right now I highly recommend avoiding the Chromium builds for now and using Firefox Nightly as described here: https://webvr.rocks/firefox
@mflux perhaps for vive if the workaround is too troublesome, but for rift/touch, chromium works fine
I partly agree with mflux's comment. Also consider Firefox Developer Edition which is more stable than Nightly. Longish post a bit about my working practice that may help
For anyone doing regular development (and even more doing exhibitions and demonstrations) I thoroughly recommend for any of the browsers that you (1) have a safe working version of the browser backed up that will NOT get automatic updates, and (2) have a safe working version of SteamVR that will not get automatic updates. Essentially an extension of my workaround above.
(1) Will depend on the browser. For the VR version of chrome it is easy just to unzip the different versions to different locations.
(2) Can be done by copying the SteamVR directory at
One extra reason to use a Firefox variant ... it seems to behave much better than ChromeVR with asynchronous reprojection.
I've just failed to get Firefox Nightly or Developer edition working here. This was using the version of the OpenVR dll linked at https://webvr.rocks/firefox.
Servo (which I'd not heard of until about ten minutes ago) works, at least for a basic demo. I'll see if that extends to anything more complicated. Definitely not one for editing code in.
Try the Steam OpenVR dll; somewhere like (depending on your install, and care with 32/64 bit versions) C:\Program Files (x86)\Steam\steamapps\common\SteamVR\bin\win64\openvr_api.dll Firefox Developer or Nightly working for me with unpatched Steam (but not for our app). Settings: dom.vr.openvr.enabled=true, and gfx.vr.openvr-runtime as above.
https://threejs.org/examples/?q=webvr#webvr_vive_dragging is a good example to test both VR and gamepads.
Nope, not working here at the moment. I notice Steam says I should update firmware, so I suppose now(ish) might be a good time to try that.
Blarg. Should be actually truly really honestly fixed now. Sorry again!
A recent update to SteamVR (Jan 26 2017 1485391631) causes Chrome VR to crash (for me on two machines) when a window attempts to enter VR. Mainly running the current (23/12/2016 Unknown user) version of Chrome VR
I have been able to resolve this temporarily by renaming C:\Program Files (x86)\Steam\steamapps\common\SteamVR and copying in an old version. Clearly not a nice solution, but might help others in the very short term.
It also looked as if it worked to 1) make a copy of the old SteamVR directory (as above) in another place XXX 2) make sure nothing Steam running 3) start vrserver.exe from the copied old directory at XXX 4) run Chrome VR, run app, and open VR That could be a slightly cleaner short term patch.
I know you are mainly looking at the Android version at the moment, but any comment/update on this would be appreciated.
This may be related to an earlier post where problems with a beta of SteamVR caused Chrome VR to crash, https://github.com/toji/chrome-webvr-issues/issues/130
Stephen