Howto:Configure camera view windows: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(No difference)

Revision as of 18:16, 26 January 2010

This article is a stub. You can help the wiki by expanding it.

Note:This article (inspired by [1]) is currently work in progress, feel free to improve it, at the moment everything here is is based on (and pretty much taken verbatim from) the following discussions:

Intro

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:

1. 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.)

2. 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.

Use Cases:

  • 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

The latest CVS version of 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 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.

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.


So, just add something like this

  <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 the <rendering> section of preferences.xml, 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 simple reference it in preferences.xml by making use of the include attribute in the <rendering section>:

preferences.xml:

 <rendering include="camera-views.xml">
 ...
 </rendering>

camera-views.xml:

<?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>