Skip to main content
Up and Coming
July 2, 2014

Positional Tracking and Collisions

I've done a bit of searching... how are people going to handle the clipping/collisions/bounding of the head/cameras once positional tracking is here?

It seems to me that the head will need a separate bounding box and the camera will have to be restricted to that. Is that something that will be in the next DK2 version of the Oculus SDK, or are we all going to come up with our own implementations?

    49 replies

    xhonziAuthor
    Up and Coming
    July 7, 2014
    "2EyeGuy" wrote:
    "xhonzi" wrote:
    Nausea guaranteed?

    I'm not sure.

    In real life I am not able to put my head through the wall and a headache is what I can expect if I try too hard.

    Reality confirmed?

    I'm sure.
    The Rift is not like real life in that we can't stop the head from moving, and if the head moves but your vision doesn't, you get motion sick.


    Hey, look! It's 2EyeGuy!!! What happened to you, man? (go to the metroid thread!)

    I agree that when the player moves his head and the simulation doesn't represent it is the number one cause of nausea. However: What should the user expect when he puts his face through a wall/table/etc? How often is a user actually going to try this? I think the nausea is a result of expectation vs reality- When there's no reason to expect your vision to not react to your head movements- nausea. But if it's a solid object- I think a collider is more natural. More natural = closer to reality = no nausea.

    This write-up by Doc Ok perhaps does a better job of explaining my thoughts:
    http://doc-ok.org/?p=785
    Up and Coming
    July 7, 2014
    If you don't want to fade to black, a different alternative is to push the player position back by the inverse amount of head motion.
    Twitter IndieDB
    Up and Coming
    July 7, 2014
    Simply put, you couldn't avoid doing a proper camera hitbox. Fading to black isn't good enough to remove the clipping artifacts you'd get with the camera going through a wall.

    "n00854180t" wrote:
    If you don't want to fade to black, a different alternative is to push the player position back by the inverse amount of head motion.


    That sounds more like what you should be doing, if you can't live with clipping.
    DK1 FREAK ...
    Up and Coming
    July 7, 2014
    @obzen - yeah I think that's what I'm going to do for my game. I'm not the biggest fan of the fade to black, though it seems like it works pretty well. I personally just don't like the idea of the player being taken out of the game in that way.

    I might add the fade to black as an option, or implement it first just because it should be a bit easier to get working reliably and smoothly (i.e., raycast short distance from the face, if it hits anything, fade to black).
    Twitter IndieDB
    Up and Coming
    July 7, 2014
    "n00854180t" wrote:
    @obzen - yeah I think that's what I'm going to do for my game. I'm not the biggest fan of the fade to black, though it seems like it works pretty well. I personally just don't like the idea of the player being taken out of the game in that way.

    I might add the fade to black as an option, or implement it first just because it should be a bit easier to get working reliably and smoothly (i.e., raycast short distance from the face, if it hits anything, fade to black).


    I suppose if you cannot solve the system (character stuck, ect...), you'd want some way to tell the player that what he is doing is not advisable unless he is some kind of contortionist.

    I would maybe try to put the camera collision hitbox on some kind of a spring, thus giving you a more natural constraint on the character, while also being able to quantify the error (the more force generated, the more fade required). Fade to black? I don't know. Maybe a blur shader instead (pass the bucket).

    Just an idea. Probably needs some experimentation.
    DK1 FREAK ...
    Up and Coming
    July 7, 2014
    That's true - it might be necessary to have both systems in place, so that if pushing the player body fails, it can still handle that case and do something to prevent nausea.

    I think that setup (push the body first, if it fails, fade to black) would be good enough for most situations in a first person game.
    Twitter IndieDB
    Up and Coming
    July 8, 2014
    Wouldn't pushing the players avatar in the opposite direction have exactly the same effect on the player as cutting out position tracking except for getting it back sooner when you pull back your head.

    I dont really get where all this opposition to fade to black is coming from, just imagine its the effect of being knocked unconscious as you slam your head against the wall. Does this happen in real life, no, but neither do you get dizzy from the sensation of your head continuing to move while your view dose not. In real life your head is stopped by a barrier there is no way to simulate that unless you attach a helmet to a giant robot arm. If you give your players too much motion sickness they will quit playing your game and send you hate mail instead, how immersive is that? If the camera starts fading just before it collides with wall the player should quickly learn there is nothing interesting to see by pressing there head further where it goes completely black without the extra deterrent of motion sickness required.

    Also remember: "different peoples is different" What is comfortable for you may not be comfortable to others, so customization is good but it will also give you more programming to do if its not integrated into the SDK. And the default should be what has done best in surveys not what you personally prefer.

    The number one golden rule of VR is never take control of the camera away from the HMD or they will vomit.
    Up and Coming
    July 8, 2014
    I can't say I was ever tempted to focus in past the boundaries of an object while trying the DK2. Not saying it's something we shouldn't plan for, but I think unless you're purposefully trying to break the experience it's just something you don't do.
    Up and Coming
    July 8, 2014
    "mrmonkeybat" wrote:
    Wouldn't pushing the players avatar in the opposite direction have exactly the same effect on the player as cutting out position tracking except for getting it back sooner when you pull back your head.


    YES, it would. Adjusting the player position would still cause unexpected visual mapping to brain anomalies. The head is moving forward but suddenly the neck stops pivoting as it should, while the eyes could retain their position (so I can see what the suggestion is getting at) it doesn't factor in movement, only visuals. The head isn't hitting anything in reality so to block it in virtual reality (by cheating and moving the body back like you suddenly have ghost legs) loses 1:1 mapping = nausea.


    fade. to. black (quickly)
    EX DK2/VIVE/PSVR/CV1/Q2/PSVR2 | Currently Quest Pro (PCVR) | VR developer RTX 3080 FE / 12900k / Windows 11 Pro
    xhonziAuthor
    Up and Coming
    July 8, 2014
    "mrmonkeybat" wrote:
    I dont really get where all this opposition to fade to black is coming from.


    I don't prefer it because it seems to me to be the greater of two evils.

    Colliders
    Pro:
    Like reality- you can't stick your face through solid objects.

    Con:
    Possibly leads to nausea.

    Fade to Black
    Pro:
    Prevents camera control from being taken from the player. Possibly less nausea.

    Con:
    Immersion breaker.

    Head into walls or other solid objects is an outside case. It's not something that we should expect a player is going to do either intentionally or unintentionally frequently or for long periods of time. I think the momentary ill feeling (should it actually occur in this specific case) of nausea will disappate more quickly than the feeling of broken immersion caused by the to-black-fading.

    However, none of us really know how strong either effect will be until we get some testing done. I assume Oculus has done this testing and I would like to know what their take on it is. I'm a little disappointed at their silence in this thread. I think there's a good chance that they've put some of their preferred implementation into the forthcoming SDK.