James Hogan wants to merge 5 commits from /u/amalon/flightgear/ to next, 2021-09-03
These patches add minimal virtual reality support to FlightGear using the osgXR library I've been working on (primarily for FlightGear):
https://github.com/amalon/osgXR
(osgXR only has bindings for Linux/X11 right now)
The first 3 patches make some generic tweaks to CameraGroup:
- buildCamera() now returns CameraInfo*
- new removeCamera() function
- new compositor reload callbacks attached to CameraGroup
And the final couple of patches specific to VR support:
- build changes to find the osgXR library (its optional)
- the main patch to add VR support, namely --enable-vr and --disable-vr options, implementation of a flightgear::VRManager class based on osgXR::Manager to do all the magic of adding & removing cameras from the CameraGroup, and 3 #ifdef'd hooks into it from fgOSResetProperties(), fgOSMainLoop() & fgOSCloseWIndow().
Notably missing for now (on Fernando's request) is the dynamic switching of the desktop window to a mirror of the VR view.
A corresponding fgdata PR will add a dialog to allow VR to be turned on and off dynamically.
I'm tracking the VR project here:
https://wiki.flightgear.org/Virtual_Reality
All comments appreciated!
Commit | Date | |
---|---|---|
[db4525]
(vr_1, vr_1_b)
by
James Hogan
VR: Implement minimal VR support Implement support for virtual reality headsets via version 0.3 of the Add a new VRManager class based on osgXR::Manager to implement its VR settings are controlled by properties, and new --enable-vr / This is enough to get basic VR for looking around the cockpit, but more [1] https://github.com/amalon/osgXR |
2021-07-17 22:19:14 | Tree |
[dcdda1]
by
James Hogan
VR: Find the osgXR library Allow the osgXR[1] library to be found and linked against. We'll use [1] https://github.com/amalon/osgXR |
2021-07-17 22:19:14 | Tree |
[e25a56]
by
James Hogan
CameraGroup: Add compositor reload callbacks Add a compositor reload callback object to CameraInfo, with callbacks This will allow VR cameras to be reconfigured after a reload. |
2021-08-02 22:38:56 | Tree |
[9e430b]
by
James Hogan
CameraGroup: Add removeCamera() Add removeCamera() method to CameraGroup to find and remove a single This will allow cameras created for VR to be dynamically reconfigured. |
2021-08-02 22:36:04 | Tree |
[7a096d]
by
James Hogan
CameraGroup::buildCamera(): Return CameraInfo* Make CameraGroup::buildCamera() return the new CameraInfo* so the caller |
2021-08-02 22:30:19 | Tree |
Corresponding fgdata PR 238
Will let Frnando review this one I guess :)
Looks good to me, really modular and clean. It's very nice to see the whole Viewer code finally start looking somewhat elegant. :) We should also probably start using your Compositor reload callbacks to do the reloading when issuing the reload-compositor fgcommand.
The only thing I'm not sure about is tied properties. I think we were avoiding them these days and using PropertyObjects instead, but I could be wrong. Maybe James can provide some insight. @jmturner
Thanks, Its great that the compositor stuff is basically in place and ready for new views to be added for VR).
I'm not sure I follow. The reload callbacks should already get invoked from reload-compositor for each CameraInfo, since that fgcommand uses reloadCompositors().
My bad, I didn't see the code that actually called the callback on reloadCompositors(). :)
Tied properties are a maintencen headache, indeed. So If you need something that's very low impact in C++, try using ProeprtyObject, or if it's something infreuent, just plain properties.
Okay, thanks. I'll have a play around with PropertyObject. If I understand right, I should just assign an initial value to plain simple properties, and keep them in sync via listeners (fg->osgXR) and callbacks/polling (osgXR->fg).
Some are determined on demand, and I don't want to expose the internal startup/shutdown state machine to the public osgXR API, but most only change along with a state change, so a generic "state has changed" virtual callback from osgXR might be good enough to trigger poll for changes.
Correct, but as you note the granularity you do this it as entirely up to you: a single 'state has changed' callback from osgXR is fine, indeed. If you have many properties going from fg -> osgXR, you may find that a manual listener is simpler, because you can define a single listener and add it to all your potentially changing property: again this reduces granularity, but many cases don't need individual-property-level granularity.
If I have a new version. do I have to create a new merge request, or is there some way to change the requested branch?
never mind, I see that updating the branch does show it up (i tried with the fgdata one), sorry for the noise
Branch updated:
- Drop VRManager::resetProperties() which ties properties. Instead use PropertyObjects (set up in VRManager constructor) to set normal properties (after update(), and before handling onRunning()/onStopped(), and only if osgXR state has changed), and use property listeners to update osgXR on property changes.
- Drop property getters, since they aren't used any longer
- Use osgXR 0.3 for Manager::checkAndResetStateChanged()
- Drop FIXME before VRManager::update() call in fgOSMainLoop() - it can be moved later if needed
Hopefully that addresses the issues with tied properties and is done sensibly, but let me know if there are improvements to be made.
Thanks
Thanks a lot for the contribution! If you already have some code and want to create another MR for the VR mirror view, please go ahead. We can discuss how to best approach this there.