Neck model?

[rpavlik]

trafficstars

If we don't have positional data for head, should we presumably be pulling a neck model internally to produce a better /me/head? and seated/standing?

[feilen]

I vote for adding a neck model, as even though it's likely to be obsolete as soon as the hacker kit has positional tracking, this is meant to be a general VR implementation (and many mobile VR solutions have no positional tracking data)

I remember with TF2 before positional tracking was added that having a neck model made a world of difference as far as motion sickness.

[rpavlik]

Yeah, one device having positional tracking doesn't magically give that to all of them :-) I think right now the individual game engine integrations have the neck model in them, vs. having one integrated into the core/server.

[feilen]

I imagine they do, and that's hardly ideal. User profiles integrating neck models would work far better.

On Fri, May 29, 2015 at 6:25 PM, Ryan Pavlik [email protected] wrote:

Yeah, one device having positional tracking doesn't magically give that to all of them :-) I think right now the individual game engine integrations have the neck model in them, vs. having one integrated into the core/server.

Reply to this email directly or view it on GitHub https://github.com/OSVR/OSVR-Core/issues/135#issuecomment-106950702.

[JeroMiya]

Would it be common for applications to want raw orientation data in one context and a neck-model simulation in another for the same /me/head semantic path, or would you just always simulate the neck model for /me/head for devices with no position tracking?

[DuFF14]

Good question @JeroMiya. @rpavlik What is the current status with this? It looks like if I use the following config file, there is no head/neck model:

"display": "displays/OSVR_HDK_1_1.json",
"renderManagerConfig": "sample-configs/renderManager.direct.portrait.json"

but adding the default configuration for video tracking does add a neck model even if there is no camera attached:

        "drivers": [{
        "plugin": "com_osvr_VideoBasedHMDTracker",
        "driver": "VideoBasedHMDTracker",
        "params": {
            "showDebug": false,
            "includeRearPanel": true,
            "headCircumference": 55.75,
            "calibrationFile": "videotrackerCombinedCalibrationFile13.json"
        }
    }, {
        "plugin": "org_osvr_filter_videoimufusion",
        "driver": "VideoIMUFusion",
        "params": {
            "name": "HeadFusion",
            "input": {
                "imu": "/com_osvr_Multiserver/OSVRHackerDevKitPrediction0/semantic/hmd",
                "faceplate": "/com_osvr_VideoBasedHMDTracker/TrackedCamera0_0/semantic/hmd/front"
            },
            "eyeHeight": 0,
            "cameraIsForward": true
        }
    }],
    "aliases": {
        "/headSpace": {
            "translate": [0.0, 0.0, 0.04141],
            "child": "/org_osvr_filter_videoimufusion/HeadFusion/semantic/fused"
        },
        "/me/head": "/headSpace"
    }

with the 'translate' field accounting for the offset from the origin.

@VRguy and I experimented with some different values for horizontal and vertical eye-to-neck distances and found that

"translate": [0.0, 0.0805, -0.075]

resulted in a more natural head rotation in-game. Was this property essentially meant to be our head/neck model? How does changing this affect our positional tracking algorithm?

[VRguy]

We probably want to clean up how we specify what we are tracking and make this parameter either change automatically based on what is detected or at least through the OSVR config utility.

When running without positional tracking, we are only tracking head orientation, so "translate": [0.0, 0.0805, -0.075] shows nominal eye position relative to rotation center.

When running with positional tracking on HDK, we are tracking front plate, so eye position is something like "translate": [0.0, 0.0, 0.04] relative to tracked object

(units are in meters)

On Wed, Apr 20, 2016 at 12:16 PM, Greg Aring [email protected] wrote:

Good question @JeroMiya https://github.com/JeroMiya. @rpavlik https://github.com/rpavlik What is the current status with this? It looks like if I use the following config file, there is no head/neck model:

"display": "displays/OSVR_HDK_1_1.json","renderManagerConfig": "sample-configs/renderManager.direct.portrait.json"

[image: no_neck_model] https://cloud.githubusercontent.com/assets/10972018/14680842/b1a18128-06ec-11e6-9b8e-2b3624874302.gif

but adding the default configuration for video tracking does add a neck model even if there is no camera attached:

    "drivers": [{
    "plugin": "com_osvr_VideoBasedHMDTracker",
    "driver": "VideoBasedHMDTracker",
    "params": {
        "showDebug": false,
        "includeRearPanel": true,
        "headCircumference": 55.75,
        "calibrationFile": "videotrackerCombinedCalibrationFile13.json"
    }
}, {
    "plugin": "org_osvr_filter_videoimufusion",
    "driver": "VideoIMUFusion",
    "params": {
        "name": "HeadFusion",
        "input": {
            "imu": "/com_osvr_Multiserver/OSVRHackerDevKitPrediction0/semantic/hmd",
            "faceplate": "/com_osvr_VideoBasedHMDTracker/TrackedCamera0_0/semantic/hmd/front"
        },
        "eyeHeight": 0,
        "cameraIsForward": true
    }
}],
"aliases": {
    "/headSpace": {
        "translate": [0.0, 0.0, 0.04141],
        "child": "/org_osvr_filter_videoimufusion/HeadFusion/semantic/fused"
    },
    "/me/head": "/headSpace"
}

with the 'translate' field accounting for the offset from the origin. [image: neck_model] https://cloud.githubusercontent.com/assets/10972018/14680844/b5c4a7a8-06ec-11e6-85c8-095c6f9dd83d.gif

@VRguy https://github.com/VRguy and I experimented with some different values for horizontal and vertical eye-to-neck distances and found that

"translate": [0.0, 0.0805, -0.075]

resulted in a more natural head rotation in-game. Was this property essentially meant to be our head/neck model? How does changing this affect our positional tracking algorithm?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/OSVR/OSVR-Core/issues/135#issuecomment-212496615

Yuval Boger CEO | VRguy http://www.vrguy.net Sensics, Inc. http://www.sensics.com

Latest news and blog posts (subscribe here http://sensics.com/subscribe-to-our-mailing-list/ to get weekly updates):

13 Apr: VRguy podcast Episode 6: Sam Rosen, ABI Research on VR Pricing, Customer-facing AR http://sensics.com/vrguy-podcast-episode-6-sam-rosen-abi-research-on-vr-pricing-customer-facing-ar/ 11 Apr: Understanding Foveated Rendering http://vrguy.blogspot.com/2016/04/understanding-foveated-rendering.html 06 Apr: VRguy podcast Episode 5: Francesco Radicati, Ovum, on mobile VR and where VR will be used at Home http://sensics.com/vrguy-podcast-episode-5-francesco-radicati-ovum-on-mobile-vr-and-where-vr-will-be-used-at-home/

[rpavlik]

Yeah, those transforms above actually belong in the plugin or the plugin device descriptor. The design of the unified tracker incorporates such offsets (that an optical target or an imu might be at a different location than the origin of the tracked body), to do the same with the current setup would involve modifications in the video imu fusion plugin. (In all cases, that 0.04... offset should really be in the transform in the device descriptor, but last time I tried that, I managed to actually crash jsoncpp somehow.)

[russell-taylor]

Remember that the origin in an orientation-only tracker doesn't have any special place. In that case, putting it at the origin rather than at the 0.04141 offset keeps the world from having its objects translate the wrong direction when the head rotates. So that offset should not be present in the systems without video tracking. If they are, then the head/neck model has to compensate for them in addition to its offset.

A head/neck model is, as probably already mentioned, not appropriate when we're doing video/based tracking or otherwise have positional info available.

[VRguy]

but since the eyes are not in the same place as the center of head rotation, a head/neck model that offsets the eyes seems to work very well in rotation-only systems. And yes, this causes the eyes to translate when the head rotates, and it's a good thing

On Sun, Apr 24, 2016 at 8:01 AM, Russell Taylor [email protected] wrote:

Remember that the origin in an orientation-only tracker doesn't have any special place. In that case, putting it at the origin rather than at the 0.04141 offset keeps the world from having its objects translate the wrong direction when the head rotates. So that offset should not be present in the systems without video tracking. If they are, then the head/neck model has to compensate for them in addition to its offset.

A head/neck model is, as probably already mentioned, not appropriate when we're doing video/based tracking or otherwise have positional info available.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/OSVR/OSVR-Core/issues/135#issuecomment-213947815

Yuval Boger CEO | VRguy http://www.vrguy.net/ Sensics, Inc. http://www.sensics.com/

Latest news and blog posts: 21 Apr: Open Source Virtual Reality ("OSVR") Welcomes Acer http://sensics.com/open-source-virtual-reality-osvr-welcomes-acer/ 20 Apr: VRguy podcast Episode 7: Layla Mah, Insightful VR, on the evolution of GPUs for VR http://sensics.com/vrguy-podcast-episode-7-layla-mah-insightful-vr-on-the-evolution-of-gpus-for-vr/ 13 Apr: VRguy podcast Episode 6: Sam Rosen, ABI Research on VR Pricing, Customer-facing AR http://sensics.com/vrguy-podcast-episode-6-sam-rosen-abi-research-on-vr-pricing-customer-facing-ar/

[russell-taylor]

Yes, indeed.