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 |
absolute | Boolean | false |
- Use an absolute / real-world-oriented direction tracking.
- MobileVR only!
Currently this is only possible on mobile devices!
Real VR headsets using the WebVR or WebXR APIs (e.g. like Oculus Quest headsets),
currently don't provide any APIs or possibilities for a real-world orientation tracking or even getting the real-world orientation somehow.
- By default the pano-image-center (hlookat=0.0) will point to North, but
it is also possible to set a custom north position/offset.
- When disabled (the default), the gyroscope tracking will be relative to the current viewing direction.
- The device must have a magnetic sensor for this to work reliably.
iOS devices are typically working very well, on Android it varies and depends on the device.
- Note - when using absolute tracking, all panos should be set/aligned to the same North. Otherwise
the north setting would need to be adjusted dynamically for each pano.
|
Attribute name | Type | Default value |
north | Number | 0.0 |
- Define where North is located in the pano-image (from -180 to +180).
- The default is 0.0, which refers to the center of the pano-image.
- Note - this is only relevant when using using absolute direction tracking.
-
The coordinate system:
|
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.
- WebXR API Notes: The WebXR API doesn't allow values higher than 1.0
and the setting can't be changed later, so only the initial value matters.
|
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 |
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 |
webvr_highrefreshrate | String | |
- Oculus Browser on Oculus Go renders at 60Hz by default while Oculus Quest does it at 72Hz by default.
A 72Hz rendering mode is available for Go as well, that increases comfort but with a performance and energy trade-off.
- Setting to true enables 72Hz mode.
- Setting to false explicitly disables 72Hz mode on both Go and Quest.
- When not set, the systems default will be used.
- Supported by the WebVR API and the WebXR API.
|
Attribute name | Type | Default value |
webvr_foveationlevel | int | 1 |
- Fixed Foveated Rendering is a method for improving rendering performance.
When enabled the screen edges are rendered at a lower resolution than the center,
resulting in fewer total pixels that need to be calculated.
- The webvr_foveationlevel setting specifies the level of fixed foveation.
The value is in range 0 to 3, where 0 - none, 1 - low, 2 - medium, 3 - high.
The default value is 1.
- Supported by the WebVR API and the WebXR API.
- More information.
|
Attribute name | Type | Default value |
webvr_ca_correction | Boolean | |
- Set to true to explicitly request a CA-Lens-Correction.
- This can correct the color-separation on the edges that is caused by the lens, but also can cost additional GPU processing power.
- When not set, the systems default will be used.
- Only supported by the WebXR API.
- More information.
|
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 | |
|
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.
- The Browsers
Screen Wake Lock API is used when available (on Android Chrome and on iOS since version
iOS 16.4).
- Without Wake Lock API support, a workaround by playing and looping a small hidden video is used.
But this can interfere with other videos. That means when playing videos, the wakelock might get interrupted.
|
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 sensors 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...
- Note - In iOS 13.4 / Safari 13.1 the devicemotion event is broken.
Therefore on these systems the default value of mobilevr_sensor
is set to 0
to use the deviceorientation event (which is working) instead.
|
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 |
flatpanohfov | Number | 120.0 |
- Enables a special mode for viewing flat-panos in VR.
- Flat panos defined by <flat> will get automatically upscaled to this horizontal field-of-view when entering the VR mode.
- The hotspot ath, atv and scale settings will also be automatically upscaled.
- When set to 0.0, this mode will be disabled.
|
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" |
|