This was lost when I stopped cloning the near camera to make the far
camera. The result was a lot of breakage, including explicit camera
configurations not working and various ordering issues too.
This seems to be accepted OSG usage for slave cameras. It's possible
that this order is important for rendering instruments that use RTT
textures on systems without frame buffer object support. I'm thinking
that the resulting bugs may be implicated in the "black rectangle" problem.
The near/far boundary, called "near-field", can be set to 0 which
disables the far camera and renders the whole scene using only one
camera. I'm hoping that this may be useful in resolving some
system-specific rendering bugs.
Various fixes were made to correctly render the scene using only the
near camera.
Partition depth in CameraGroup:
Remove the ViewPartionNode scenegraph node. The split rendering of the
scene, done to avoid Z buffer precision problems, is now done by two
slave cameras of the viewer.
Rename FGManipulator to FGEventHandler.
Remove virtual member functions that aren't required for event handlers.
Begin using camera group properties to update cameras at runtime;
Initially only the viewport properties are used.
When no camera group is found in the property tree (the default),
create the properties for one. Expose the default window by name.
Add a test for Boost headers to configure.ac. Boost is now a
dependency.
Remove GLUT and SDL versions of the OSG graphics.
CameraGroup supports cameras opened in different windows or in the
same window, with flexible view and perspective specification.
Clean up mouse click handling via osgViewer. Don't let any camera
"have focus;" this forces events to be reported in window coordinates
and simplifies life. Don't use the osgViewer::View::requestWarpPointer
method; instead use our own code which only deals with window
coordinates.
Make glut and sdl versions work with CameraGroup too.
