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.
This also fixes distortion weirdness in the osgviewer version. That
was caused by osg::GraphicsContext getting in the act on resize events
and adding its own scaling to the projectionOffset of slave cameras!
file. Possible uses of this functionality could include converting the
model to some other format or coordinate system for use in some other
visualization or simulation.
src/GUI/gui.h src/GUI/gui_funcs.cxx src/Main/fg_commands.cxx
src/Main/renderer.cxx src/Main/renderer.hxx: Tim Moore:
These patches implement a command to dump the entire OSG scene graph as
a .osg text file. While large, this allows debuggers to really see
what's happening in the scene graph.
configure.ac src/Main/Makefile.am src/Main/fg_os.cxx
src/Main/fg_os.hxx src/Main/fg_os_sdl.cxx src/Main/main.cxx
src/Main/renderer.cxx src/Main/renderer.hxx
src/Network/jpg-httpd.cxx
Added Files:
src/Main/FGManipulator.cxx src/Main/FGManipulator.hxx
src/Main/fg_os_osgviewer.cxx:
Tim Moore: Make use of osgViewer.
src/Input/input.cxx src/Main/renderer.cxx
src/Main/renderer.hxx src/Scenery/scenery.cxx
src/Scenery/scenery.hxx: Move scenery picking into the renderer.
There is most of the required data defined. Also we can better use
the pick visitor that will be needed with th upcommung panel code.
Computes the pick direction and starting point. This is code that translates
a screen coordinate into a vector in the FlightGear world (between the eye and
the on-screen coordinate.) Armed with this vector in FG world coordinates,
you could call a scenery intersection routine and lookup the lon/lat/elev of
the point in the world that was clicked on.
ssgSetNearFar(). This by default creates a symmetric view frustum which is
typically what an application wants.
However, to get control of the view frustum in order to build support for
asymmetric view frustums, we need to wrap these calls with a bit of our own
logic.
This set of changes wraps all calls to ssgSetFOV() and ssgSetNearFar() with
FGRenderer methods.
I also standardized how the FGRenderer class is handled in globals.[ch]xx.
This led to some cascading changes in a variety of source files.
As I was working my way through the changes, I fixed a few warnings along
the way.
erly known as trRenderFrame) is now declared as a NULL function pointer and ass
ignment of the proper function is now done in FlightGear (jpgRenderFrame=FGRend
erer::update).
a working state. I still see an anomoly when taking a screen shot from inside
a 3d cockpit, but external (chase/tower) views seem to work well. I also
added a property to control how many screen-res tiles are generated in the
output. Theoretically, you can now generate unlimited resolution screen shots,
or limited only by your disk space and patience.
Today I successfully generated a 20*1024 x 20*768 (20480x15360) resolution
screen shot. If you rendered that at 100 dpi it would cover a poster of
about 17 feet by 12.8 feet.
Good luck trying to display something that big or convert it to anything
useful on a typical PC. :-)
Split up main.cxx into a program manegement part (which remains in
main.cxx) and a render part (the new renderer.?xx files). Also turn
the renderer into a small class of it's own. At this time not really
exctining because most of the stuff is still global, but it allows us
to slowly migrate some of the global definitions into the new class.
The FGRenderer class is now managed by globals, so to get the renderer
just call gloabals->get_renderer()
At some pijt it might be a good idea to also turn the remaining code in
main into a class of it's own. With a bit of luck we end up with a more
robust, and better maintainable code.
