RE: Open standards augmented reality

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