- From: <jerome.giraud@orange-ftgroup.com>
- Date: Wed, 9 Mar 2011 13:41:35 +0000
- To: <richt@opera.com>, <robin@berjon.com>
- CC: <public-device-apis@w3.org>
Hi, I just set up a simple example of virtual reality using the orientation API and some 3D CSS transforms (to be seen on an iPhone 4 with iOS 4.2.1): http://www.winktoolkit.org/webapps/alpha/wink/api/accelerometer/test/test.html I didn't have time to link it to geolocation data and google street view images but this shouldn't be that hard. Some times ago, we also tried to play videos on the same kind of 3D cube, and we were happy to see that we didn't encounter any performances issues (to be seen on an iPad this time, or Safari 5 :)): http://www.winktoolkit.org/webapps/sintel/cube.html So hopefully, building a AR app, once the device tag will be available won't bring so many performances issues. Jérôme -----Message d'origine----- De : public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] De la part de Rich Tibbett Envoyé : mercredi 9 mars 2011 13:13 À : Robin Berjon Cc : public-device-apis@w3.org Objet : Re: Open standards augmented reality Robin Berjon wrote: > Hi, > > I just came across this: > > http://www.technologyreview.com/computing/35065/?p1=A1&a=f > https://research.cc.gatech.edu/polaris/ > > I was wondering if anyone here was aware of this work, had thoughts, etc. related to rechartering. > As I understand it, the current standards development of the device element [1] gives us webcam access and then geolocation [2] and orientation [2] give us the spatial awareness required to develop augmented reality experiences in the browser. It would be nice to then expose a whole host of sensors that provide more context to the current environment: temperature, light, gravity, pressure, proximity. These are things that we could (and I propose that we should) recharter with. The other concern is the performance hit of doing AR in JavaScript - especially on mobile devices. I expect a JS AR library to pop up and lead the way here. It might utilize Workers and WebGL rendering and browsers are quickly becoming fully hardware accelerated. At that point, if we're seeing significant unresolvable problems with AR performance in the browser, we should regroup and see if we could offload some of the more intensive processing to the compiled nature of the browser. Until then, I'm happy to stay quiet on whether loading AR in to the browser is necessary or even if its a good idea in the first place and let 3rd-party libraries lead the way on AR - as long as we're providing the essential building blocks to AR experiences in browser (such as camera, geolocation and orientation). In terms of the formats of geolocation data, I'm happy to leave that to the open market. 3rd party AR libraries are going to support whatever works for them at the time, whether that's KHARMA or otherwise (e.g. the Geonames format). - Rich [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#devices [2] http://dev.w3.org/geo/api/spec-source.html [3] http://dev.w3.org/geo/api/spec-source-orientation.html
Received on Wednesday, 9 March 2011 13:42:06 UTC