Implement support for virtual reality headsets via version 0.3 of the
osgXR[1] library I've been working on which uses OpenXR.
Add a new VRManager class based on osgXR::Manager to implement its
callbacks. When osgXR needs a new view created, we build a new camera in
the default camera group, and notify osgXR of each new "scene" typed
render pass. It also hooks into the CameraInfo's new compositor reload
callback to ensure osgXR is updated when the compositors are reloaded.
VR settings are controlled by properties, and new --enable-vr /
--disable-vr options are implemented to enable/disable VR at start.
This is enough to get basic VR for looking around the cockpit, but more
work will be required to support a desktop mirror of VR view, VR splash
screen, VR GUI, controller interaction, and correct positional sound.
[1] https://github.com/amalon/osgXR
Add a compositor reload callback object to CameraInfo, with callbacks
for just prior and after the CameraInfo's compositor is reloaded by
reloadCompositors().
This will allow VR cameras to be reconfigured after a reload.
Add removeCamera() method to CameraGroup to find and remove a single
CameraInfo.
This will allow cameras created for VR to be dynamically reconfigured.
Since 'center on aircraft' is now persistent, we need to expliictly init
this value when showing the map. Thanks to Michael Danilov and Colin
Geniet for the fix.
SF-Id: https://sourceforge.net/p/flightgear/codetickets/2637/
Reversed the affect of mouse in some legacy views, e.g. Helicopter and Pilot
views now move in expected direction for mouse drags. Also increased scale
of movement to make things similar to the default view system.
In chase view etc, apply mouse movements after damping of aircraft orientation,
previously mouse movements were getting damped.
Removed SviewStepFinalToTarget. SviewStepFinal now automatically aims at target
if new posdir.target_is_set flag is true.
Improved double views: Avoid duplicate SviewStepCopyToTarget step. Disabled
mouse drag handling - was gives weird results and is not required or
helpful. Be more consistent in using target position if available, otherwise
eye position; for example using a Helicopter view to create a double view now
uses the target of the helicopter view, not the eye point, which works much
better.
Removed internal use of SviewStepFinal from SviewStepDouble - used to be
special case.
Split mouse drag handling out of SviewStepRotate into new SviewStepMouseDrag.
Simplified last-pair code - both last-pair and last-pair double find position
and target in the same way.
Added <startup-current> param. Default is false which preserves previous
behaviour where internal state is initialised to zero. Otherwise we initialise
internal state using the current error value, which can reduce oscillations.
Added <startup-its> param, default is zero. For the first <startup-its>
iterations we don't update the output, which can be used to cope with initial
bad data from earlier controllers.
Also refactored the code to hopefully make it clearer and modified debug
logging to output all info in a single statement and on a single line for
clarity.
For example avoid initial oscillations with:
<pid-controller>
..
<startup-current>true</startup-current>
...
</pid-controller>
Ever since support for CompositeViewer was added in f62e5b9ce3,
FGEventHandler::eventToViewport() has been always calling
window_builder->getDefaultWindow() so it could decide whether an event was for
the main window or not. But if a custom camera-group was specified, there would
be no existing window called 'FlightGear' so getDefaultWindow() would create
one, which then interfered with event handling.
The fix is to change the global WindowBuilder::defaultWindowName to match
sim/rendering/camera-group/gui/window/name when we are handling a custom
camera-group, which ensures that when FGEventHandler::eventToViewport() calls
window_builder->getDefaultWindow(), it gets the main window, not a new window
called 'FlightGear'.
Set telnet_hz to 100 to reduce delay when making a recording - this avoids
problem where telnet round-trip time could result in recording being 1-2s
longer than we expected, leading to test failures.
With Normal recordings, if we are recording multiplayer aircraft, we continue
appending to the in-memory recording while replaying, so we need to stop when
we reach the original end of recorded frames.
New properies so recordreplay can know extent of current in-memory normal
recording:
sim/replay/record-normal-begin
sim/replay/record-normal-end
This is required since scripts/python/recordreplay.py improved checking of
recording length when replaying.
scripts/python/recordreplay.py
src/Aircraft/replay.cxx
src/Aircraft/replay.hxx
src/Aircraft/replay.*:
If /sim/replay/record-continuous-compression is true, we compress each
frame's data as a separate raw zlib stream.
Requires latest simgear's simgear/io/iostreams/zlibstream.cxx for
decompression with ZLibCompressionFormat::ZLIB_RAW. Haven't figured out how
to extend simgear's code to provide a compressing ostream so for now we
have our own local compression code.
We open popup and set sim/replay/replay-error=true if we fail to read
compressed data.
scripts/python/recordreplay.py:
Added test of compressed continuous recordings.
docs-mini/README-recordings.md:
Added information about compressed format.
