1
0
Fork 0
Commit graph

2 commits

Author SHA1 Message Date
david
b3bb53b67f Fix a bug reported by Frederic Bouvier:
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>
2002-07-03 04:09:27 +00:00
david
b53cd9c59f 3D panel support from Andy Ross:
+ 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.
2002-06-28 14:17:40 +00:00