[webvr] What not a shared WebVR library similar to ANGLE?

Yuval Boger yuval at sensics.com
Thu Sep 29 01:17:35 UTC 2016


I support Ben's proposal. Sensics would be willing to allocate some of the
OSVR team's time to such an effort. Now we just need a browser vendor to
agree to the same.

Yuval

Yuval Boger
CEO
Sensics, Inc.

On Tue, Sep 6, 2016 at 9:29 PM, Ben Houston <ben at exocortex.com> wrote:

> I greatly respect Florian's opinion but I think that ANGLE actually
> accelerated the adoption of WebGL in Firefox and Chrome.  I will note
> that Firefox and Chrome brought out a stable and usable WebGL
> implementation long before both IE and Safari did and other browsers
> never released a WebGL implementation as it was too costly to do.
> IE's WebGL implementation contains a bunch of weird things that make
> it hard to use (gl_FrontFacing not supported?) an Safari's still
> doesn't support anti-aliasing.  I think that ANGLE actually pushed
> things forward very quickly with WebGL 1.0.
>
> I would suggest that one of the browser makers entertain bringing Ryan
> Pavlik in to one of their offices to do a one- or two-week spike [1]
> to see if OSVR can be implemented in their browser easily ASAP.
>
> I would suggest supporting Ryan on-site during that spike with getting
> the browser compiling with the appropriate libraries and help integrating
> OSVR properly into the render pipeline.
>
> This spike can be done parallel with the existing development schedules
> at the browser maker, thus it will have minimal impact, but if it works, it
> could have great benefits.
>
> I'd suggest trying to get a alpha browser release out publicly at the
> end of the spike
> so others can see if this approach can reap benefits or what are the
> downsides.
>
> The spike would allow one to know if this results in an
> overall benefit without a mitigating downside -
> it could reduce costs of supporting WebVR going forward, free up
> resources for other VR initiatives than just driver support, improve
> stability, increase the number of devices supported.
>
> Interesting, there is no need
> to actually have cross library sharing between multiple browsers to
> gain the benefits of a mature shared VR driver layer. because OSVR is
> already shared and mature - the browser makers do not have to do that
> themselves, they can just leverage it individually if need be.  If
> OSVR does not have unfixable flaws (e.g. performance, device
> compatibility, API, etc.), then this could be very nice indeed.
>
> [1] http://www.scaledagileframework.com/spikes/
>
> Best regards,
> Ben Houston (Cell: 613-762-4113, Skype: ben.exocortex, Twitter:
> @exocortexcom)
> https://Clara.io - Online 3D Modeling and Rendering
>
>
> On Thu, Sep 1, 2016 at 10:36 PM, Ryan Pavlik <ryan at sensics.com> wrote:
> > Though the existence of the OSVR HDK headset does confuse things a bit
> from
> > a branding perspective, the OSVR software framework actually is VR vendor
> > neutral and can/will succeed independent of how many people buy a
> reference
> > piece of hardware that sports a similar name. There are a number of
> vendors
> > (outside of Sensics and Razer) whose native interface is their OSVR
> plugin,
> > as well as others who support OSVR as one way to use their hardware. And
> as
> > I mentioned, for the basic devices, it builds on the generic interfaces
> that
> > have been in use for 20 years with VRPN - it's not an API designed first
> for
> > a single device, it was designed first to be universal. (My background is
> > actually more in projection based CAVE style VR, if that gives you any
> idea
> > of how serious I am about not designing for a single device).
> >
> > On the agility point - On the sensing/input side, innovations that big
> > vendors come up with are likely to be on the server, rather than client,
> > side, and so easy to adopt. (In the case of the Vive and one of the
> Oculus
> > driver implementations, the plugin wraps the vendor's code so many
> > enhancements come for free.) On the rendering side, we have independent
> > implementations of time warp and atw (and had them before Oculus on PC,
> > iirc), as well as direct mode support on Windows, etc. I've used it to
> run
> > (Unity!) apps on a Vive Pre in direct mode on a machine way too low spec
> to
> > run through steamvr, despite the fact that the OSVR Vive driver harnesses
> > the steamvr driver for the Vive.
> >
> > And, in any case, the OSVR software framework is open source software,
> with
> > a sound background and pedigree and rooted in academic and industrial
> > experience mixed with demands of the current gen of consumer VR. Can't
> we as
> > a community innovate faster, and bring more vendors onboard at the same
> > time, so there's no catching up to do at all? (That's a challenge, not a
> > question to reply to :D )
> >
> > Anyway, I'll go back to my corner now that I've chimed in, and remain
> > lurking - hope to see you all around!
> >
> > Ryan
> >
> >
> > On Thu, Sep 1, 2016, 7:28 PM Florian Bösch <pyalot at gmail.com> wrote:
> >>
> >> I forgot to explain that the idea would be for the compatibility layers
> >> frontend to *be* the standard, and that no further translation to the
> WebVR
> >> standard would be needed beyond hooking up its endpoints. That would
> >> (possibly) avoid the protracted update cycle that WebGL is currently
> engaged
> >> in, or at least streamline it.
> >>
> >> On Fri, Sep 2, 2016 at 2:20 AM, Florian Bösch <pyalot at gmail.com> wrote:
> >>>
> >>> Not to diminish the accomplishment of ANGLE being a central component
> of
> >>> WebGL, I feel it should be mentioned that it's also been the source of
> >>> cross-vendor bugs that wouldn't exist quite this way in a more
> heterogenous
> >>> implementation environment. And while it's a great waste of time for
> >>> everybody to write everything, it is also a great source of resilience
> >>> against cross vendor/ecosystem bugs.
> >>>
> >>> I'm not up to date on the state of OSVR and vendor specific SDKs, but I
> >>> also don't think it's quite comparable to ANGLE.
> >>>
> >>> ANGLE in a nutshell uses a standardized set of APIs offered by the
> >>> operating system against a system driver. The evolution of both the
> backend
> >>> and frontend APIs followed a well documented and predictable process.
> >>>
> >>> Nevertheless even with the ANGLE compatibility layer in place, an
> update
> >>> to WebGL has proven to be an extraordinarily difficult process, and it
> is
> >>> still, and will be for quite some time, be stuck at its first iteration
> >>> (give or take the odd extension).
> >>>
> >>> A VR-SDK is not a driver and a standard set of APIs. They're not
> >>> following a well documented and specified revisioning process, they're
> not
> >>> system drivers, they don't offer a standardized way to access the
> hardware
> >>> and they're not coming installed with the operating system. I'm sure
> some of
> >>> these things will change eventually, but they won't change tomorrow.
> >>>
> >>> OSVR itself has to service the ecosystem of devices it "natively"
> >>> supports first, and everything else second. This means that new
> features
> >>> that Oculus and Vive think up, and put into their sdk, might not be
> >>> available in OSVR for quite some time, if ever.
> >>>
> >>> I don't see how that improves the situation/drawbacks of having a
> single
> >>> compatibility layer that reflects a state of affairs as it existed
> quite
> >>> some time (years) ago. I do think that a suitable compatibility layer
> has
> >>> the following characteristics (just my opinion of course):
> >>>
> >>> It is VR-vendor neutral
> >>> It provides an extension mechanism to use VR-vendor specific features
> >>> before they've been present in hardware/SDKs for a decade
> >>> It provides suitable ways to detect the capabilities/extensions of the
> >>> presently connected device. In web parlance, avoid UA detection but
> practice
> >>> feature detection.
> >>> Its core API (the lowest common denominator between VR-devices)
> follows a
> >>> standard process
> >>> Extensions follow an extension evolution process
> >>>
> >>> This has been after all a fairly successful recipe for the GL family of
> >>> APIs, and is somewhat adopted by DirectX in its later incarnations.
> >>
> >>
> > --
> > Ryan A. Pavlik, Ph.D.
> > CTO - OSVR Platform
> > Sensics, Inc.
> > www.sensics.com
> >
> > Latest news and blog posts (subscribe here to get weekly updates):
> >
> > Aug 30: TechCrunch: VR from the battlefield to the couch and back
> >
> > Aug 24: OSVR comes to WebVR
> >
> > Aug 17: VRGuy podcast: Nonny de la Pena on immersive journalism
> >
> >
> >
> >
>



-- 
Yuval Boger
CEO | VRguy <http://www.vrguy.net/>
Sensics, Inc. <http://www.sensics.com/>

-- 


Latest news and blog posts (subscribe here 
<http://sensics.com/subscribe-to-our-mailing-list/> to get weekly updates):

Aug 30: TechCrunch: VR from the battlefield to the couch and back 
<https://techcrunch.com/2016/08/30/vr-on-the-battlefield-to-the-couch-and-back-again-sort-of/>

Aug 24: OSVR comes to WebVR <http://www.sensics.com/osvr-comes-webvr>

Aug 17: VRGuy podcast: Nonny de la Pena on immersive journalism 
<http://sensics.com/vrguy-podcast-episode-20-nonny-de-la-pena-co-founder-emblematic-group/>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/web-vr-discuss/attachments/20160929/7fc53da7/attachment.html>


More information about the web-vr-discuss mailing list