Here are the Boost-less FGEventMgr updates I promised.
Removed Boost dependencies from FGEventMgr.
Removed Boost configure check.
fgMethodCallback now handles const member functions.
I've successfully tested these changes with gcc and msvc.
Synced to CVS 19:36 EDT 2002-04-10 (after this evenings JSMsim and Base
package updates).
Description:
Added FGLocation class which is new home for calculating matrix rotations.
Viewer can now be configured to access rotations created by the model rather
than repeating the same calculations again.
Changed model initialization for the time being so that its location data is
available for the viewer (currently required by other subsystems). At some
point we can move this back to fg_init along with the viewer initialization.
Seperated the update from the draw function in the model code. The viewer
code needs the same matrix data, and moving the update portion at this time
does not increase the number of matrix math iterations.
Moved the model draw so that it always appears "in front" of lights and clouds.
Reogranized viewer update routine for using the FGLocation class and
simplified some more tasks. The routine is fairly easy to follow now, with
the steps ordered and spelled out in comments.
Viewmgr only updates the current (visible) view now, with the exception of an
old reference to "chase view" that will be corrected in forthcoming changes.
Also will be doing some work on the viewmgr outputs.
Model is now clears the z-buffer in all modes. This will be changed with the
next viewmgr update. The only side effect is that models always disappear
when over 5km distant from the eye point (can't really see them anyway:-)).
Other than a flag to indicate "internal" view I don't anticipate the
configuration interface for viewmgr/views will be changed a lot for now. It
is close to done. The next viewmgr update will however rework the outputs so
may change location.
This code will run with the previous version of preferences.xml, but will run
faster with the newer version. I am attaching a preferences.xml that should
not be commited before the code. All the changes are in the /sim/view section
and should show a simpler view configuration that references model locations.
Note that I've added a 2nd tower view in "lookfrom" mode for illustration
purposes. You can look around using the mouse. You may want to remove that or
comment it out.
I made these modifications to correct the problem of getter functions
returning pointers to local variables. Those variables are no longer
locals and become static. One should be aware that it kills reentrancy
!
This patch moves built-in Class (for now only mag-ribbon) into special
directory as you have written it in TODO: in comments of this class in
panel_io.cxx. IMHO it is good idea. I want to play with built-in
classes and OpenGC and this will be useful.
Minor patches to initial tower view code. Added calculation for "tower" at
any airport, placed a couple fractions of a degree off the center. Moved the
farplane from 100m to 5km so that "lookfrom" mode can see the model. 5km is
still in a reasonable range for a depth buffer. Note that looking at a model
anything but a small distance will cause some problems on older cards.
Temporarily changed viewer to always report elevation/lon/lat of the aircraft
in order to avoid a problem with the ground trim getting recalculated when
tower and aircraft are on different tiles.
radiostack.cxx, fg_init.cxx and main.cxx. If these changes are accepted
then you can remove Time/event.[ch]xx and Include/fg_callback.hxx from
the repository.
Tower View and viewer config is in place. Note that the interface is
still in a state of flux. A couple of the config items (namely the
offsets) are still using the old settings. The tower is hard coded
into the base package for a position off the starting runway at KSFO
and is probably not in the right place for there even. Looks pretty
cool though! Tower View is the third view. If you aren't at KSFO
you'll just see blank space in view 3. It's looking through the earth or
something like that :-). Important note: zoom in with a few
hits of the "x" key to see the plane better in tower view.
case logging is disabled). This way, when people specify a
non-existant aircraft or have an error in a custom XML file, they'll
get an error report, at least.
system. A chap from Germany called Alexander Kappes (cc'd) got
in touch with me a few weeks ago and has written the start of
Approach control. At the moment tuning in to a valid approach
frequency (Dortmund or East Midlands) should result in vectors to
a spot about 3 miles from the active runway, and a telling off if you
stray too far from the correct course, in the console window. He
seems to know what he's doing so expect this to improve rapidly!!
I've added a rudimentry AI manager and a hardwired Cessna at
KEMT on the runway - I'll remove it before the next release if I don't
have it flying by then. There seems to be an issue with framerate
which drops alarmingly when looking at it - I've a feeling that I've
possibly created several Cessnas on top of each other, but am not
sure.
and specific animation types are derived from it. This change makes
the code much easier to read, maintain, and extend.
Added a 'translate' animation type for a scaled, 3D linear translation
(such as a sliding throttle knob).
Renamed the 'offset' property to 'offset-m' or 'offset-deg' as
appropriate; ditto for 'min' and 'max' properties.
Clear frame buffer and render model after rest of 3D scene. This has a
small frame rate cost (YMV). But who thought 3D cockpit would be cheap?
If anyone has a better idea, have at it!
Just did some more careful testing and I see little or no frame rate loss
with the depth buffer clear. Also you can change the near plane to 0.1
and get rid of the "sunroof" (so I don't have to make up another set of
patches.
This patch creates a seperate scene graph for the cockpit. The near plane is
only moved up when in the interior (pilot) view. This is because with
rounding (I presume) it the visible ground is a bit up higher than it is with
the older nearplane setting. Not much, but it is enough to bury the wheels.
I suspected this might be true but spliting to two sg's confirms it. If
necessary we can adjust the model up a bit when in interior view. This might
be good so we can set the near plane even closer when in the cockpit (its
still at 0.2m).
In general this looks a lot better on my Voodoo with this patch. No
perceptibel change in frame rate on my system. In terms of future plans I'd
see the sense in making the model plug into either scene. This will be
necessary when we have multiple model instances in the frame.
The matrix doesn't define some cells, which are actually used
in the multiplication. That makes the result unpredictable.
I have no idea if 0.0 is the correct value for these, but
garbage is hardly the correct value either. Should some of them
be set to 1.0?
Think my brain is getting clogged with matrices :-). Well I've got the funky
orientation offset bug out of the model code. In the process the model.cxx
got optimized a bit. At some point we'll need to liberate model.cxx from the
viewer class, but it is no longer hard coded to access the "pilot view" to
get it's data. Instead it uses whatever the "current" view happens to be. I
may try and do that final bit of having models rotate independant of the view
tomorrow night, or start right in on the viewmgr and get a tower view up and
running. You guys have any preference? My brother's family is coming to
visit for a few days so what I don't get done tomorrow night probably won't
get done until after the weekend.
Fix FGViewer::update so that pitch offset and goal pitch offset work
together nicely (the offset was snapping to 90/-90 when only one of
the two was changed).
Viewer improvements from Jim Wilson:
These files get the 3d cockpit working and fix a few issues in the viewer
code.
XYZ offsets are now defined as follows: X -left/right+ (along wing axis), Y
-up/down+ perpendicular to the aircraft, Z is -in/out+ the aircraft's body axis.
I've also done some cleaning up of unused and mostly unusable interfaces,
added commentary to the *.hxx, combined together some duplicate code and
eliminated a couple unecessary operations. I also moved what was left of the
"protected" zone to "private" since we aren't subclassing this anymore.
(mainly in src/Input/input.cxx) will make src/GUI/mouse.cxx obsolete
and bring the mouse into the same input system as the joystick and
keyboard. This is just preliminary work allowing, covering mouse
clicks (no motion yet), and it actually crashes on a middle or right
click.
The new mouse support is disabled by default until it become stable;
to try it out, you need to configure --with-new-mouse.
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.
