40 ms·

> there's nothing we can do about the lack of virtual acceleration cues. I think we're not talking about the same thing. I don't see how it could be a cause of

> there's nothing we can do about the lack of virtual acceleration cues. I think we're not talking about the same thing. I don't see how it could be a cause of simulator sickness, which I thought had to do with eye strain from focal points not being correct, and the inner ear. Proprioception is a sense like the ordinary 5 senses, the perception or awareness of the position and movement of the body. It is what makes our body feel like our body. Dissociation, caused by dissociatives, can cause inanimate external objects to feel like they are part of us, which could be considered chemically hacking proprioception. The wooden arm illusion is another way to hack proprioception using touch to reinforce the sense of it. But VR should be able to do this without chemistry or touch, because visual clues reinforce the sense of proprioception. VR can really be the wizbang killer app, but it isn't. Maybe they show you a virtual arm and you see yourself manipulate it, but it doesn't feel like your arm (I am not talking about the feeling of touch). That is how they are ignoring proprioception. And it doesn't have to be an arm, because in VR, you don't have to be human. It should be possible to blow the wooden arm illusion out of the water with VR, and have ten arms, and they all feel like they are distinctly your arms. But we don't see that, and no one is working on it. All we get is a stiff arm without natural reticulation. So it is fair to say developers are ignoring proprioception, because they are unaware of their own sense of proprioception (like knowing where your hand is without looking at it). Proprioception should be of primary concern in Virtual Reality. They should toss everything, and start all over again with inducing proprioception as the prime driver of the technology. > As for your question about distance, I suspect you're looking for "accommodation". Accommodation is the physical distortion of the eye to change the focal distance of the lens. Combined with vergence (the distance at which our binocular vision rays converge), the two systems work together to give you a sense of how far away something is (among other things, like atmospheric hazing, parallax, and trained memory of similar objects). Most modern VR systems lack the ability to account for accommodation, leading to what is called "vergence-accommodation conflict". It can be a source of eye-strain for some people, but it tends to be adaptable over time. Interesting, but complicated. Should be called "apparent display distance," or something simple and easy to understand. Still, gives me more information. Appreciated.

satokema 4y ago
A non-trivial number of VR users experience phantom sense of varying strength, including myself. Proprioception is not the only thing being consulted here, seeing someone touch what visually seems like your face is a common low-level manifestation of this. It's possible to be in an avatar and have someone touch the avatar's tail and somehow weirdly you can feel like "your tail" is being touched (albeit you feel it in your tail bone). Maybe the technology to better integrate more brain variants will eventually exist, but current VR tech already has a niche to cater to and develop from.
- Maursault 4y ago
  > A non-trivial number of VR users experience phantom sense of varying strength, including myself. You have elegantly spotlighted the problem. Call me when they all experience it, always and every excursion into the virtual. Then we'll know VR developers have finally started paying attention to proprioception.
moron4hire 4y ago
Even this, what you are saying about "virtual arms", has been tried. Inverse-kinematic self-avatars were a big thing within the industry about 5 years ago. And it was... largely not that important. Without a tracking point for the elbow, it's nearly impossible to do IK for limbs. Remember, a double-pendulum is a chaotic system. A small perturbance can lead to dramatic divergence between simulated and actual state in chaotic systems. That said, it's still possible to get body sense in VR, for the head, main torso, arms, and especially hands. It's hard to do. And when things are hard like this, there are economics of scale to consider. For example, the Quest 2 has native hand tracking built in, but not a lot of other VR systems do, and the ones that do often have dramatically different APIs (though OpenXR helps a lot here, which shifts the problem to whether or not the system in question has an OpenXR-compliant driver). Do you go all in on one platform and support its input modalities to the maximum degree? Or do you try to target the common denominator between a broader swath of the market. Non-VR consumer software developers get to develop their software in an environment of operating systems that have well-established UI and UX metaphors. You make a button in WxWidgets or UWP or SwiftUI or HTML and that button comes with a LOT of functionality that you don't have to program yourself. We don't have that in VR. To make a button in a game engine for a VR game you basically have to implement that entire thing yourself. Oh, the game engine probably gives you a raycaster to be able to find objects, but you have to program up where that raycaster should be firing, which objects you should be interested in, and what interactions hitting the buttons on your controller map to how the button in the view reacts. To a large degree, every VR developer has to reinvent the world when they make something. We're working on the very edge of performance that these systems can eke out. We don't have shared UI metaphors, but not for lack of trying. There are several projects underway attempting to do just that. MRTK and StereoKit in particular have put a lot of work into just that. But they aren't for everyone. They can't do everything. It'd be like expecting Call of Duty to be implemented strictly in Win32 controls. And the input modalities are so much more diverse and non-standardized than desktop mouse-and-keyboard that I doubt there will ever be a one-size-fits-all UI toolkit for VR. I reassert that you are not being fair to the VR industry. Everything you have talked about so far has been tried and either found to not be worth the complexity or not possible to do within the current constraints.

satokema 4y ago

A non-trivial number of VR users experience phantom sense of varying strength, including myself. Proprioception is not the only thing being consulted here, seeing someone touch what visually seems like your face is a common low-level manifestation of this. It's possible to be in an avatar and have someone touch the avatar's tail and somehow weirdly you can feel like "your tail" is being touched (albeit you feel it in your tail bone). Maybe the technology to better integrate more brain variants will eventually exist, but current VR tech already has a niche to cater to and develop from.

Maursault 4y ago
> A non-trivial number of VR users experience phantom sense of varying strength, including myself. You have elegantly spotlighted the problem. Call me when they all experience it, always and every excursion into the virtual. Then we'll know VR developers have finally started paying attention to proprioception.

moron4hire 4y ago

Even this, what you are saying about "virtual arms", has been tried. Inverse-kinematic self-avatars were a big thing within the industry about 5 years ago. And it was... largely not that important. Without a tracking point for the elbow, it's nearly impossible to do IK for limbs. Remember, a double-pendulum is a chaotic system. A small perturbance can lead to dramatic divergence between simulated and actual state in chaotic systems. That said, it's still possible to get body sense in VR, for the head, main torso, arms, and especially hands. It's hard to do. And when things are hard like this, there are economics of scale to consider. For example, the Quest 2 has native hand tracking built in, but not a lot of other VR systems do, and the ones that do often have dramatically different APIs (though OpenXR helps a lot here, which shifts the problem to whether or not the system in question has an OpenXR-compliant driver). Do you go all in on one platform and support its input modalities to the maximum degree? Or do you try to target the common denominator between a broader swath of the market. Non-VR consumer software developers get to develop their software in an environment of operating systems that have well-established UI and UX metaphors. You make a button in WxWidgets or UWP or SwiftUI or HTML and that button comes with a LOT of functionality that you don't have to program yourself. We don't have that in VR. To make a button in a game engine for a VR game you basically have to implement that entire thing yourself. Oh, the game engine probably gives you a raycaster to be able to find objects, but you have to program up where that raycaster should be firing, which objects you should be interested in, and what interactions hitting the buttons on your controller map to how the button in the view reacts. To a large degree, every VR developer has to reinvent the world when they make something. We're working on the very edge of performance that these systems can eke out. We don't have shared UI metaphors, but not for lack of trying. There are several projects underway attempting to do just that. MRTK and StereoKit in particular have put a lot of work into just that. But they aren't for everyone. They can't do everything. It'd be like expecting Call of Duty to be implemented strictly in Win32 controls. And the input modalities are so much more diverse and non-standardized than desktop mouse-and-keyboard that I doubt there will ever be a one-size-fits-all UI toolkit for VR. I reassert that you are not being fair to the VR industry. Everything you have talked about so far has been tried and either found to not be worth the complexity or not possible to do within the current constraints.