Quest controller prep

[DigiTec]

Description:

The generation 2 touch controllers used by the Oculus Quest will have all of the same buttons and will only differ in the appearance of the model. For this reason, we are factoring the code to allow for only key attributes such as the model url, ray origin and pivot points to be changed. The rest of the model should have similar button mesh structures and so all of the same code should be used.

Changes proposed:

• Factor existing globals for the touch controller model into a set configured by controllerType
• Mirror the gen1 config to the gen2 config until we can upload final models.
• Detect the device type and change the displayModel used for Oculus Quest.
• Update code to use the displayModel properties for ray cast origin and pivot point.

[dmarcos]

Thanks. Just one concern. How should an appllication discriminate between touch / quest? Supermedium for instance, displays an image with controller instructions at launch. Now there’s 1:1 mapping between physical controller and component. This breaks the pattern and applications will have to treat it differently.

[dmarcos]

Is not gen1 / gen2 more of an Oculus nomenclature? Wouldn’t be more clear for developers to call it Rift and Quest?

[tcs-ulli]

Rift S and Quest have same Controllers

[dmarcos]

Maybe not needed. Any scenario
where someone wants to support just one of them?

[dmarcos]

Maybe pass the controller type (Rift, Quest) as well?

[ngokevin]

@DigiTec Any ideas on differentiating touch and quest controllers?

[dmarcos]

@DigiTec Congrats on the Quest Launch! A-Frame works fantastically on the Oculus browser. If you can share a gltf model of the controllers we can ship this PR. Thanks for your help.

[DigiTec]

My proposal for the controller model selection is that we deliver the details in the payload as suggested in the thread. This will solve two cases, the one we are in with Quest/Rift S/Rift where these are all Oculus Touch controllers but with some visual differences. The second case it will solve is specifying a model override. While testing improvements to the old Rift model it was not possible for me to iterate quickly and locally because of the way we fetch directly from the CDN. Being able to specify a model override will be useful for the debugging case, but also if someone has authored a better model for their scenario (performance, capabilities, or some other vector of improvement I haven't thought about). The current glTF I have was not good. We have to iterate more on the model. I've been out of office for a bit and have been unable to drive all of the model fixes needed. I hope to jump on that next week. I suspect it will be a couple more weeks before we have a useful model (one where we can properly articulate the joints/buttons, and highlight etc...)

…

On Wed, May 22, 2019 at 11:48 AM Diego Marcos ***@***.***> wrote: @DigiTec <https://github.com/DigiTec> Congrats on the Quest Launch! A-Frame works fantastically on the Oculus browser. If you can share a gltf model of the controllers we can ship this PR. Thanks for your help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4073?email_source=notifications&email_token=AAMS3HVJUKM57GXF47R3ZRLPWWIQBA5CNFSM4G46ODP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV76B2Q#issuecomment-494919914>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMS3HQDRSBBSXDV2I4JVCTPWWIQBANCNFSM4G46ODPQ> .

[dmarcos]

@DigiTec Thanks for the update and welcome back.

Using an alternative model should be possible by doing el.setAttribute('oculus-touch-controls', 'model', false); and then adding your own model el.setAttribute('gltf-model', 'url(...)');. Overriding the built-in one might be tricky. For buttons highlight and animations to work, the user's model would have to have same parts and ids that would have to document and maintain moving forward.

[nrgapple]

Are there any updates on the issue? It seems we are still missing models for the quest.

[dmarcos]

No models yet. You should be able to use oculus-touch-controls in the meantime (with old touch models that you can replace). Buttons mapping remain the same.

[ganeshv]

FWIW Firefox Reality has Quest controller models here: https://github.com/MozillaReality/FirefoxReality/tree/master/app/src/oculusvr/assets

[dmarcos]

@DigiTec Are there any official Quest controllers models we can use to finish up this PR? Thanks for all your help.

[DigiTec]

Having this conversation internally now. We need to build some. The set we have isn’t compatible with standard three.js rendering.

…

On Oct 14, 2019, at 1:31 PM, Diego Marcos ***@***.***> wrote: @DigiTec Are there any official Quest controllers models we can use to finish up this PR? Thanks for all your help. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[dmarcos]

Having this conversation internally now. We need to build some. The set we have isn’t compatible with standard three.js rendering.

@DigiTec Thanks for the quick update. We use the glTF viewer to make sure that models work in THREE / A-Frame. If possible, separate parts to animate / highlight would be great. The Touch v1 models we use are a good example. Let me know if I can do anything to help.

[dmarcos]

@Knochi has kindly contributed gen2 models on aframevr/assets#34 If they look good for everybody, we can use them with this PR in the interim until official models are available.

[Knochi]

I think these are as official as the gen1 ones. They are from the MozillaReality Repo

https://github.com/aframevr/assets/tree/master/controllers/oculus

[dmarcos]

I integrated the models that @Knochi kindly made based on the Mozilla Reality ones. I also adjusted the model pivot and laser-controls positions accordingly. Thanks @DigiTec and @Knochi for the beautiful work. It's much appreciated.