SviewCreate() now takes a SGPropertyNode* config which contains all information
needed to specify the view, including window size and position.
By default views are defined using a series of <step>...</step> nodes which map
to SviewStep* classes internally.
Alternatively, existing extra-view functionality is supported using
type='current', 'last_pair' or 'last_pair_double', plus one can use old-style
<view>...<view> nodes with type='legacy'.
See src/Viewer/sview.hxx for details and examples.
The extra-view commands view-clone, view-last-pair and view-last-pair-double
now pass the supplied SGPropertyNode* through the underlying FGViewMgr to
SviewCreate().
Improved handling of +/- heading and pitch values. For example some legacy
views have inverse relationship between heading-offset-deg and the actual
heading offset, so we now only multiply by -1 early on when handling these
legacy views, and SviewStepRotate does not negate.
Fixed Helicopter view direction bug with multiplayer aircraft - need to use
global /sim/current-view/heading-offset-deg, even for multiplayer aircraft.
Fixed incorrect handling of roll in pilot view - when adding in extra changes
of heading, pitch and roll to things like Helicopter view, simply adding to
heading, pitch and roll doesn't work if aircraft roll is not zero. Instead we
need to do the calculation with SGQuatd, so have added optional rotation params
to SviewStepFinal.
Added support for legacy Tower view look from.
Details:
src/Main/fg_commands.cxx
src/Viewer/viewmgr.cxx
src/Viewer/viewmgr.hxx
Added 'view-new' command.
All recently-added view commands now pass the SGPropertyNode* arg to
globals->get_viewmgr() and from there to SviewCreate().
src/Viewer/sview.cxx
src/Viewer/sview.hxx
SviewStepAircraft and SviewStepNearestTower uses new Callsign
class for tracking multiplayer aircraft by callsign instead of
/ai/models/multiplayer[] number, so we cope when multiplayer aircraft
are renumbered by network outages.
Double views are now implemented as a final view step, instead of
in a separate class derived from SviewView. So all views are
implemented using SviewViewEyeTarget, and there is arguably no
need for the separate SviewView base class.
SviewViewEyeTarget now has a single list of steps, instead of separate
lists for eye and target, because the use of SviewStepCopyToTarget makes
separate lists unnecessary.
Overview:
Previously Flightgear always used a single osgViewer::Viewer(), which
inherits from both osgViewer::ViewerBase and osgViewer::View, giving a
single view window.
If CompositeViewer is enabled, we instead use a osgViewer::CompositeViewer
which contains a list of osgViewer::View's. Each of these View's can have
its own eye position, so we can have multiple different views of the same
scene.
Enable at runtime with: --composite-viewer=1
Changes to allow use of osgViewer::CompositeViewer:
Previously FGRenderer had this method:
osgViewer::Viewer* getViewer();
This has been replaced by these two new methods:
osgViewer::ViewerBase* getViewerBase();
osgViewer::View* getView();
If CompositeViewer is not enabled (the default), the actual runtime state
is unchanged, and getViewerBase() and getView() both return a pointer to
the singleton osgViewer::Viewer() object.
If CompositeViewer is enabled, getViewerBase() returns a pointer to a
singleton osgViewer::CompositeViewer object, and getView() returns a
pointer to the first osgViewer::View in the osgViewer::CompositeViewer's
list.
The other significant change to FGRenderer() is the new method:
osg::FrameStamp* getFrameStamp()
If CompositeViewer is not enabled, this simply returns
getView()->getFrameStamp(). If CompositeViewer is enabled it returns
getViewerBase()->getFrameStamp(). It is important that code that previously
called getView()->getFrameStamp() is changed to use the new method, because
when CompositeViewer is enabled individual osgViewer::View's appear to
return an osg::FrameStamp with zero frame number).
All code that uses FGRenderer has been patched up to use the new methods so
that things work as before regardless of whether CompositeViewer is enabled
or not.
We make FGRenderer::update() call SviewUpdate() which updates any extra
views.
Extra view windows:
If CompositeViewer is enabled, one can create top-level extra view windows
by calling SviewCreate(). See src/Viewer/sview.hxx for details.
Each extra view window has its own simgear::compositor::Compositor
instance.
Currently SviewCreate() can create extra view windows that clone the
current view, or view from one point to another (e.g. from one multiplayer
aircraft to the user's aircradt) or keep two aircraft in view, one at a
fixed distance in the foreground.
SviewCreate() can be called from nasal via new nasal commands "view-clone",
"view-last-pair", "view-last-pair-double" and "view-push". Associated
changes to fgdata gives access to these via the View menu. The "view-push"
command tags the current view for later use by "view-last-pair" and
"view-last-pair-double".
Extra view windows created by SviewCreate() use a new view system called
Sview, which allows views to be constructed at runtime instead of being
hard-coded in *-set.xml files. This is work in progress and views aren't
all fully implemented. For example Pilot view gets things slightly wrong
with large roll values, Tower View AGL is not implemented, and we don't
implement damping. See top of src/Viewer/sview.cxx for an overview.
OpenSceneGraph-3.4 issues:
OSG-3.4's event handling seems to be incorrect with CompositeViewer -
events get sent for the wrong window which causes issues with resize and
closing. It doesn't seem to be possible to work around this, so closing
extra view windows can end up closing the main window for example.
OSG-3.6 seems to fix the problems.
We warn if CompositeViewer is enabled and OpenSceneGraph is 3.4.
This is to avoid console/log spam from jetways.nas in particular,
which uses loadxml to probe for file existence, every 10 seconds. But
in general it seems useful to have this potentially be quiet, since
there is a result code.
When the file path is not preset, check for this and don’t let
readProperties() fail with an exception, since this makes for very
noisy event reporting.
Change fgcommand to take an optional property tree root element.
This fixes the animation bindings to use the defined property tree root - to support multiplayer (or other) model that can bind to the correct part of the property tree.
Requires a corresponding fix in sg to allow the command methods to take an optional root parameter.
What this means is that when inside someone else's multiplayer model (e.g. backseat, or co-pilot), the multipalyer (AI) model will correctly modify properties inside the correct part of the property tree inside (/ai), rather than modifying the properties inside the same part of the tree as the non-ai model.
This means that a properly setup model will operate within it's own space in the property tree; and permit more generic multiplayer code to be written.
This is probably responsible for some of the pollution of the root property tree with MP aircraft properties.
This change is the logical counterpart of SimGear's change from commit
79f869a7f32910197be72b21f6489fbbba02c836 that moved the following files
from simgear/misc to simgear/io/iostreams:
gzcontainerfile.cxx
gzcontainerfile.hxx
gzfstream.cxx (formerly zfstream.cxx)
gzfstream.hxx (formerly zfstream.hxx)
sgstream.cxx
sgstream.hxx
sgstream_test.cxx
For unknown reasons this seems to alleviate the word-wrap / min-height
bug on Windows. Committing so we can test and verify this is really
the case before the next release.
Requires FGData commit: 0565eaab10a5d466cd485766b17d1870936a0a57
(which actually renames the file).
Also disables the preferences-load command since I don’t believe it
would actually be safe to reload the defaults without doing a simulator
reset (aircraft -set.xml values would be overwritten, for example)
Remove uses of .str(), .c_str() and some other methods of SGPath.
Pass SGPath directly where possible, or explicitly convert to the
appropriate 8-bit encoding.
Drop fgNormalizePath, use realpath() only
As this makes it accept relative paths, always use the returned
(absolute) version for the actual file operation to avoid check-to-use
races, or where this is not possible (NasalSGPath) explicitly reject
relative paths
Fix: do_save is a write, not a read
This is insecure because it always (not just on Windows) converts
\ to / before .. checking. Either use the path it returns (as in
f_open()) or use an SGPath (where this conversion is already done)
Only a minor problem because the affected functions are limited to
the .sav file type
Unfortunately we can’t drop loaded ones, since the in-memory structures don’t have ref-counting, and we don’t
know what AI plans may be referencing them.
- /sim/aircraft can be set to package ID, including qualified
package ID. If not matching package is found, falls back to
traditional search of fg-aircraft for -set.xml files
- use old-style reset as the basis for a lightweight 'reposition' command. This does not restore state, or reset
time management, but does reset the FDM and re-finalize position.
Adapt to corresponding SG change to make SGMaterialLib be ref-counted,
and have the 'reload-materials' command notify the tile-manager of this,
so it can update the options struct it passes to new tiles.
Had to add this to FGGlobals, since it needs to be cleaned up
alongside the sound manager (which ideally it would be owned by,
but that's a change for another day)
