FGViewer
| Started in | 06/2009 |
|---|---|
| Description | Implements a standalone osgviewer based viewer for FG |
| Contributor(s) | Mathias Fröhlich |
| Status | Under active development (2009-2015) |
| Changelog | /utils/fgviewer |
| Rendering |
|---|
|
Rendering Pipeline |
|
Effects and Shaders |
|
Ongoing Efforts |
|
Standalone Tools |
|
IPC/Networking |
FGViewer is an utility to load a lightweight OSG viewer instead of loading the entire simulator. Useful for checking aircraft models, scenery tiles and airport layouts. It is similar to OSGViewer, but has the added advantage that it supports .btg and .stg files.
Using FGViewer
To launch FGViewer, run the following command:
fgfs --fg-root=$FG_ROOT --fgviewer [path]
or:
fgviewer --fg-root $FG_ROOT [path]
where [path] is the path to the thing that you want to view. An example of a possible path is Scenery/Terrain/w130n30/w123n37/KSFO.btg.gz. The full command, will show the layout of San Francisco International Airport:
fgfs --fg-root=$FG_ROOT --fgviewer Scenery/Terrain/w130n30/w123n37/KSFO.btg.gz
Altough FGViewer does not do nearly as much initialization as FlightGear, so it is quick to start up, it does read preferences.xml and autosave.xml and understands the fgfs command line arguments. You can, for example, set property values on the command line.
Controls
| Key | Function |
|---|---|
| Esc | Quit FGViewer |
| LMB | Rotate view |
| MMB | Pan view |
| RMB | Zoom view |
Plan
 This article may require cleanup to meet the quality standards of the wiki. Please improve this article if you can.
|
|
almost every system should be able to run completely independently of the frame rate. — Torsten Dreyer (Jan 26th, 2016). Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...).
(powered by Instant-Cquotes) |
|
|
|
Depsite appearances moving the rendering to a seperate node/process is probably the easiest to implement as the inter module dependencies aren't that strong, or at least those that are strong can be shipped as a block update at the end of the simulation frame. — Richard Harrison (Nov 19th, 2015). Re: [Flightgear-devel] HLA developments.
(powered by Instant-Cquotes) |
|
|
|
My next task will be to stitch together simplified tiles, and place them into the directory hierarchy described by the SPT work Mathais did 2 years ago. Note that only fgviewer can currently display scenery in the .SPT hierarchy. Someone still needs to start work on the internal fgfs viewer to get flightgear itself handling multiple LOD terrain.
|
|
FGViewer is intended to become a standalone viewer that is implemented on top of HLA/OpenRTI. It will communicate with a main fgfs master process to update its slave view/cameras - all the other subsystems (FDM, autopilot, weather etc) would merely be visualized by the viewer, but not actually running there - it would get the relevant info from the fgfs master through the RTI. FGViewer use will be completely optional - at the moment it's just there to help with decoupling the viewer/renderer from the underlying simulation, which is code that is quite entangled currently.
So the idea behind the tool is to create a distinct viewer component (still in the early stages of development) which, while still remaining compliant with the FlightGear environment, is trying to adopt as few dependencies from FlightGear as possible and therefore does not necessarily have to follow every rule of "how things are done in fgfs" in order to achieve its fine goal. It's a good idea to factor out the dependencies that the visual part of FlightGear has on the whole flightgear implementation. A large fraction of the time that was spent for the OSG port was required simply to detangle a pile of quite obscure interdependencies between the former viewer code and the so-called FlightGear core.
Carefully cutting some of the old ties (some call them "cruft"), for example by keeping the viewer part as independent from the FlightGear core as possible, might serve as a good platform for future development. It's obvious that FlightGear, as every visual simulation, has to depend on the viewer. But the opposite way of depending the viewer part heavily on core FlightGear components is certainly not going into the outlined direction.
This is a basic version of that tool that might grow if there is a need. Matthias hopes to include more flightgear internal scenery loading stuff so that you can at some time also load aircraft models and see if the static parts / animations / transforms / postprocessing steps are as expected without the need to start the whole simulation.
Status
FGVviewer is not at the point where this is already usable as the viewer is not complete and the code discussed in this section is not yet in an usable state. But if you have just a single configured viewpoint this already works by adding the apropriate HLA objects and attaching the viewer to them. In the long term this is probably the viewer to use as it is designed to be used in an environment like this.
FGViewer gained a lot of unfinished HLA code that enables FGViewer to sit on a HLA configured view - more or less.
Together with FGViewer there is also some work done on the scenegraph that is used there. FGViewer is since some time just able to display a whole world paged model that has the stg/btg files in the leafs. With this work there is also some level of detail work done in the leaf nodes that is used by the usual fgfs scene.
Implementation
The spt loader used in fgviewer also has lod hierarchies built in. You can already load - may be I need to push this series to the latest version - lower level of detail huger tiles if you put them into the right directories. That's in preparation and has no upstream support form the scenery yet.
There is a meta loader for these spt files that encode the area they should cover in the file name before the spt extension.
There are problems with the tiles near the poles. But this is something that the original stg database covers very bad. So the spt loader just reflects this weakness.
In fgviewer there's a PagedLOD whole world database tree running. This is similar to osg's marble dataset but carefully designed around our tile structure. Using this I think we can really replace a lot of our fine structured scenery tiles with something more croase that is used for tiles more far away. Drawback with our current codebase: Our integration of the particle systems need to be rethought as this contains geometry with culling disabled which makes a pagedlod just never expire. Switching the particle systems off works pretty good so far.
Related content
Wiki articles
- SPT Loader
- FlightGear HLA support (High Level Architecture)
- FlightGear CIGI Support (Common Image Generator Interface)