A-Terrain - a cartography component for A-Frame
blog.mozvr.com
blog.mozvr.com
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.
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!
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.)