Should an empty profiles array be used to indicate no controller should be rendered?

[AdaRoseCannon]

This situation occurs whenever the input's physical device is visible in other ways.

This has come up in discussions a couple of times and isn't addressed in the spec as far as i can tell.

[AdaRoseCannon]

cc @brianchirls

[AdaRoseCannon]

For regular inputs the easiest way to tell if a controller is squeeze capable is a generic entry in the input profiles but if the profile array is empty then it's not possible.

I think the issue is that rendering and behaviour descriptions are joined from the profiles array.

[AdaRoseCannon]

Perhaps the correct approach would be an empty none.glb in the webxr input profiles repo for the controller.

Or perhaps defining a some new generics which don't get rendered at all but still contain the information about the buttons exposed through gamepad but with empty nodes in the actual model.

Something like 'generic-****-invisible'

[AdaRoseCannon]

/tpac anyway lets chat about this at TPAC

[Manishearth]

I think none.glb is a good way of going about it

[AdaRoseCannon]

Yeah, I am also beginning to feel the same, we should probably document how non-renderable stuff should be handled even if it doesn't involve an actual spec change, just some extra generic input profiles.

[toji]

Given that the input profiles serve two parallel purposes (input visualization and capability detection) I'd also advocate for not omitting an input profile string unless the implementation legitimately has no idea what kind of input it's dealing with. In the case of something like hands, it's still important to communicate things like if squeeze is supported, so an accurate input profile list should still be returned.

Providing an empty glTF for rendering is a good way to "trick" implementations into doing the right thing, but that only works if all instances of that particular input profile across all platforms shouldn't be visualized. It's easy to imagine that one platform would expect generic-hand to render a skinned hand because they have no passthrough, while another would have an OS-level hole punching visualization of the user's actual hands, and applications would want to handle both as elegantly as possible. That argues for Ada's suggested *-invisible profiles as a specialization of an otherwise visible input. I'd probably expect something like ['generic-hand-invisible', 'generic-hand'] to be the returned array.

Also worth nothing that the "invisible" hand model still might need a full skeleton so that anyone downloading the asset and blindly skinning it doesn't start failing in unexpected ways.

[AdaRoseCannon]

TPAC result: There should be some sort of enum to say that rendering is handled elsewhere.

But could still do the input profile as invisible or empty.