scene management code and organizing it within simgear. My strategy is
to identify the code I want to move, and break it's direct flightgear
dependencies. Then it will be free to move over into the simgear package.
- Moved some property specific code into simgear/props/
- Split out the condition code from fgfs/src/Main/fg_props and put it
in it's own source file in simgear/props/
- Created a scene subdirectory for scenery, model, and material property
related code.
- Moved location.[ch]xx into simgear/scene/model/
- The location and condition code had dependencies on flightgear's global
state (all the globals-> stuff, the flightgear property tree, etc.) SimGear
code can't depend on it so that data has to be passed as parameters to the
functions/methods/constructors.
- This need to pass data as function parameters had a dramatic cascading
effect throughout the FlightGear code.
a tile boundary. (Potentially imposes a slight performance penalty, but
getting the correct answer needs to be higher priority than getting the
wrong answer really quickly.)
are now working. A runway light is defined by a point and a direction. The
point and direction are combined with the local up vector to create a small
triangle orthogonal to the direction. The two ficticous corners of the
triangle are given an alpha value of zero, the orignal corner is given an
alpha of one. The triangle is drawn in glPolygonMode(GL_FRONT, GL_POINT)
mode which means only the corner points are drawn, and since two have alpha=0
only the original point is drawn. This is a long way to go to draw a point,
but it ensures that the point is only visible within 90 degrees of the light
direction, behind the light it is not visible. This is still a long way
to get to drawing a point, but we use an environement map, with the direction
vector as the normal to mimic a light that is brightest when viewed head
on and dimmest when viewed perpendicularly or disappears when viewed from
behind.
- warning, there is a bug in how the current runway light direction vector
is calculated which will adversely effect runway lighting. The airports
should be regenerated in order to fix this problem.
fgLoad3DModel() throws an exception if it fails to load the requested model.
This causes FGTileMgr::update(...) to exit. So I've added a try/catch block
to catch the exception and display an error message instead.
Animations are now contained within the scene graph itself and are
updated whenever the graph is traversed -- that saves time by not
updating animations not currently in sight, and it allows animations
to be used for static objects and random objects as well.
Added new FGModelLoader and FGTextureLoader classes. These are intern
tables for models, to guarantee (mostly) that no model is loaded more
than once. FGTextureLoader is not yet used anywhere, but
FGModelLoader is now in place everywhere that ssgLoad* used to be
used (thus adding the ability to use animations).
In the future, FGModelLoader will add some interesting functionality,
including the ability to reload 3D models on the fly.
the tile cache it's ssg elements are disconnected from the main ssg scene
graph, and then the tile is thrown on the end of a delete queue. The
tilemgr->update() routine runs every frame. It looks at this queue and if
it is non-empty, it incrementally frees the compents of the first tile
on the queue. When the tile is completely free it is removed from the queue.
The amount of time to free the memory for even a single tile can be quite
substantial, especially with the increased overhead of dynamic/random
ground objects. This change allows the system to spread the work of freeing
tile memory out over many frames so you don't get a noticable single frame
hit or stutter.
This is a small fix for what turned out to be a major bug. Ground elevation
was calculated incorrectly when distant from one of the view locations. This
resulted in several problems including bizarre gear trimming, mid air
"crashes" (as in thinking we hit the ground) and so on when close to or on the
ground.
Unfortunately it does require a second ssg traversal when in tower view
(only), but the increased load isn't all that noticable. For the time being
this really is the best solution. In a future update I will be eliminating
the unecessary per frame traversals for the static views (without having to
maintain multiple ssgRoots).
When we go to multiple FDM instances we will perhaps need to put the ssg
traversal and ground elevation queries for the FDMs into an event timer that
updates the FDMs ground elevation in a round robin fashion (maybe every 1/n
seconds where n is the number of FDM instances running).
This is a new improved patch for the previous tile manager fixes.
Rather than building dependencies between FGlocation or the viewer or fdm with
tilemgr what I ended up doing was linking the pieces together in the Mainloop
in main.cxx. You'll see what I mean...it's been commented fairly well. More
than likely we should move that chunk somewhere...just not sure where yet.
The changes seem clean now. As I get more ideas there could be some further
improvement in organizing the update in tilemgr. You'll note that I left an
override in there for the tilemgr::update() function to preserve earlier
functionality if someone needs it (e.g. usage independent of an fdm or
viewer), not to mention there are a few places in flightgear that call it
directly that have not been changed to the new interface (and may not need to be).
The code has been optimized to avoid duplicate traversals and seems to run
generally quite well. Note that there can be a short delay reloading tiles
that have been dropped from static views. We could call the tile scheduler on
a view switch, but it's not a big deal and at the moment I'd like to get this
in so people can try it and comment on it as it is.
Everything has been resycned with CVS tonight and I've included the
description submitted earlier (below).
Best,
Jim
Changes synced with CVS approx 20:30EDT 2002-05-09 (after this evenings updates).
Files:
http://www.spiderbark.com/fgfs/viewer-update-20020516.tar.gz
or
http://www.spiderbark.com/fgfs/viewer-update-20020516.diffs.gz
Description:
In a nutshell, these patches begin to take what was one value for ground
elevation and calculate ground elevation values seperately for the FDM and the
viewer (eye position). Several outstanding view related bugs have been fixed.
With the introduction of the new viewer code a lot of that Flight Gear code
broke related to use of a global variable called "scenery.cur_elev".
Therefore the ground_elevation and other associated items (like the current
tile bucket) is maintained per FDM instance and per View. Each of these has a
"point" or location that can be identified. See changes to FGLocation class
and main.cxx.
Most of the problems related to the new viewer in terms of sky, ground and
runway lights, and tower views are fixed.
There are four minor problems remaining. 1) The sun/moon spins when you pan
the "lookat" tower view only (view #3). 2) Under stress (esp. magic carpet
full speed with max visibility), there is a memory leak in the tile caching
that was not introduced with these changes. 3) I have not tested these
changes or made corrections to the ADA or External FDM interfaces. 4) The
change view function doesn't call the time/light update (not a problem unless
a tower is very far away).
Details:
FDM/flight.cxx, flight.hxx - FGInterface ties to FGAircraftModel so that it's
location data can be accessed for runway (ground elevation under aircraft)
elevation.
FDM/larsim.cxx, larcsim.hxx - gets runway elevation from FGInterface now.
Commented out function that is causing a namespace conflict, hasn't been
called with recent code anyway.
FDM/JSBSim/JSBSim.cxx, YASim/YASim.cxx - gets runway elevation from
FGInterface now.
Scenery/newcache.cxx, newcache.hxx - changed caching scheme to time based
(oldest tiles discard).
Scenery/tileentry.cxx, tileentry.hxx - added place to record time, changed
rendering to reference viewer altitude in order to fix a problem with ground
and runway lights.
Scenery/tilemgr.cxx, tilemgr.hxx - Modified update() to accept values for
multiple locations. Refresh function added in order to periodically make
the tiles current for a non-moving view (like a tower).
Main/fg_init.cxx - register event for making tiles current in a non-moving
view (like a tower).
Main/location.hxx - added support for current ground elevation data.
Main/main.cxx - added second tilemgr call for fdm, fixed places where viewer
position data was required for correct sky rendering.
Main/options.cxx - fixed segfault reported by Curtis when using --view-offset
command line parameter.
Main/viewer.cxx, viewer.hxx - removed fudging of view position. Fixed numerous
bugs that were causing eye and target values to get mixed up.
graph as the terrain, except for internal cockpit view. The SSG
scene-graph variables (except for the lighting root -- I'll get that
later) are now held in globals.hxx.
FGModelMgr::draw() is obsolete; I'll remove it in a future revision.
Description:
This update includes the new viewer interface as proposed by David M. and
a first pass at cleaning up the viewer/view manager code by Jim W.
Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and
modified the Makefile.am accordingly.
Detail of work:
Overall:
The code reads a little easier. There are still some unnecessary bits in
there and I'd like to supplement the comments in the viewer.hxx with a tiny
bit on each interface group and what the groupings mean (similar but briefer
than what you emailed me the other day). I tried not to mess up the style,
but there is an occasional inconsistency. In general I wouldn't call it done
(especially since there's no tower yet! :)), but I'd like to get this out
there so others can comment, and test.
In Viewer:
The interface as you suggested has been implemented. Basically everything
seems to work as it did visually. There is no difference that I can see in
performance, although some things might be a tiny bit faster.
I've merged the lookat and rph (pilot view) code into the recalc for the
viewer. There is still some redundancy between the two, but a lot has been
removed. In some cases I've taken some code that we'd likely want to inline
anyway and left it in there in duplicate. You'll see that the code for both
looks a little cleaner. I need to take a closer look at the rotations in
particular. I've cleaned up a little there, but I suspect more can be done
to streamline this.
The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO
the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about
to rip it out. It would seem that there more conventional ways to get
spherical data that are just as fast. In any case all the viewer was pulling
from the quat matrix was the pitch value so I modified mouse.cxx to output to
our pitchOffset input and that works fine.
I've changed the native values to degrees from radians where appropriate.
This required a conversion from degrees to radians in a couple modules that
access the interface. Perhaps we should add interface calls that do the
conversion, e.g. a getHeadingOffset_rad() to go along with the
getHeadingOffset_deg().
On the view_offset (now headingOffset) thing there are two entry points
because of the ability to instantly switch views or to scroll to a new view
angle (by hitting the numeric keys for example). This leaves an anomaly in
the interface which should be resolved by adding "goal" settings to the
interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc.
Other than these two issues, the next step here will be to look at some
further optimizations, and to write support code for a tower view. That
should be fairly simple at this point. I was considering creating a
"simulated tower view" or "pedestrian view" that defaulted to a position off
to the right of whereever the plane is at the moment you switch to the tower
view. This could be a fall back when we don't have an actual tower location
at hand (as would be the case with rural airports).
ViewManager:
Basically all I did here was neaten things up by ripping out excess crap and
made it compatible as is with the new interface.
The result is that viewmanager is now ready to be developed. The two
preexisting views are still hardcoded into the view manager. The next step
would be to design configuration xml (eg /sim/view[x]/config/blahblah) that
could be used to set up as many views as we want. If we want to take the easy
way out, we might want to insist that view[0] be a pilot-view and have
viewmanager check for that.
separate header file. This change will help integrate properties into
JSBSim.
Also, I (David Megginson) removed most of the SimGear include
statements from globals.hxx, reducing the amount of recompilation
every time SimGear changes. This required making minor changes to a
lot of files that were depending on the side-effects of the inclusions
in globals.hxx.
Added two new properties:
/environment/temperature-sea-level-degc
/environment/pressure-sea-level-inhg
These are now supported in FGEnvironment as well, though they always
have the same value for now. They need to be hooked up to the FDMs.
different locations, and hitched it into FGGlobals. FGEnvironmentMgr
has taken over as the subsystem, while FGEnvironment is simple the
information that it returns. I've removed current_environment
completely -- everything now uses properties or goes through
FGGlobals. FGGlobals itself has a couple of useful methods:
const FGEnvironment * get_environment ();
const FGEnvironment * get_environment (double lat, double lon, double alt);
The first one returns the environment data for the plane's current
position, while the second returns the environment data for any
arbitrary location. Currently, they both return the same information,
but that will change soon.
properties have been renamed from wind-(north|east|down)-fps to
wind-from-(north|east|down)-fps, and the FDMs modified appropriately.
No other changes should be visible unless FG_OLD_WEATHER is defined.
are being driven from an external data source.)
Akso found and fixed a bug in the simgear that caused the time to go goofy
temporarily while scenery was being loaded.
What was happening was that we screwed up and scheduled tiles for
(lon,lon) rather than (lon,lat) ... note the typo. This generated
bogus tile id's which the system happily accepted, put into the tile
cache system, and attempted to load. The problem was that these bogus
tile id's were negative where as all valid tile id's should be >= 0.
These negative tile id's up the logic used to remove tiles from the
cache. When identifying tiles for removal, we look for the furthest
tile away from us by starting out the furthest id at -1 and if we find
something further, we update the furthest tile id. Then at the end we
check if the furthest tile id >= 0 to see if we found anything we
could remove. However, the furthest tile id was these bogus tiles
with negative tile id's so the system always assumed there was nothing
appropriate for removal. This made it impossible to ever remove a
tile from the cache meaning it quickly filled up and no more tiles
could be loaded.
I fixed the one instance of scheduling tiles for a bogus location, and
added a sanity check so if it ever happens again we'll bomb with an
appropriate error message.
fix startup sequence problems where we initialize the FDM before we know
the desired starting altitude.
These changes delay fdm initialization until the local tile has been loaded
and we can do a real intersection and find the true ground elevation.
In order to do this, I depend more on the property manager as glue, rather
than the FGInterface.
There are some glitches still when switching to a new airport or reseting
the sim. I will work on addressing these, but I need to commit the changes
so far to keep in sync with other developers.
but no entries qualify for removal. It will keep trying to schedule the
tile(s) until an entry frees up. Entries in the cache do not qualify for
removal if they are in the process of being loaded.
a crash when relocating to a new airport. Pending work from the old
area is now just completed as normal, rather than trying to empty the various
queues in their various stages when can lead to many problems in a threaded
environment.
