Update examples: add controller option

[kylebakerio]

• added controller option!
• also, support controller model (and button model) animations!
• more semantic use of NAF createdByMe() to remove need for class
• clean up this.Y[this.Z] pattern by more correctly utilizing A-Frame prototype pattern
• support for live-switching between models
• support for many other controller models (not only vive, but also older models as well)

see live updated demo: https://naf-wip.glitch.me/tracked-controllers.html

[kylebakerio]

Through working on the quest 2 controller in parallel, I have realized that only some model changes are handled in updateModel(), but others are handled earlier that I'm missing and skipping replay on, in onButtonChange(). I am considering updating the code to be grabbing those events further up and relaying them, so that button movements are also handled, instead of just button mesh colorations.

Another option is to offer a pull request upstream to modify those controller components so that they truly do allow separate manipualtion of the controller without emitting an event. It could be doable without creating any breaking changes, just separation of concerns. But that's more work, anotehr pull request on another project, etc.

Kind of annoying. The architecture and flow of the events for controllers is more than a bit awkward.

[kylebakerio]

This is particularly relevant for the quest 2 controllers, which I will be making a pull request to core for to enable full joystick and trigger button representation. I'd like those to be visible over the wire, and with the current design, that stuff would be missed.

I'll come back with more updates soon, need to run some experiments on that.

[kylebakerio]

Alright, so:

1. I expanded the method I've used to grab joystick movements, mesh colors, and button mesh rotation/position updates.
2. I've tested it with the new not-released quest2 model component that support moving buttons; also, the vive controls component supports moving buttons, and that worked as well
3. Also tested with a few other models of older oculus controllers (to be clear: all except for quest 2 were only tested with emulated chrome extension)
4. This all works, correctly, in my experiments, for all the models I have tested recently (you can test the latest, including with experimental quest2 support, here).
5. However, knowing everything I know, if I were starting at the beginning again, I think I'd be tempted to just intercept and rebroadcast simplified versions of the actual base events from the tracked-webxr-controls component itself, for the cleanest implementation.
6. That said, there are some optimization benefits gained from doing it this way, so I'm not really motivated to rewrite this into that form--this seems to work quite well.

[kylebakerio]

note: I added this file only so that I could test with it on glitch: https://naf-wip.glitch.me/tracked-controllers.html

it is removed in a later commit

[kylebakerio]

these make seeing the controller buttons much easier, they are really hard to see without this

[vincentfretin]

okay

[vincentfretin]

You can remove those commented lines now.

[vincentfretin]

This try catch can be removed completely right? removeAttribute below is already doing the job.

[vincentfretin]

Are you sure you want this.removeEventListeners(); here? It seems wrong. this.removeEventListeners(); is already in pause() for local player symmetrically with the this.addEventListeners() for the local player in play()

[kylebakerio]

yeah, that's correct. I hadn't touched A-Frame almost at all since last fall until the past month or so. Not sure if I forgot or never knew, but I've either learned or re-learned from you about the removeAttribute calling remove which calls pause pattern. when I started I assumed it was just incomplete. makes sense, though.

thanks for the review, I think everything I wrote would have worked fine either way, but I definitiely gained knowledge about writing better a-frame code.

[vincentfretin]

Thank you for your patience. I'm glad you learned some things from this review.

I also relearned yesterday that when adding a component, it runs init and then update!, then play.
See https://github.com/aframevr/aframe/blob/795edfd65841d54aa2b186a02f660ffee606b50c/src/core/component.js#L306-L336
I had a code in update that was replacing an outfit material for an avatar, and I saw it did the logic twice.
My code was this:

schema: {
    outfit: { default: "" },
},
update: function (oldData) {
    if (!oldData) return; // Normally always a {} if it's an object based component when adding the component locally, but can be undefined some times when NAF is creating it.
 
    if (oldData.outfit !== data.outfit) {
      this.loadOutfit();
    }
}

To fix the issue I just added an extra condition:

update: function (oldData) {
    if (!oldData) return; // Normally always a {} if it's an object based component when adding the component locally, but can be undefined some times when NAF is creating it.
 
    if (oldData.outfit && oldData.outfit !== data.outfit) {
      this.loadOutfit();
    }
}

That works because I know I'm setting the outfit when creating the component, I don't want a naked avatar. :)

[vincentfretin]

I tested it on my Quest 1, it's working.

[kylebakerio]

My latest update for the oculus-touch-controls (in aframe core, not here) should also fix the quest 1 (and all non-quest-2 oculus controllers, I think) controllers having the 'all buttons light up when you touch one button' issue, and that'll instantly start working with this component at that time if/when it gets merged in.