rom: "Rob Manson"
> To: dev-platform@lists.mozilla.org
> Sent: Wednesday, April 16, 2014 10:17:06 PM
> Subject: Re: Oculus VR support & somehwat-non-free code in the tree
>
> Hey Vlad,
>
> yep timing/latency is definitely the key.
>
> It's great to hear t
On Thursday, April 17, 2014 10:18:01 AM UTC-4, Gervase Markham wrote:
> > The good news is that with the preview release of the latest SDK,
> > they added a C API that does everything that we need. So this might
> > become a moot point; we can dlopen/dlsym our way to victory, and I'm
> > already r
On 17/04/14 05:55, Vladimir Vukicevic wrote:
> Already in the works. :)
Awesome :-)
> The good news is that with the preview release of the latest SDK,
> they added a C API that does everything that we need. So this might
> become a moot point; we can dlopen/dlsym our way to victory, and I'm
> a
On Wed, Apr 16, 2014 at 09:55:02PM -0700, Vladimir Vukicevic wrote:
> On Wednesday, April 16, 2014 9:00:40 PM UTC-4, Eric Rahm wrote:
> > So who actually needs to talk to Oculus? I can try to reach out some
> > folks I used to work with who are there now and see if they're
> > interested in makin
Hey Vlad,
yep timing/latency is definitely the key.
It's great to hear that rAF will be able to support future scheduling to
make time sensitive things better. But wouldn't it be best to have this
sort of implementation utilised by DeviceOrientation/DeviceMotion too?
The Rift is really just u
On Tuesday, April 15, 2014 8:17:44 PM UTC-4, Rob Manson wrote:
> We've also put together a plugin for our open source awe.js framework
> that uses getUserMedia() to turn the Rift into a video-see-thru AR
> device too. And for the 6dof tracking we just use the open source
> oculus-bridge app that
On Wednesday, April 16, 2014 9:00:40 PM UTC-4, Eric Rahm wrote:
> So who actually needs to talk to Oculus? I can try to reach out some
> folks I used to work with who are there now and see if they're
> interested in making license modifications.
Already in the works. :)
The good news is that wi
So who actually needs to talk to Oculus? I can try to reach out some
folks I used to work with who are there now and see if they're
interested in making license modifications.
-e
On 4/16/14, 7:01 AM, Gervase Markham wrote:
On 14/04/14 23:41, Vladimir Vukicevic wrote:
I'd like to get this che
>On 2014-04-15, 5:58 PM, Gijs Kruitbosch wrote:
>> On 15/04/2014 22:34, K. Gadd wrote:
>>> Arguably if you wait for other vendors to expose VR before you do it,
>>> you'll end up having to implement a sub-standard proprietary API like
>>> you did with Web Audio.
>>
>> We had an alternative implemen
Benoit Jacob schrieb:
In this respect, more innovation is not necessarily better, and in fact,
the cost of innovating in the wrong direction could be particularly high
for the Web compared to other platforms.
But innovation is part of our mission (yes, the very short statement of
it that must
Rob Manson schrieb:
I know I'm lobbing in from the sidelines on what is essentially a
licensing debate internal to Mozilla...but wouldn't any VR
implementation like Vlad described be best done as an extension of
existing open web standards where possible.
Excellent points, I really think that s
On 14/04/14 23:41, Vladimir Vukicevic wrote:
> I'd like to get this checked in so that we can either have it enabled
> by default in nightlies (and nightlies only), or at least allow it
> enabled via a pref. However, there's one issue -- the LibOVR library
> has a not-fully-free-software license [
On 15/04/14 06:21, Nick Alexander wrote:
> Can somebody save me some license reading and explain what the existing
> framework around shipping libovr is? Is it explicitly allowed?
> Explicitly dis-allowed? If I read gerv's post [1] correctly, it is
> allowed, but it's hard to distinguish gerv's o
On Apr 15, 2014, at 9:00 PM, Robert O'Callahan wrote:
> On Wed, Apr 16, 2014 at 11:14 AM, Vladimir Vukicevic
> wrote:
>
>> Note that for purposes of this discussion, "VR support" is minimal.. some
>> properties to read to get some info about the output device (resolution,
>> eye distance, dist
On Wed, Apr 16, 2014 at 11:14 AM, Vladimir Vukicevic wrote:
> Note that for purposes of this discussion, "VR support" is minimal.. some
> properties to read to get some info about the output device (resolution,
> eye distance, distortion characteristics, etc) and some more to get the
> orientation
If Oculus doesn't mind relicensing, then this whole discussion is
moot, right? So find that out ASAP.
Nick
On Tue, Apr 15, 2014 at 12:08 AM, Henri Sivonen wrote:
> On Tue, Apr 15, 2014 at 1:41 AM, Vladimir Vukicevic
> wrote:
>> 1. Check in the LibOVR sources as-is, in other-licenses/oculus. A
I know I'm lobbing in from the sidelines on what is essentially a
licensing debate internal to Mozilla...but wouldn't any VR
implementation like Vlad described be best done as an extension of
existing open web standards where possible.
The 6dof data that comes from the Oculus Rift is essential
On 2014-04-15, 7:14 PM, Vladimir Vukicevic wrote:
On Tuesday, April 15, 2014 5:57:13 PM UTC-4, Robert O'Callahan wrote:
On Wed, Apr 16, 2014 at 3:14 AM, Benoit Jacob wrote:
I'm asking because the Web has so far mostly been a common denominator,
conservative platform. For example, WebGL stays a
On Apr 15, 2014, at 4:17 PM, Benoit Jacob wrote:
>
>
>
> 2014-04-15 18:28 GMT-04:00 Andreas Gal :
>
> You can’t beat the competition by fast following the competition. Our
> competition are native, closed, proprietary ecosystems. To beat them, the Web
> has to be on the bleeding edge of te
The following is all my opinion, of course:
Arguably many of the wins currently being seen in web games were only possible
because your biggest competitor (Google, w/NaCL) basically
ceded the market by failing to ship promptly and failing to support
their developers. I don't think the asm.js game
2014-04-15 18:28 GMT-04:00 Andreas Gal :
>
> You can’t beat the competition by fast following the competition. Our
> competition are native, closed, proprietary ecosystems. To beat them, the
> Web has to be on the bleeding edge of technology. I would love to see VR
> support in the Web platform be
On Tuesday, April 15, 2014 5:57:13 PM UTC-4, Robert O'Callahan wrote:
> On Wed, Apr 16, 2014 at 3:14 AM, Benoit Jacob wrote:
>
> > I'm asking because the Web has so far mostly been a common denominator,
> > conservative platform. For example, WebGL stays at a distance behind the
> > forefront of O
On Tue, Apr 15, 2014 at 10:33:51AM -0400, Mike Hoye wrote:
> On 2014-04-15, 10:25 AM, Mike Hoye wrote:
> >On 2014-04-15, 12:47 AM, Andreas Gal wrote:
> >>Vlad asked a specific question in the first email. Are we comfortable
> >>using another open (albeit not open enough for MPL) license on trunk
>
You can’t beat the competition by fast following the competition. Our
competition are native, closed, proprietary ecosystems. To beat them, the Web
has to be on the bleeding edge of technology. I would love to see VR support in
the Web platform before its available as a builtin capability in an
On 2014-04-15, 5:58 PM, Gijs Kruitbosch wrote:
On 15/04/2014 22:34, K. Gadd wrote:
Arguably if you wait for other vendors to expose VR before you do it,
you'll end up having to implement a sub-standard proprietary API like
you did with Web Audio.
We had an alternative implementation + API (
ht
On 2014-04-15, 5:34 PM, K. Gadd wrote:
Arguably if you wait for other vendors to expose VR before you do it,
you'll end up having to implement a sub-standard proprietary API like
you did with Web Audio. If you're first to the market (even with a
prototype that's preffed off), you can exert a lot
On 15/04/2014 22:34, K. Gadd wrote:
Arguably if you wait for other vendors to expose VR before you do it,
you'll end up having to implement a sub-standard proprietary API like
you did with Web Audio.
We had an alternative implementation + API (
https://wiki.mozilla.org/Audio_Data_API ). I don'
On Wed, Apr 16, 2014 at 3:14 AM, Benoit Jacob wrote:
> If VR is not yet a thing on the Web, could you elaborate on why you think
> it should be?
>
> I'm asking because the Web has so far mostly been a common denominator,
> conservative platform. For example, WebGL stays at a distance behind the
>
Arguably if you wait for other vendors to expose VR before you do it,
you'll end up having to implement a sub-standard proprietary API like
you did with Web Audio. If you're first to the market (even with a
prototype that's preffed off), you can exert a lot more pressure on
how things turn out, IMO
Mike Hoye wrote:
the window-close button being right next to the send button in
Thunderbird turns into a real problem after your third coffee, let me
tell you.
Don't you mean before your third coffee?
--
Warning: May contain traces of nuts.
___
dev
On 2014-04-15, 6:52 AM, Robert O'Callahan wrote:
I'd like to get this checked in so that we can either have it enabled by
default in nightlies (and nightlies only), or at least allow it enabled via
a pref. However, there's one issue -- the LibOVR library has a
not-fully-free-software license [1
2014-04-14 18:41 GMT-04:00 Vladimir Vukicevic :
> 3. We do nothing. This option won't happen: I'm tired of not having Gecko
> and Firefox at the forefront of web technology in all aspects.
>
Is VR already "Web technology" i.e. is another browser vendor already
exposing this, or would we be the f
On 2014-04-15, 10:25 AM, Mike Hoye wrote:
On 2014-04-15, 12:47 AM, Andreas Gal wrote:
Vlad asked a specific question in the first email. Are we comfortable
using another open (albeit not open enough for MPL) license on trunk
while we rewrite the library? Can we compromise on trunk in order to
On 2014-04-15, 12:47 AM, Andreas Gal wrote:
Vlad asked a specific question in the first email. Are we comfortable using
another open (albeit not open enough for MPL) license on trunk while we rewrite
the library? Can we compromise on trunk in order to innovate faster and only
ship to GA once t
Hi
> 1. Check in the LibOVR sources as-is, in other-licenses/oculus. Add a
> configure flag, maybe --disable-non-free, that disables building it. Build
> and ship it as normal in our builds.
'--with-non-free'
But actually I'd support the option of keeping the SDK separated and
dlopen'ing the
On Tue, Apr 15, 2014 at 10:41 AM, Vladimir Vukicevic wrote:
> I have a prototype of VR display and sensor integration with the web,
> along with an implementation for the Oculus VR. Despite there really being
> only one vendor right now, there is a lot of interest in VR. I'd like to
> add the we
I’d like to add voice to Henri’s opinion here, because it’s important.
The pivotal part of this discussion is about the precedent this establishes and
the long-term repercussions it will have.
On 15 Apr 2014, at 02:35, Vladimir Vukicevic wrote:
> Yes -- perhaps unsurprisingly, I disagree with G
On Tue, Apr 15, 2014 at 1:41 AM, Vladimir Vukicevic wrote:
> 1. Check in the LibOVR sources as-is, in other-licenses/oculus. Add a
> configure flag, maybe --disable-non-free, that disables building it. Build
> and ship it as normal in our builds.
I think this would
a) set a terrible preceden
1. Check in the LibOVR sources as-is, in other-licenses/oculus. Add a
configure flag, maybe --disable-non-free, that disables building it.
Build and ship it as normal in our builds.
Should be opt-in, not opt-out.
+1
Nick
___
dev-platform mailing li
On 2014-04-14, 9:47 PM, Andreas Gal wrote:
Vlad asked a specific question in the first email. Are we comfortable using
another open (albeit not open enough for MPL) license on trunk while we rewrite
the library? Can we compromise on trunk in order to innovate faster and only
ship to GA once t
+1 to breaking licensing dogma in favor of innovation + moving faster.
On Mon, Apr 14, 2014 at 9:55 PM, Bobby Holley wrote:
> On Mon, Apr 14, 2014 at 9:47 PM, Andreas Gal wrote:
>
>> Vlad asked a specific question in the first email. Are we comfortable
>> using another open (albeit not open enou
On Mon, Apr 14, 2014 at 9:47 PM, Andreas Gal wrote:
> Vlad asked a specific question in the first email. Are we comfortable
> using another open (albeit not open enough for MPL) license on trunk while
> we rewrite the library? Can we compromise on trunk in order to innovate
> faster and only ship
Vlad asked a specific question in the first email. Are we comfortable using
another open (albeit not open enough for MPL) license on trunk while we rewrite
the library? Can we compromise on trunk in order to innovate faster and only
ship to GA once the code is MPL friendly via re-licensing or r
On Monday, April 14, 2014 7:29:43 PM UTC-4, Ralph Giles wrote:
> > The goal would be to remove LibOVR before we ship (or keep it in assuming
> > it gets relicensed, if appropriate), and replace it with a standard "Open
> > VR" library.
>
> Can you dlopen the sdk, so it doesn't have to be in-tree
On Mon, Apr 14, 2014 at 03:41:49PM -0700, Vladimir Vukicevic wrote:
> Hey all,
>
> I have a prototype of VR display and sensor integration with the web,
> along with an implementation for the Oculus VR. Despite there really
> being only one vendor right now, there is a lot of interest in VR.
> I'
On 2014-04-14 3:41 PM, Vladimir Vukicevic wrote:
> 2. Contact Oculus with our concerns about the license, and see if they
would be willing to relicense to something more standard.
We should certainly ask, and explain what the problem is for us.
> The goal would be to remove LibOVR before we ship
Hey all,
I have a prototype of VR display and sensor integration with the web, along
with an implementation for the Oculus VR. Despite there really being only one
vendor right now, there is a lot of interest in VR. I'd like to add the web
and Firefox to that flurry of activity... especially g
47 matches
Mail list logo
