Howto:Configure camera view windows
FlightGear's multiple view features are very powerful, and it is amazing how fast things run on medium and even lower range hardware.
FlightGear's XML-configurable camera view system supports two major modes of operation:
- If you have multiple monitors connected to your computer and setup as separate independent displays (i.e. you can't drag a window back and forth between the monitors, and can't create a window that spans multiple monitors) then you can configure FlightGear to open up a separate window on each display and draw a unique view perspective in each window. (And if you want you can configure flightgear to open multiple windows on a single display.)
- If you have multiple monitors connected as one larger virtual display, you can configure FlightGear to open up one large window that spans all your displays, but then separate that large window into individual cameras and still draw a unique perspective on each display.
In addition, each view is highly configurable, no matter how your displays are configured.
- You can setup a distinct field of view for each display, so you can create a seamless outside world with different size monitors.
- If you wish, you can define each view in terms of the low level view frustum parameters, so you can carefully measure your monitor/display layout and configure each view to match your physical layout exactly ... including asymmetric view frustums if need be. Otherwise you can still define your views in terms of a simpler (but less flexible) horizontal/vertical field of view scheme.
- You can specify the horizontal and vertical offset from center for each display. This allows you to spread out your monitors to account for the physical gap between displays ... this allows you to create an even more seamless virtual world where runway lines and horizon lines start in the correct place on the next monitor when they run off the edge of the first. Imagine taking a large poster, cutting it into pieces and then separating the pieces from each other by a little bit ... none of the straight lines in the original image will pass straight through in the separated/stretched version. Now imagine taking that same picture and cutting strips out of it, but leaving the sections where they were originally. Straight lines are preserved between adjacent pieces. This is what this is about.
- ATI (the ATI that makes graphics chips and cards) used a simplified (prerelease) version of this feature to demo 8 screens being driven from a single computer at SigGraph this year.
- Enter the Matrox Triple Head to Go (google it if you haven't heard of it.) This is just a little box, but to the computer, it looks like one giant 3x wide monitor. It plugs into your computer on one side, and on the other side you plug in 3 actual monitors. So you get up to 3 monitors without your computer needing to know anything about it, and even on video cards with only one external display connector (like a laptop.) Using the 2nd mode of operation described above, I divided my one big window into 3 camera views and was able to draw about 120 degree wrap around field of view on 3 displays.
Required changes in preferences.xml
As of version 1.9, FlightGear uses OpenSceneGraph (OSG) for rendering the scenery. OSG already has an implementation for setting up different cameras looking at the scene and they are configured in $FG ROOT/preferences.xml.
Slave cameras are created using properties in preferences.xml. One slave is always created that is aligned with the viewing parameters of the master camera. Others can be opened in different graphics windows, possibly on other displays and screens. A slave camera is presently created in its own window. Closing any if the windows will close FlightGear as a whole.
Parameters for the slave are currently pretty limited; they include:
- the dimensions and position of the window.
- "shear" values in projection space.
- and "heading-deg" (a heading offset that was added specifically for LinuxTag).
The shear-x and shear-y values are really only useful for setting up a "video wall" type display where monitors arranged around the "master view" show a view in an offset frustum with the same aspect ratio and fov as the master.
Let's first look at an example, setting up two extra windows. Add something like the following code to the <rendering> section of your preferences.xml file:
<camera> <host-name type="string"></host-name> <display>0</display> <screen>0</screen> <shear-x>2</shear-x> <shear-y>1</shear-y> <width>320</width> <height>240</height> <fullscreen type="bool">false</fullscreen> </camera> <camera> <host-name type="string"></host-name> <display>0</display> <screen>0</screen> <shear-x>-2</shear-x> <shear-y>1</shear-y> <width>320</width> <height>240</height> <fullscreen type="bool">false</fullscreen> </camera>
To simplify maintenance you can also save these modifications in a separate PropertyList-encoded XML file (i.e. toplevel XML node must be named "PropertyList") and simplly reference it in preferences.xml by making use of the include attribute in the <rendering section>.
Preferences.xml will look like this:
<rendering include="camera-views.xml"> ... </rendering>
And a to be created camera-views.xml file will have the following content:
<?xml version="1.0"?> <PropertyList> <camera> <host-name type="string"></host-name> <display>0</display> <screen>0</screen> <shear-x>2</shear-x> <shear-y>1</shear-y> <width>320</width> <height>240</height> <fullscreen type="bool">false</fullscreen> </camera> <camera> <host-name type="string"></host-name> <display>0</display> <screen>0</screen> <shear-x>-2</shear-x> <shear-y>1</shear-y> <width>320</width> <height>240</height> <fullscreen type="bool">false</fullscreen> </camera> </PropertyList>
Finally, you may be better off just running a separate FlightGear instance on the second monitor and slaving it. The whole idea behind having a multiple screen setup like twinview is that it mimicks a continuous area with no boundaries. Putting those screen boundaries back in when the video subsystem has worked so hard to eliminate them is a metaphor collision and a design problem, see Property Tree/Native Protocol Slaving.