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

Ben Houston ben at exocortex.com
Thu Sep 29 00:39:06 UTC 2016

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

More information about the web-vr-discuss mailing list