Friction / vibration dampening of the gyro movement.
Values: 0.0 - 0.99 or "auto"
0.0 = no friction / dampening, 0.99 = very strong dampening
The higher the value the more dampening, but therefore also the movement will be delayed more.
auto - use dynamically an automatic zoom friction value based on the current zoom/fov
and the current frame-rate based friction - e.g. more shake dampening when zooming in.
horizontaloffset - By touch dragging only the horizontal offset will change.
full - Full touch control - pan horizontally and vertically.
The vertical offset will return slowly to the real device orientation when moving the device.
disablegyro - When the user touches the screen, the gyro control
gets automatically disabled and the normal controls are taking over. To get the gyro control
back, the gyro would need to get enabled again.
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 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...
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 slightly 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.
Some devices have uncalibrated sensors and there this automatic calibration can help to avoid an unintended gyroscope movement / drifting.
The automatic self-calibration will be done every time when the device will be hold very still, e.g. either by holding the device very steady or by laying the device on a stable table.
Enable the gyroscope support also for desktop devices (e.g. Windows Tablet-PCs).
By default the gyroscope support is only available for mobile and tablet devices.
This settings should be not enabled by default!
Desktop browsers might wrongly report that they have gyroscope support even when there is gryoscope sensor available!
When using the gyro inside an 'cross-origin' iframe (that means the outer page and inner iframe
page are on different origins/domains) then the gyro-usage might be blocked by the browser.
To work-around that limitation it is possible to 'capture' the devicemotion event in the outer page
and send it via the postMessage API to the inner iframe.
Here example Javascript code for the outer (the iframe-containing) webpage: