View manager

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.


This is a mini-howto document describing the configuration of views using the new capabilities in the viewer code. Let me know if you see typos, etc.

Jim Wilson has written a mini-howto for configuring views in flightgear (i.e. cockpit view, tower view, chase view, etc.) These are all dynamically configurable via an xml config file.

Curt added this HOWTO to the flightgear docs page or you can find it directly using the following URL:



there are only three situations we need to deal with in the viewer code:

  1. Looking away from a known position.
  2. Looking towards a known position from a known distance and angle(s).
  3. Looking from one known position towards another.

An example of (1) is the view from inside the aircraft; an example of (2) is a chase view; and an example of (3) is a tower view. The view manager class should take care of setting up viewers appropriately for different situations.

In every case, we want to be able to specify offsets for all six degrees of freedom. I think that it makes sense to put all of this in a single, configurable viewer class, rather than having separater viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that duplicate most of each-others' code.

The main required output is the VIEW matrix to pass to ssgSetCamera, but several parts of FlightGear need vectors and matrices that are byproducts of calculating VIEW as well (such as the world-up vector); it would be nice to minimize these dependencies as far as possible.

All of the views can still be managed by the view-manager class (a proper subsystem), but we should try to remove all hard-coded dependencies from the rest of the FlightGear codebase. For example, the scenery code doesn't need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera.

Here are most of the required outputs, from an analysis I did earlier:

  • the VIEW matrix, a matrix containing the transformations to put the view in the correct position and orientation (as as the argument to ssgSetCamera)
  • the UP matrix, rotation matrix to the current notion of up (opposite of gravity)
  • the current absolute view position in fgfs coordinates
  • the current view position in fgfs coordinates, relative to the scenery center
  • the world-up vector
  • the surface-east vector
  • the surface-south vector

All of the others are byproducts of the VIEW calculation, used for convenience by various bits of the code.

Ultimately, the "view" is just a tuple with six degrees of freedom. The front-end code would "feed" these numbers via the appropriately complicated mechanism (aircraft phi/theta/psi plus view offset/tilt, for example), but clients would only care about the final numbers, and not the intermediary stuff.

Melchior FRANZ has reorganized the <view> handling and added a new view mode. It's still work in progress, but looks quite nice already: "Fly-By View" This picks a view position somewhere ahead and lets the aircraft fly by, then searches a new position etc. Nice for replay, or for experiencing how fast the aircraft actually flies. (From cockpit view it looks always slow. ;-) I still need to tweak the parameters and to prevent updates when the aircraft has barely moved. The reorganization part was desirable, because until today the different <view>s had to have continuous indices. When FlightGear predefined <view n="0"> to <view n="5">, then aircraft had to continue with <view n="6">. A lot of aircraft did that, but whenever one removed or added a generic view, all aircraft <view> definitions had to be moved, which was a huge PITA. Now indices of <view> definitions can be freely assigned. To avoid further, unnecessary collisions, I "suggest" (well, *demand* :-) that aircraft use indices starting with 100, leaving 0..99 for the "system". (Remember that you don't have to specify the index in every definition. Setting n="100" in one will automatically set the next to 101 etc., unless otherwise specified. Melchior FRANZ has also made a minor change to the way numbers are interpreted when written to /sim/current-view/view-number: 0 and positive numbers are treated like they used to, so everything works like before: they select the (n-1)th <view>. But now that holes are allowed, this does no longer necessarily match the node index. To select a view with particular node index (e.g. the aircraft's <view n="100">, one can write that as negative number: setprop("/sim/current-view/view-number", -100); This will, of course, immediately be turned into the normal index (let's say 6), I expect that everyone forgets this feature quickly, and that nobody uses it, except maybe a few notorious C++ code readers. ;-)[1]

The best way is probably to forget about those numbers, and to address the view by name, for example via hash:

var view = {}; var nodes = props.globals.getNode("/sim").getChildren("view"); forindex (var i; nodes) view[nodes[i].getNode("name").getValue()] = i; setprop("/sim/current-view/view-number", view["Copilot View"]);


Look-at mode

Taken from [3]

<view n="101">
    <name>News Camera</name>
    <internal type="bool">true</internal>