Re: Methods and attributes being removed from Chrome 59's WebVR 1.1 implementation

The final shape of the standard is still in flux, (see the explainer
<https://github.com/w3c/webvr/blob/master/explainer.md> for the current
state of things) so there's definitely a possibility to make reasonable
changes to help take into account a wider range of devices. I would suggest
starting a separate thread on this mailing list (public-webvr@w3.org) that
describes what your device is and what you believe the current API
incompatibilities are. Code/API samples demonstrating how your device works
would be extremely helpful.

I'll caution that if support for the device requires large scale
refactoring or forces developers to treat your class of device differently
than the majority of commercially available headsets it's unlikely that we
would find it practical to incorporate those changes, but if it can be
accommodated with a few modest tweaks we'll probably be happy to do so.

--Brandon

On Mon, Apr 17, 2017 at 4:41 AM gabriel <gabriel@broomx.com> wrote:

>
>
>
> Hello,
>
> I’m sorry to highjack this thread, I’m not sure where else to begin with
> my query as it doesn’t seem fit to file an issue just yet. Please let me
> know if this is inappropriate, and direct me to the proper process.
>
> We are a Spanish company developing a VR home projection system (no HMD,
> link bellow), and are very interested in implementing WebVR at the core of
> player. We believe our project will define a new category of VR/AR
> displays, not taken in account in the present state of the WebVR standard.
>
> So our question is to know if such a product could be considered in the
> standard, and how to proceed in order to make our VR projector a registered
> device and integrate its specifications.
>
> Sorry once again if this is not the right place to begin, and please
> forgive my english.
>
> Thanks in advance,
>
> Best regards,
>
>
>
> Gabriel Lecup
>
> Technical Coordinator
>
> www.broomx.com
>
> gabriel@broomx.com
>
> Le 17-04-2017 07:44, Brandon Jones a écrit :
>
> The object returned from getFrameData is a superset of the data returned
> by getPose, so that information is still available even with getPose
> removed.
>
> On Sun, Apr 16, 2017, 6:03 PM Sean McBeth <sean.mcbeth@primrosevr.com>
> wrote:
>
>> What does this mean for "head-locked" UI elements? With WebVR 1.1, there
>> is no non-deprecated way to get the position and orientation of the head
>> separately from that of the two eyes. In WebVR 2.0, there is a
>> `poseModelMatrix` attribute in the `VRDevicePose` class. Though it hasn't
>> yet been documented, the name seems pretty obvious.
>>
>> So if `getPose()` is getting removed from Chrome 59, is `poseModelMatrix`
>> getting added, before WebVR 2.0 is finalized? Or are we going to have to
>> try to decompose the `leftViewMatrix` and `rightViewMatrix` in some way to
>> be able to recombine them?
>>
>>
>> On Fri, Apr 14, 2017 at 7:31 PM, Brandon Jones <bajones@google.com>
>> wrote:
>>
>>> Hi all!
>>>
>>> Wanted to give a heads up that in Chrome 59 (which branched today and
>>> should be hitting Beta channel in a couple of weeks) the WebVR
>>> implementation (still the 1.1 API) will have several methods and attributes
>>> removed. Specifically:
>>>
>>> - VRDisplay.getPose()
>>> - VRDisplay.resetPose()
>>> - VRDisplay.isConnected
>>> - VRDisplayCapabilities.hasOrientation
>>> - VREyeParameters.fieldOfView
>>>
>>> These have also been marked as "deprecated" in the WebVR 1.1 spec. They
>>> were removed because no equivalent functionality is planned for WebVR 2.0
>>> and we want to ween WebVR apps off of them now so that the eventual
>>> migration to 2.0 will be smoother.
>>>
>>> You can see the associated bug, with links to the code change, here:
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=706561
>>>
>>> Thanks!
>>> --Brandon
>>>
>>
>>
>>
>> --
>> Thank you,
>> Sean T. McBeth
>> CEO, Primrose LLC <http://www.primrosevr.com/>
>> T:> 717.261.7689 <//717.261.7689>
>>
>