OK, as promised, I have the "fixed" 3D panel support ready for testing
(http://plausible.org/andy/vpanel-20020624.tar.gz). Changes include:
+ 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.
So grab the source and unpack it into your FlightGear source
directory. The first thing you will notice is that the old virtual
cockpits aren't virtual anymore. You will need to put them into the
aircraft model file. This is the syntax I added to the a4-blue.xml
model files to get a panel that matches Jim's current work (I haven't
done any of the other planes yet):
<panel>
<path>Aircraft/a4/a4-panel.xml</path>
<bottom-left>
<x-m>-3.21</x-m>
<y-m>-0.24</y-m>
<z-m> 0.44</z-m>
</bottom-left>
<bottom-right>
<x-m>-3.21</x-m>
<y-m> 0.24</y-m>
<z-m> 0.44</z-m>
</bottom-right>
<top-left>
<x-m>-3.21</x-m>
<y-m>-0.24</y-m>
<z-m> 0.69</z-m>
</top-left>
</panel>
That is, you tell the model to include a given 2D panel file, and map
it to the quadrilateral defined by the three points. The "nominal"
size of the panel is still specified in the panel XML file, as the <w>
and <h> properties; these values are used for the mapping.
Note that the coordinates are "plib" or "JSBSim" coordinates, and
*not* the numbers you find in the .ac file. The plib AC3D loader
swaps the Y and -Z axes at load time. We should probably pick one
convention (the view offsets use yet another, as does YASim) and make
everything conform.
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.
Andy
--
Andrew J. Ross NextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
