StepView
|
|
If you're able to run a build from next and run with --composite-viewer=1, there's support for extra view windows which can provide a top-level window showing exterior aircraft views independently from the main window's view.
One can configure such a view via XML with the view-clone command - see: $FG_SRC/Viewer/sview.hxx and it's used by fgdata/gui/menubar.xml. Or simply clone the current view using the View menu.
At some point in the future we'll have Canvas views which will allow such views to appear within the main view, e.g. as an emulated CRT/LCD screen.[1]
What is it
"Step View" - because it constructs eye and target positions/directions in a series of explicit configurable steps.
flightgear/src/Viewer/sview.cxx) already knows how to parse some of the standard XML view specifications, so that it can clone views.
Extra view windows use a new view system called Sview which is short for 'step view', where one configures an arbitrary number of individual steps that end up defining the camera position and orientation. There are a number of different step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc. One can specify the exact desired sequence of steps by passing XML to the view-new command see
flightgear/src/Viewer/sview.hxx for details.
These basic steps are enough to allow Sview to copy what conventional views do, allowing the 'Add clone view' menu item to work - this opens a new window with a copy of the current view, which is then independent of the main window's view.
It's easy enough to add (C++) code to implement new steps, including more sophisticated things. For example there is a view step that keeps two aircraft visible at all times, with one in the foreground. See CompositeViewer Support for details and demonstration videos.
It might be interesting to try to define the Shuttle RMS arm view as an Sview in its own top-level window. Apart from anything else Jules would like to make sure that Sview supports whatever requires; He'd imagine that we would have one Sview step for each hinge/link in the arm for example, and this might need a new Sview step type.
It would also be a useful incentive to getting Canvas views working.[2]
Internals
we could make things into a top-level subsystem. Though Sview is not the default view subsystem and so in some ways it's nice to keep it under control of the main view subsystem.
However before we get too far down into these details... the code in src/Viewer/sview.* currently mixes two things that it might be good to split up first. First there's the step view system itself which manages eye and target positions/directions, and second we have the creation and management of extra view windows (and potentially canvas elements) with their own graphics context and Compositor instance etc.
The reason they are bundled together at the moment is that splitting them up might require that we expose some of the details of how step views are created, which is necessarily a little involved - see the various base and derived classes such as SviewStep and derived classes such as SviewStepMove, SviewStepNearestTower etc.
Whether or not we can keep the details hidden, might depend ultimately on the UI for creating views that we want to present to the user.[3]
References
| References |