the ascii scenery file format has actually worked in quite some time, and the
ADA runway light code has been supersceded by a slightly different mechanism.
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.
To compile the development CVS version of FlightGear(0.9.0) i had to
apply some small changes to SimGear and FlightGear.
The changes need probably some additional ifdefs for other platforms but
since my linux-hd crashed i can't verify that.
The biggest and coolest patch adds mouse sensitivity to the 3D
cockpits, so we can finally work the radios. This ended up requiring
significant modifications outside of the 3D cockpit code. Stuff folks
will want to look at:
+ The list of all "3D" cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another "update" hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
"mouse press delay", and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
GL/gl.h can't be included at the first position in windows. It requires
the inclusion of windows.h that must be included in other fgfs header
file. I only move down #include <GL/gl.h>
+ The panel(s) are now an first-class SSG node inside the aircraft
scene graph. There's a little code added to model.cxx to handle the
parsing, but most of the changes are inside the new FGPanelNode
class (Model/panelnode.[ch]xx).
+ The old FGPanel source changed a lot, but mostly cosmetically. The
virtual-cockpit code moved out into FGPanelNode, and the core
rendering has been abstracted into a draw() method that doesn't try
to set any OpenGL state. I also replaced the old inter-layer offset
code with glPolygonOffset, as calculating the right Z values is hard
across the funky modelview matrix I need to use. The older virtual
panel code got away with it by disabling depth test, thus the "panel
draws on top of yoke" bug. PolygonOffset is really the appropriate
solution for this sort of task anyway.
+ The /sim/virtual-cockpit property is no more. The 2D panels are
still specified in the -set.xml file, but 3D panels are part of the
model file.
+ You can have as many 3D panels as you like.
Problems:
+ The mouse support isn't ready yet, so the 3D panels still aren't
interactive. Soon to come.
+ Being part of the same scene graph as the model, the 3D panels now
"jitter" in exactly the same way. While this makes the jitter of
the attitude gyro less noticeable, it's still *very* noticeable and
annoying. I looked hard for this, and am at this point convinced
that the problem is with the two orientation computations. We have
one in FGLocation that is used by the model code, and one in
FGViewer that is used at the top of the scene graph. My suspicion
is that they don't agree exactly, so the final orientation matrix is
the right answer plus the difference. I did rule out the FDMs
though. None of them show more than about 0.0001 degree of
orientation change between frames for a stopped aircraft. That's
within an order of magnitude of what you'd expect for the
orientation change due to the rotation of the earth (which we don't
model -- I cite it only as evidence of how small this is); far, far
less than one pixel on the screen.
[and later]
OK, this is fixed by the attached panel.cxx file. What's happened is
that the winding order for the text layer's polygons is wrong, so I
reverse it before drawing. That's largely a hatchet job to make
things work for now, though. We should figure out why the winding
order is wrong for only text layers and fix it. I checked the plib
sources -- they're definitely doing things CCW, as is all the rest of
the panel code.
Odd. I'm also not sure why the 2D panel doesn't care (it works in
both winding orders). But this will allow you to check in working
code, anyway. There's a big comment to this effect in there.
