networked-hand-controls.js should inherit or respect MODEL_BASE from AFrame

[Utopiah]

I'm trying to run NAF offline and it works well.

I tried running the hands example but unfortunately couldn't load the model, which was a stranger error.

Upon checking the component networked-hand-controls https://github.com/networked-aframe/networked-aframe/blob/master/src/components/networked-hand-controls.js#L588 I noticed MODEL_BASE is being redefined.

I also noticed customHandModelURL which should be sufficient for my use case yet somehow despite setting using networked-hand-controls="customHandModelURL:model.glb;" it I still see in the console network errors trying to reach the CDN.

PS: what's quite surprising also is that if I remove the HMD, put it back, I see hands models at original coordinates. So... somehow something gets loaded, at least in the HMD, but maybe not displayed. Very confused.

[vincentfretin]

I'm not super familiar with the code. @kylebakerio may know better.

[kylebakerio]

It's not being redefined, iirc, it's only defined there. Why do you say redefined? Pretty sure I just split the URL up that way to make the code cleaner.

customHandModelURL is not a well tested feature, just a kind of 'well, technically, someone might want this instead, so let's allow it and see what happens'. You are likely to get errors if your custom hand model doesn't have baked in animations with the same names--I didn't spend the time modifying that to be more flexible because this was already a big contribution and that was an edge case that so far we had no demand for.

What I imagine is happening is you are adding a custom model that lacks the animations, they load in, but then you get errors thrown when buttons are pressed and animations for gestures are triggered.

short term patch: look at the code and make sure you add matching animations to your model, even if they do nothing. (unless you actually want matching gestures, in which case you'll need to add the animations themselves, not just named blank animations, ofc).

Note that this is documented in the code:

    // these are for specifying a custom hand model URL; only allowed at init, not via update
    // (must correspond to existing models and have matching animations to work properly)
    customHandModelURL: { type: "string", default: '' }, 

Also notice that there's a visible internal property. For your weird 'visible when I take it off and put it on' issue, that's most likely just the errors preventing visible from switching on, but then an update being fired because of some event that does trigger it related to entering/exiting webxr? just a guess, but not worth chasing down as it's very likely an artifact of what are effectively broken models.

a slightly better patch would be a PR that bypasses the gestures according to a flag available in the schema. this should not only allow adding simpler models without gestures, but also turning off the gesture tracking if someone wanted that for less noisy network traffic, for example.

[Utopiah]

I copied the AFrame models as glb and put them in the local directory so I'm rather confident the models themselves including all necessary animations (as it works with AFrame offline).

What I meant by "redefined" is relative to AFrame, not NAF, but maybe there are some use cases were decoupling models from AFrame is useful.

[Utopiah]

Well that's a mindf*ck... when I visit https://naf-examples.glitch.me/tracked-controllers.html (online obviously) I see someone else (my other computer for tests) but I also see no hands, also not locally in the HMD (even though they are tracked, I can see the OS buttons when I flip them away).

Checked via the remote debugging console and spot no error (beside a missing favicon).

Edit: just tried another AFrame experience (non networked) relying on hand-tracking-controls="hand: right;" and hands are visible.

[kylebakerio]

Sorry, I'm not sure I follow.

Perhaps I'm forgetting, but I don't think MODEL_BASE exists in A-Frame; pretty sure it's just something I wrote there so that the URL wasn't copy/pasted 6 times. Can you tell me what you think it should inherit from? In other words: MODEL_BASE is not being 'redefined' (unless I'm forgetting something and missing something here?)--it's just being defined, for code cleanliness/convenience/readability...

As you can see in the original hand-controls, the url is just stored hardcoded and copy/pasted: https://github.com/aframevr/aframe/blob/2c4509aa1a9a3c447c08be9facfea0c7d6a9e156/src/components/hand-controls.js#L5

No inheriting necessary, or indeed really possible I think--pretty sure those URLs are wrapped up as private variables that there is no external access to and only visible to that component.

Also, that shouldn't be being used if you're specifying custom models yourself I think. Can you show an example where you are specifying a custom hand model URL but you still see the CDN request? Again, didn't really test this feature, just threw it in there as a draft concept in case someone might want it in the future.

Does the 'someone else' have controllers simulated or attached/active?

And you are saying that the canonical example on naf-examples.glitch.me doesn't work for you, right? What headset are you using?

hand-tracking-controls doesn't really have anything to do with hand-controls or networked-hand-controls, so I'm not sure what to glean from the last edit.

I'll try on my quest tomorrow and check to see that something hasn't broken in a recent browser update, I guess. For me, I'm seeing that my chrome extension for emulating a webxr session appears to have been broken presumably with recent browser updates, so I can't test the controller functionality itself on my browser at the moment.

[vincentfretin]

I just tested the tracked controllers example on Quest, I see the hand and controller.

[Utopiah]

I just tested the tracked controllers example on Quest, I see the hand and controller.

Very strange, just tried again with a Quest 1 (freshly reset from yesterday) and Quest 2, both with latest OS and same problem, no hands.

[Utopiah]

MODEL_BASE

You are correct, I meant MODEL_URLS which I discovered via aframevr/aframe@d56b570 yet I'd argue they have similar if not the same role. Consequently up to you to see if decoupling is better.

(Apologies for being to sparse with answers right now but desktop crashed due to a powercut so not ideal situation)

[Utopiah]

Just tried on another Quest 2 on another physical network and have the same problem, no hands visible in the official example on Glitch.

[kylebakerio]

That pull request snippet is actually referring to exactly the privately scoped variable I pointed to before, here: https://github.com/aframevr/aframe/blob/9d0a60392740e4a3de43b8f68f9234a679ca7575/src/components/hand-controls.js

If you look for MODEL_URLS in aframe's repository, that's the only place it shows up. No way for us to inherit that unless we started offering a custom A-Frame build along with NAF, or did some very gross raw github file lookup... neither of which I think are directions that makes sense for us. ;)

---

As for the missing hands:

I also just tested in a quest 2, and I also found the controller and hand both visible for me.

My guess would be something about the CDN isn't working for you...? Can you try just accessing the url directly from your quest browser and seeing if that succeeds or fails--or, ideally, hooking up chrome dev tools to observe what the network request for the model (and its response) look like?

Another option is some other error occurring for some reason that is interrupting the initialization of the hands. Would need dev tools to confirm. Could try spinning up a version that has a console instead, though.

Very odd.

[kylebakerio]

btw, @vincentfretin I did notice the controller buttons weren't moving when I pressed them. are we using the latest master aframe build there that adds this in? We aren't, and that's why I don't see it, right?

[kylebakerio]

@Utopiah if both the custom model url and the default model url both fail for you, in theory some other error could be causing both. But I am not sure what error that could be that is occurring on the canonical naf-examples demo just for you but not for either of us.

Checked via the remote debugging console and spot no error (beside a missing favicon).

But it sounds like you've done this, and also thus confirmed that there are no errors...??? And you checked the network requests and see a successful request for the model?

Sounds very strange. Glad you reported, but so far there's no clues to follow on our end and no way to reproduce, it sounds like.

[vincentfretin]

btw, @vincentfretin I did notice the controller buttons weren't moving when I pressed them. are we using the latest master aframe build there that adds this in? We aren't, and that's why I don't see it, right?

Yes we're using aframe 1.3.0 in the examples, not a master build, that's why.

[kylebakerio]

Also seems to work in emulated desktop with chrome extension, btw:

@Utopiah have you tried using the webxr emulator?

[Utopiah]

This is what I see :

which does load the glb

yet does not show them

[kylebakerio]

quite odd. I do see that it's in tablet mode, wondered if that was related, but didn't seem to matter:

I don't have these color & material warnings show up, though...? Maybe that's relevant? Only clue I see here.

[kylebakerio]

if you 'exit vr' and then re-enter vr on the desktop emulator, do the hands then appear for you? what logs do you get then?

[Utopiah]

Using the emulator 0.3.3 with Chromium version 108.0.5305.0 (Developer Build) (64-bit) I do see that yellow hand model also but I fail to see how that is relevant if I don't see it in the headset.

[kylebakerio]

For debugging purposes, I guess. reaching at straws, trying to figure out what is going on, hard to debug at a distance with supposedly no errors or warnings and unable to replicate locally.

It's not just yellow hand model but also controller model... Actually, that's also interesting: you see neither hand nor controller model, right? Both are failing for you in headset? In both our demo and in your own copy of the code?

[Utopiah]

It's literally the Glitch link, without any modification to either code nor headset, even after a hardware reset.

[kylebakerio]

I'm curious about those warnings that were shown on yours. Why are you getting swapchain request/ignore, and flatshading? What OS/browser are you on? That's the only clue I see right now.

Next step would be coding up custom demos to chase this down. One might be to just statically display the models in your scene and make sure they can display at all. If that works, then the next thing would be putting breakpoints throughout the init chain of the networked-hand-controls component and seeing what shows up. Maybe duplicating the original demo but only showing one or the other of the hand or controller, to see if removing one allows the other to show up?

[Utopiah]

Using the Oculus browser, latest version