Attribute name |
Type |
Default value |
postracking | String | "auto" |
- Enable VR Positional-Tracking.
- Requires a VR headset with positional-tracking support, otherwise it has no effect.
- The current position will be added to the view.tx/ty/tz settings.
- When positional-tracking is available the onhavepostracking event will be called.
- Available settings:
- auto - Automatically enable positional-tracking when using depthmap-panos.
- true - Always enable positional-tracking (when available by the VR hardware).
But note - normal panoramic images would get distorted when not viewed from their normal image-center!
- false - Always disable positional-tracking.
|
Attribute name | Type | Default value |
hlookatoffset | Number | 0.0 |
- A custom offset to the horizontal looking position (view.hlookat) in degrees.
- Can be used to rotate the view independently and additionally to the users viewing.
|
Attribute name | Type | Default value |
oversampling | Number | 1.0 |
- An oversampling scale-factor for the rendering resolution.
- Higher values will increase the image-quality, but require more GPU processing power.
- Lower values will lower the image-quality and require fewer GPU processing power.
|
Attribute name | Type | Default value |
auto_oversampling | Boolean | true |
- When enabled apply an automatic additional oversampling factor depending on the actual VR headset.
- This is done because the default resolution provided by the device is lower
then the resolution that the device would be capable of for performance reasons.
- The added oversampling factor improves image-quality at cost of a little performance.
- When higher and more stable framerates are more important than image-quality consider disabling that setting or using a lower
oversampling setting.
- Supported headsets:
- For Oculus Go and Oculus Quest a factor of ~1.4 will be automatically added.
- Custom oversampling settings will be respected and a too high oversampling
factor automatically avoided.
|
Attribute name | Type | Default value |
zoom | Number | 1.0 |
- Apply a custom zoom-scale to the VR view.
- Should be used very carefully and only for special cases!
|
Attribute name | Type | Default value |
friction | Number | 0.0 |
- A value between 0.0 and 0.999
- Add a fricition to reduce the gyro responsive speed.
- Should be used only for high zoom values to reduce shaking, but never for normal viewing!
|
Attribute name | Type | Default value |
headtracking | Boolean | true |
- By setting headtracking to false, it would be possible to disable the headset-movement-tracking and
control the viewing direction by yourself by changing the view settings.
- Warning - disabling this settings is NOT recommended!
-
Changing the viewing direction in VR different to the users head movement is a bad experience.
And on systems with 're-projection' (HTC Vice, Oculus Rift) this can cause graphical errors, because
these systems doesn't assume that the view will change different to the head-movement.
|
Attribute name | Type | Default value |
headtracking_absolute | Boolean | false |
- Use an 'absolute' head tracking when possible.
- When enabled the looking direction should be linked to the real world one.
- When disabled (the default) the looking direction is relative to the startup looking direction when entering the VR mode.
|
Attribute name | Type | Default value |
fullscreen_mirroring | Boolean | false |
- Switch also automatically to fullscreen mode when using WebVR.
|
Attribute name | Type | Default value |
mouse_pointerlock | Boolean | true |
- Lock the mouse-control when in VR mode (no visible mouse-cursor) and control
the viewing direction directly by mouse movements.
|
Attribute name | Type | Default value |
mobilevr_support | Boolean | true |
- Enable or disable the MobileVR support.
- This is a fallback solution when there is no WebVR API support available in the browser.
- It allows using VR on any mobile devices that have gyroscope and accelerometer sensors.
|
Attribute name | Type | Default value |
mobilevr_desktop_support | Boolean | false |
- Provide the MobileVR support also on Desktop devices.
- By default the support is limited to mobile and tablet devices.
|
Attribute name | Type | Default value |
mobilevr_fake_support | Boolean | false |
- Enable a 'fake' MobileVR support for tablet and non-VR desktop devices.
- On these devices using VR wouldn't be possible normally, but with this setting enabled krpano will provide a fake solution / kind of simulation to give the user still an impression of the VR mode.
- For checking if the fake mode is enabled there is the isfake attribute.
|
Attribute name | Type | Default value |
mobilevr_touch_support | Boolean | false |
- Enable touch support for rotating / adjusting the horizontal offset.
- This setting is disabled by default because some VR headsets are touching the screen with their case
and can sometimes trigger wrong inputs.
|
Attribute name | Type | Default value |
mobilevr_profile | String | |
The default value (for Cardboard V1 headsets):
"80|60|42|35|0.441|0.156"
|
Attribute name | Type | Default value |
mobilevr_screensize | String | "auto" |
- Set a custom diagonal device screen size in inch.
- Knowing the physical screen size is necessary and very important to be able calculate the correct VR field-of-view and lens-distortion.
- When set to auto (the default):
- In this case the plugin tries to detect the device itself to get its screensize.
- The plugin uses therefore an internal list of devices. Additionally a customizable list of devices can be defined in the xml.
- When the device is unknown an external database can be used (see mobilevr_database_url) for finding the size of the device.
- When detecting the size isn't possible, the plugin sends the onunknowndevice event.
|
Attribute name | Type | Default value |
mobilevr_database_support | String | "xml|internal|external" |
|
Attribute name | Type | Default value |
mobilevr_database_url | String | |
- Use a Cardboard Device Parameter Database (DPDB) as fallback for getting the screen-size for unknown devices.
- By default this online database will be used:
- When the database url setting will be set to an empty string value or to null, then no online database request will be made for unknown devices.
|
Attribute name | Type | Default value |
mobilevr_wakelock | Boolean | true |
- Wakelock - try to keep the mobile device awaken and prevent that the display
switches to sleep / standby mode.
This is necessary because during the VR viewing typically no user touches on the display
(which would prevent sleeping) are happening.
- Currently the wake-locking is not a browser feature, currently it is only an ugly hack (which works
by playing and looping a small hidden video).
The current hack might be not working or could cause problems in newer/updated browser version,
therefore it's optionally possible to disable that feature.
|
Attribute name | Type | Default value |
mobilevr_sensor | int | 1 |
- Define which browser event should be used for the device movement tracking:
- 0 = the deviceorientation event
- Here the sensor fusion will be done by the browser itself.
- The data from this event is unfortunately buggy or just bad (slow, inaccurate, wrong) in many Android devices and Android browsers.
- 1 = the devicemotion event (default)
- Here the sensor fusion will be done by krpano.
- The browser provides the raw data from the acceleration and the gyroscope sensors and krpano combines them for getting the final device rotation:
- The gyroscope data is very quick and accurate but the gyroscope sensor measures only relative rotations and
therefore it drifts away from the real physical orientation over time.
- To compensate that drift, the acceleration sensor is used. That sensor measures the gravity acceleration of the earth
and that can be used as absolute reference.
- But the acceleration data is very noisy and it can be only used for detection 'tilt' rotations (tilt left, right, up or down) -
rotations around the device itself can't detected by acceleration, for this the gyroscope data is required.
- So the data from both sensor will be combined / fused.
The acceleration data will be low-pass filtered and used as slow 'stabilization' and
the gyroscope data for quick and accurate movements in all directions.
- Using the devicemotion event (setting mobilevr_sensor=1) is the default and there should be normally no need or benefit to use the deviceorientation event,
except maybe for some extreme browser bugs...
|
Attribute name | Type | Default value |
mobilevr_sensor_mode | int | 3 |
- The frame-rendering and the 'sensor-data-events' are happening in different time intervals / rates
(depending on the system and browser),
so it is necessary to evaluate and interpolate/extrapolate the sensor data somehow to get
a smooth and also fast and responsive movement.
- With this setting, different modes for this process can be selected.
- Available modes:
- 0 = Directly use the latest available sensor data.
No interpolation or extrapolation. Depending on the sensor-time-intervals of the browser
the movement can be either jerky or smooth.
- 1 = Smoothly interpolate between the latest
available sensor data. This will give a very smooth but delayed movement.
- 2 = Forecast the device rotations and then interpolate between the sensor data.
- 3 = Extrapolate the latest available sensor data
to the current frame time.
This will give a fast responsive and smooth movement, but there can be a jerking
when the extrapolated/predicted data and the real movement don't match.
- 4 = Forecast the device rotation to the current frame time.
This will give a fast responsive and smooth movement, but there can be a jerking
when the extrapolated/predicted data and the real movement don't match.
- 5 = Forecast the device rotation and extrapolate the
sensor data from the latest event to the current frame time.
- 6 = Forecast the device rotation one frame ahead.
- 7 = Forecast the device rotation two frames ahead.
- Note - these settings would need to be rated inside a VR-HMD (head-mounted-display)!
E.g. mode=1 looks good and super smooth on the screen, but inside a HMD the delayed movement
can be unpleasing. Other modes might look jerking on the screen, but good inside the HMD.
Additionally it depends on the sensor-rate of the browser, how good each mode will look.
A good compromise for different devices are the modes 3 and 4.
|
Attribute name | Type | Default value |
vr_cursor | String | |
|
Attribute name | Type | Default value |
vr_cursor_enabled | Boolean | true |
|
Attribute name | Type | Default value |
vr_cursor_onover
vr_cursor_onout
|
Action Event Action Event |
|
- These events will be called when the vr_cursor will move over and out of others hotspots.
- The 'scope' of these events will be one of the hovered hotspots.
That means these events act like the onover,
onout events of the hotspot itself.
|
Attribute name | Type | Default value |
vr_controller_support | Boolean | true |
- Enable or disable the support for vr-controllers.
|
Attribute name | Type | Default value |
vr_controller | String | |
|
Attribute name | Type | Default value |
vr_controller_clickbuttons | String | "0,1" |
|