Positional Tracking and Collisions

"molton" wrote:
If I lean into a wall with my head, my head will stop. Not a huge immersion breaker in that regard, perhaps leaning your head against the wall can just move your player controller away from the wall so your camera is still moving in that direction, just when you return to center your body might be in a different position. fading to black when at a wall sounds worse than that, but there's only one way to find out. Can't wait for them DK2's to ship out.

"n00B" wrote:
Go stand on a slick surface with socks on, next to a wall. Push your head into the wall. Your feet will slide back. Thus the idea.

Yeah, that. I hope I don't get yelled at like you did :)

So, you're telling me that when you lean your head into a wall in-game and continue to try to push your head farther, your head in real life will stop? I was completely unaware that the Rift has that type of feedback already. Go ahead and create a game that totally induces motion sickness and nausea. When your players aren't capable of playing the game for 5 minutes because you refuse to allow them to always have control of the head in-game, then maybe consider the possibility that other developers have already tested this and found the best solution right now.

.....

"n00854180t" wrote:
Some people just don't understand that if you're moving the character back, the head of the player, and the camera in game, both still move. Imagine that.

Yes the head of the player and the camera in game move relative to the body of the player, but DO NOT MOVE relative to the rest of the world, which is the point of reference of your eyes so is what counts here.

Your eyeballs in real-life are moving through space, your eyeballs in in VR are not, so if you do that it is very likely that you will induce simulation sickness, Sharpfish is right.

But please stop insulting one another.

What I find hilarious is that if everyone had the attitude some people here are expressing, that the way to progress and figure things out is to just go "IMPOSSIBIRU" and throw up their hands, the Rift wouldn't even exist. :lol:

"n00854180t" wrote:
What I find hilarious is that if everyone had the attitude some people here are expressing, that the way to progress and figure things out is to just go "IMPOSSIBIRU" and throw up their hands, the Rift wouldn't even exist. :lol:

It's not that we're not willing to experiment, it's just that some people are not willing to accept known facts. Some people are just so dense that I think they may try to argue against real-world gravity next.

EDIT: To clarify, any time that your visual feedback does not match your real-life head movement, you WILL get motion sick. There is no way around that unless we had full-dive VR where we can simulate the movement of the fluid in your ears.

Wow I didn't realise this could be a problem, but I guess any movement of the camera that isn't initiated by the player can potentially cause nausea.

Clearly the player can't enter geometry such as a wall and moving , stopping or bouncing the camera can cause nausea so the logical thing to do is to take the camera out of the equation.

I'm guessing the best thing to do is:
Fade to black, the camera hasn't intersected the geometry but the player is unaware of the camera stopping because the screen is black.
perhaps a bump noise too?

I'm not sure what the effect would be like if you hit a wall at a shallow angle like running down a corridor hugging the wall?

Use case A : when headbanging a wall head on.
when we go too close to a wall in reality we
1. Loose focus : blur
2. Light levels dim : brightness^-1

On collision do : ( convolve / floor ( ( headPos - WallLimit ) ) )* ( 1 - Normalise(headPos - wallLimit )


Dumb man posting via smart phone, please forgive.

b

At the risk of getting back on topic-

I've been messing with this a bit in Unity with my DK1 and my chest mounted Hydras. For the record- position tracked hands have a similar problem- how to handle collisions in the virtual space that aren't enforced by the physical space. I assume that even those who favor uninhibited camera movement are for inhibited virtual hand movement, but I could be wrong.

I figure regardless of whether the best solution is one of these two or something else, chances are it will involve a collider around the camera object.

First thing I noticed- It's easy to create a collider on the camera that will keep your player object from moving. :lol: There's a method for ignoring collisions betwixt two specfic objects and another one that ignores collisions betwixt any object in layerX and any object in layerY. I guess I need to try playing with those.

However there is also this other option- the istrigger property ignores all collisions and just reports when the trigger collider intersects another collider. Easy enough. If you're going the fade-to-black route, I guess you set istrigger on the collider and you're almost done.

For the other possible solution- I assume you would use a collider (not a trigger) and you'd have to rely on the the collider exceptions to prevent colliding with the player capsule. But I think the problem here is that colliders only work when forces are moving the objects around (not discreet changes to the transform). Someone correct that if you can. We'll have to wait and see how that positional tracking code looks once we get the DK2 SDK, but if it's not done with forces, we may be in trouble.

An easy way would be something like this (with triggers or colliders):

Vector3 oldPos=OVR.position;
updatePositionalTracking;
if camera.trigger.triggerenter(collider) { OVR.position = oldPos;}

Unfortunately, that would block any movement that would lead to a collision, not just the component of the movement that is blocked. That probably involves some math that I'm not prepared to do. There's likely a slick way of doing it- involving quaternions and other stuff- but I don't know it.

The collider class already does all of that, but again it comes down to movement by force or movement by discreet transform manipulation. (maybe). That seems like the next thing to invetigate.

The usual method of 3rd person camera collision is using a swept volume (sometimes called a probe, or trace), from the head position (which should be safe), towards the desired camera position. Dunno about Unity, but it should have similar collision queries. Sometimes, this are batched with other collision jobs, but anyway...

Vector direction = (camera.position - player.head.position);
float distance = direction.length();
float radius = rendering.frustum.nearPlane * 1.10f + 0.01f; (usually, something around the near plane distance of your rendering frustum).

// test collision with world, with a few exceptions.
CollisionInfo collisionInfo = world.collideSweptSphere(player.head.position, radius, direction, distance, FLAG_IGNORE_PLAYER | FLAG_IGNORE_PROJECTILES | FLAG_IGNORE_PROPS);

// something in the way
if(collisionInfo.collided)
{
    // move camera to a safe position to avoid geometry rendering clipping (or maybe not!).
    camera.position = player.head.position + (direction * collisionInfo.distance);
    
    // do some vision blur shenanigans.
    float intersectDistance = (distance - collisionDistance);
    rendering.blurVision = maths.clamp((rendering.blurDistanceLimit - intersectDistance) / rendering.blurDistanceLimit, 0.0f, 1.0f);

    // do some vision dim shenanigans.
    rendering.dimVision = maths.clamp((rendering.dimDistanceLimit - intersectDistance) / rendering.dimDistanceLimit, 0.0f, 1.0f);

    // render player with translucency (where we're too close to the character model).
    player.translucency = clamp(ect....);
    }
}