I was just about to say the same thing. This API is essential for our AR work;
the fact that Firefox is different than other browsers is problematic, but
there are javascript libraries that help with it. Getting rid of it would be
really bad.
> On Jul 24, 2017, at 9:57 AM, Ben Kelly wrote:
independent of WebAR? Especially
when we think of issues discussed on this thread (e.g., threat models and
security) having “things needed for AR” folded into WebAR, and accessible in
the context of whatever permission model WebAR ends up using may be the way we
want to go.
--
Blair MacIntyre
On Jul 24, 2017, at 4:38 PM, Enrico Weigelt, metux IT consult
wrote:
>
> On 24.07.2017 15:07, Mike Hoye wrote:
>>
>> I have a sense that as AR gets richer and more nuanced that ambient
>
> Are we still talking about browsers ?
Yes.
There are plenty of websites that use deviceorientation,
I’m not sure what you’re asking: I’ve been using the deviceorientation API
like this for many years, as have plenty of other people.It’s absolutely
needed.
--
Blair MacIntyre
Principal Research Scientist
bmacint...@mozilla.com <mailto:bmacint...@mozilla.com>
> On Jul 24, 2017
Are we still talking about deviceorientation?
It’s used to determine the 3D orientation of the device, so that we can tell
the direction it is facing. Developers use it to render 3D graphics (WebGL or
CSS3D using perspective DIV) around the user. e.g., look at one of my project
samples, like
> On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre
> wrote:
>> Are we still talking about deviceorientation?
>
> As I said twice and Frederik repeated, we're not, other than asking if
> anyone has a plan for how to make it interoperable.
Yes, I know; I was just respo
> At least these things should be purely optional and providing an
> *easy* way to filter that data. (same for the geolocation stuff).
FWIW, I wouldn’t mind being involved in a discussion about this, if people want
to seriously consider putting it behind a "user-permission prompt" (similar to
>> What's the reason for this? I don't know for sure, but it may be necessary
>> for things like AR/VR to have higher resolution than that.
> The reason is to limit the frequency of sensor data the web application
> receives to allow it to guesstimate the changes to the device position to
> limi
>>> We discussed this a bit with Anne on IRC. It seems like this API is a good
>>> use case for a permission prompt to the user. Since the API works by
>>> registering an event listener, the only realistic option seems to be
>>> Permission.request() before registering the event listeners. Unf
(I’m CC:ing a few of the MR team folks, although I’m sure many of them are on
the dev-platform list already).
Speaking for myself (not the official stance of the WebVR team), I share these
concerns and like the trajectory you suggest.
I would HOPE that in the long run (some number of years?)
I don’t think tying orientation to GPS is really a viable approach.
The main use case for the orientation API, I think, is not AR; it’s 360 images
and videos, and “cardboard VR”, right now.
> On Jan 1, 2018, at 5:01 PM, Martin Thomson wrote:
>
> The suggestion that was made in the past was
at is a far
> stretch from head/position tracking.
>
> On Wed, Jan 3, 2018 at 2:47 PM, Blair MacIntyre <mailto:bmacint...@mozilla.com>> wrote:
> I don’t think tying orientation to GPS is really a viable approach.
>
> The main use case for the orientation API, I think,
We could chat about it, sure; how do you envision it working without breaking
old websites?
> On Jan 3, 2018, at 5:43 PM, Martin Thomson wrote:
>
> On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre
> wrote:
>> I was more concerned about the idea (or, at least what
could trigger a perms request, and the data would only start
flowing on acceptance.
> On Jan 3, 2018, at 11:52 PM, Martin Thomson wrote:
>
> On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre
> wrote:
>> We could chat about it, sure; how do you envision it working withou
I’ve been thinking about this since my last message, and I wanted to step back
and clarify something for myself.
First, this discussion pertains to FF on Windows, Mac, Android and Linux, I
assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide on
things like this. Is this c
> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre
> wrote:
>> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I
>> assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide
>> on things like this. Is this correct?
>
>
12, 2018 at 4:48 AM, Blair MacIntyre
> wrote:
>>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre
>>> wrote:
>>>> First, this discussion pertains to FF on Windows, Mac, Android and Linux,
>>>> I assume? FF for iOS just uses the wkWebView and
>
> On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre
> wrote:
>>> In that case I'm not entirely sure why we'd also pursue new
>>> variants separately.
>>
>> I’m not sure what this means?
>
> That if our main usage for the new sensor APIs
plays collect (using sensors to
build models of the world around the user, for example), we will eventually
want to explore how to expose that data into the web (as part of WebXR, or some
other API). Explaining what this means to users will be hard, much like device
orientation.
Thanks for
19 matches
Mail list logo
