Hey, I'm one of the creators and current maintainers of A-Frame.
We (the creators of A-Frame) started Supermedium as part of YC W18 to continue to push VR on the Web, and we recently released a WebVR application on top of A-Frame to craft VR worlds inside of VR inside a browser (https://supermedium.com/supercraft).
Let us know if you have any questions about WebVR or A-Frame!
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) when the object count rises over, say, 50. What's the solution here?
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).
Performance of WebXR/WebVR in Chrome+FF is the main reason I started 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.
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.
FWIW, I note 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.)
A year or two ago, I used A-Frame to visualize some of NASA's Martian terrain data[1]. The hardest part was processing it. QGIS could not understand the projection, so slicing out a parcel of land and lining it up with a texture was messy. The best output format was obscure (ENVI) and required arcane GDAL commands to produce. For a GIS noob, it was a lot to handle.
But with this component, all you need to do is specify lat and lon--can't get much easier than that! The repo suggests that different data sources can be used[2], I wonder how hard it would be to standup a Martian terrain source?
Having played with geospatial a lot in the past, both "manually" and using libraries like cesium.js (which a lot of this is based on), my gut reaction is "I have no idea how hard it is." ;)
Joking aside, I'm not sure. As you know, the math in the libraries and the datasets are tightly coupled to the projection model (e.g., on earth, things come back to ECEF coordinates, what cesium calls FIXED, and models of the planet like WGS84). So, I would suspect that this work could serve as a model, but a bunch of the internal math would need to change. Assuming there is a well defined model of Mars that can be used, akin to WGS84, and you can massage all the datasets into a form that can be reliably mapped to it, like AGI/Cesium has done with the geospatial data we are using, it should be possible.
I know we would love to see someone do this, inspiring projects like this is one reason we release things in the open. Heck, you could imaging a new set of options for the a-terrain component that specified the globe model somehow ("WGS84, MARS18") and a base URL for the data server ...
I'm using a spherical model for simplicity. Although I'm fetching image tiles and suchlike I reproject from mercator directly to spherical for simplicity rather than the slightly ellipsoidal model.
And the image tile source and elevation tile source and radius of the sphere is a user settable attribute from the <a-terrain> tag. If you simply set the right radius and image tile source in html - you would have a working mars view... I believe. I can ask Cesium if they have some official sources for this.
I see this as part of a trend where we'll see geo capabilities available more and more as a plug in, whereas it used to be that it was its own separate and self contained domain.
13 comments
[ 3.4 ms ] story [ 28.9 ms ] threadWe (the creators of A-Frame) started Supermedium as part of YC W18 to continue to push VR on the Web, and we recently released a WebVR application on top of A-Frame to craft VR worlds inside of VR inside a browser (https://supermedium.com/supercraft).
Let us know if you have any questions about WebVR or A-Frame!
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).
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.
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.)
A year or two ago, I used A-Frame to visualize some of NASA's Martian terrain data[1]. The hardest part was processing it. QGIS could not understand the projection, so slicing out a parcel of land and lining it up with a texture was messy. The best output format was obscure (ENVI) and required arcane GDAL commands to produce. For a GIS noob, it was a lot to handle.
But with this component, all you need to do is specify lat and lon--can't get much easier than that! The repo suggests that different data sources can be used[2], I wonder how hard it would be to standup a Martian terrain source?
1 - Github: https://github.com/bryik/aframe-terrain-model-component Example: https://www.wsundine.com/misc/noctis-terrain
2 - https://github.com/anselm/aterrain/blob/master/src/TileServe...
Joking aside, I'm not sure. As you know, the math in the libraries and the datasets are tightly coupled to the projection model (e.g., on earth, things come back to ECEF coordinates, what cesium calls FIXED, and models of the planet like WGS84). So, I would suspect that this work could serve as a model, but a bunch of the internal math would need to change. Assuming there is a well defined model of Mars that can be used, akin to WGS84, and you can massage all the datasets into a form that can be reliably mapped to it, like AGI/Cesium has done with the geospatial data we are using, it should be possible.
I know we would love to see someone do this, inspiring projects like this is one reason we release things in the open. Heck, you could imaging a new set of options for the a-terrain component that specified the globe model somehow ("WGS84, MARS18") and a base URL for the data server ...
And the image tile source and elevation tile source and radius of the sphere is a user settable attribute from the <a-terrain> tag. If you simply set the right radius and image tile source in html - you would have a working mars view... I believe. I can ask Cesium if they have some official sources for this.