4 ms·

Hi, we see an over 10x performance penalty for the same scene in webVR vs native application. Also, there's constant sickening object flickering (basically what

Hi, we see an over 10x performance penalty for the same scene in webVR vs native application. Also, there's constant sickening object flickering (basically what's described here: https://github.com/toji/chrome-webvr-issues/issues/119 https://github.com/toji/chrome-webvr-issues/issues/119) when the object count rises over, say, 50. What's the solution here?

ngokevin 8y ago
Seems like that was an issue with Chrome? We have our own VR browser (Supermedium), try your content there and let us know. There is a smidge of latency of Steam VR, but we'll look to optimize it soon, otherwise it's indiscernable from native. 50 shouldn't be an issue, but you can employ optimization techniques such as geometry merging and instancing to reduce draw calls. In Supercraft, we merge hundreds or thousands of objects down to 1 draw call (check out this dragon at https://supermedium.com/craft/bawdy-wealth https://supermedium.com/craft/bawdy-wealth).
avaer 8y ago
Performance of WebXR/WebVR in Chrome+FF is the main reason I started Exokit (https://github.com/webmixedreality/exokit https://github.com/webmixedreality/exokit), which is a HTML/WebXR->OpenGL binding as a node module that runs fast. It's early days and I can't speak to any particular performance issue, but making WebXR run like native is certainly a problem I'm trying to solve.
- ngokevin 8y ago
  It runs like native mostly fine for the most part, doesn't call for a rebuild from scratch. Our VR browser engine is based off of FF for now, and it's on Steam VR and Oculus Stores without anyone noticing.
mncharity 8y ago
FWIW, I note https://github.com/mncharity/node-webvr-alt-stack https://github.com/mncharity/node-webvr-alt-stack . It's an old abandoned WebVR-1.0-like Vive-on-linux browser-as-compositor stack. Official WebVR support for linux was so completely unusable, that I rolled my own on top of Valve's low-level OpenVR lighthouse device driver. It was a hack, but that made it easy to get working. Some Three.js WebVR demos worked. A-Frame didn't (wasn't a priority). No lens correction. Old WebVR 1.0. The repo may well still work, but you'd likely need to pin all the node.js module versions. No predictive pose, so lag but no judder. The few people who tried it, including some highly sensitized devs, were fine with that. 90 fps on down towards 40. I still use a similar stack around 30 fps with camera passthru AR. It just worked. I didn't plan to deploy on it, but it was nice to have a WebVR dev environment where things just worked. Which at the time, was far from true even on Windows. And given your description of current state... fyi fwiw. I wondered at the time if Mozilla might be making a strategic error by so blowing off linux. The linux VR community was, and is, negligibly small compared to Windows. But a more diverse development community might have yielded a more robust development effort. (BTW, my thanks - I'd managed to not notice the project has a long open issue. Eep.)

ngokevin 8y ago

Seems like that was an issue with Chrome? We have our own VR browser (Supermedium), try your content there and let us know. There is a smidge of latency of Steam VR, but we'll look to optimize it soon, otherwise it's indiscernable from native. 50 shouldn't be an issue, but you can employ optimization techniques such as geometry merging and instancing to reduce draw calls. In Supercraft, we merge hundreds or thousands of objects down to 1 draw call (check out this dragon at https://supermedium.com/craft/bawdy-wealth https://supermedium.com/craft/bawdy-wealth).

avaer 8y ago

Performance of WebXR/WebVR in Chrome+FF is the main reason I started Exokit (https://github.com/webmixedreality/exokit https://github.com/webmixedreality/exokit), which is a HTML/WebXR->OpenGL binding as a node module that runs fast. It's early days and I can't speak to any particular performance issue, but making WebXR run like native is certainly a problem I'm trying to solve.

ngokevin 8y ago
It runs like native mostly fine for the most part, doesn't call for a rebuild from scratch. Our VR browser engine is based off of FF for now, and it's on Steam VR and Oculus Stores without anyone noticing.

mncharity 8y ago

FWIW, I note https://github.com/mncharity/node-webvr-alt-stack https://github.com/mncharity/node-webvr-alt-stack . It's an old abandoned WebVR-1.0-like Vive-on-linux browser-as-compositor stack. Official WebVR support for linux was so completely unusable, that I rolled my own on top of Valve's low-level OpenVR lighthouse device driver. It was a hack, but that made it easy to get working. Some Three.js WebVR demos worked. A-Frame didn't (wasn't a priority). No lens correction. Old WebVR 1.0. The repo may well still work, but you'd likely need to pin all the node.js module versions. No predictive pose, so lag but no judder. The few people who tried it, including some highly sensitized devs, were fine with that. 90 fps on down towards 40. I still use a similar stack around 30 fps with camera passthru AR. It just worked. I didn't plan to deploy on it, but it was nice to have a WebVR dev environment where things just worked. Which at the time, was far from true even on Windows. And given your description of current state... fyi fwiw. I wondered at the time if Mozilla might be making a strategic error by so blowing off linux. The linux VR community was, and is, negligibly small compared to Windows. But a more diverse development community might have yielded a more robust development effort. (BTW, my thanks - I'd managed to not notice the project has a long open issue. Eep.)