1
0
Fork 0
flightgear/src/Model/panelnode.cxx

189 lines
5.9 KiB
C++
Raw Normal View History

#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
#include <simgear/compiler.h>
2002-10-29 19:44:03 +00:00
#include <vector>
#include <GL/gl.h>
#include <plib/sg.h>
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
#include <Main/fg_props.hxx>
#include <Cockpit/panel.hxx>
#include <Cockpit/panel_io.hxx>
#include "panelnode.hxx"
2002-10-29 19:44:03 +00:00
// Static (!) handling for all 3D panels in the program. Very
// clumsy. Replace with per-aircraft handling.
vector<FGPanelNode*> all_3d_panels;
bool fgHandle3DPanelMouseEvent(int button, int updown, int x, int y)
{
for(int i=0; i<all_3d_panels.size(); i++)
if(all_3d_panels[i]->doMouseAction(button, updown, x, y))
return true;
return false;
}
void fgUpdate3DPanels()
{
for(int i=0; i<all_3d_panels.size(); i++)
all_3d_panels[i]->getPanel()->updateMouseDelay();
}
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
FGPanelNode::FGPanelNode(SGPropertyNode* props)
{
// Make an FGPanel object. But *don't* call init() or bind() on
// it -- those methods touch static state.
_panel = fgReadPanel(props->getStringValue("path"));
2002-10-29 19:44:03 +00:00
// Never mind. We *have* to call init to make sure the static
// state is initialized (it's not, if there aren't any 2D
// panels). This is a memory leak and should be fixed!`
_panel->init();
// Initialize the matrices to the identity. PLib prints warnings
// when trying to invert singular matrices (e.g. when not using a
// 3D panel).
for(int i=0; i<4; i++)
for(int j=0; j<4; j++)
_lastModelview[4*i+j] = _lastProjection[4*i+j] = i==j ? 1 : 0;
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
// Read out the pixel-space info
_xmax = _panel->getWidth();
_ymax = _panel->getHeight();
// And the corner points
SGPropertyNode* pt = props->getChild("bottom-left");
_bottomLeft[0] = pt->getFloatValue("x-m");
_bottomLeft[1] = pt->getFloatValue("y-m");
_bottomLeft[2] = pt->getFloatValue("z-m");
pt = props->getChild("top-left");
_topLeft[0] = pt->getFloatValue("x-m");
_topLeft[1] = pt->getFloatValue("y-m");
_topLeft[2] = pt->getFloatValue("z-m");
pt = props->getChild("bottom-right");
_bottomRight[0] = pt->getFloatValue("x-m");
_bottomRight[1] = pt->getFloatValue("y-m");
_bottomRight[2] = pt->getFloatValue("z-m");
2002-10-29 19:44:03 +00:00
// Now generate our transformation matrix. For shorthand, use
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
// "a", "b", and "c" as our corners and "m" as the matrix. The
// vector u goes from a to b, v from a to c, and w is a
// perpendicular cross product.
float *a = _bottomLeft, *b = _bottomRight, *c = _topLeft, *m = _xform;
float u[3], v[3], w[3];
int i;
for(i=0; i<3; i++) u[i] = b[i] - a[i]; // U = B - A
for(i=0; i<3; i++) v[i] = c[i] - a[i]; // V = C - A
w[0] = u[1]*v[2] - v[1]*u[2]; // W = U x V
w[1] = u[2]*v[0] - v[2]*u[0];
w[2] = u[0]*v[1] - v[0]*u[1];
// Now generate a trivial basis transformation matrix. If we want
// to map the three unit vectors to three arbitrary vectors U, V,
// and W, then those just become the columns of the 3x3 matrix.
m[0] = u[0]; m[4] = v[0]; m[8] = w[0]; m[12] = a[0]; // |Ux Vx Wx|
m[1] = u[1]; m[5] = v[1]; m[9] = w[1]; m[13] = a[1]; // m = |Uy Vy Wy|
m[2] = u[2]; m[6] = v[2]; m[10] = w[2]; m[14] = a[2]; // |Uz Vz Wz|
m[3] = 0; m[7] = 0; m[11] = 0; m[15] = 1;
// The above matrix maps the unit (!) square to the panel
// rectangle. Postmultiply scaling factors that match the
// pixel-space size of the panel.
for(i=0; i<4; i++) {
m[0+i] *= 1.0/_xmax;
m[4+i] *= 1.0/_ymax;
}
// Now plib initialization. The bounding sphere is defined nicely
// by our corner points:
float cx = (b[0]+c[0])/2;
float cy = (b[1]+c[1])/2;
float cz = (b[2]+c[2])/2;
float r = sqrt((cx-a[0])*(cx-a[0]) +
(cy-a[1])*(cy-a[1]) +
(cz-a[2])*(cz-a[2]));
bsphere.setCenter(cx, cy, cz);
bsphere.setRadius(r);
2002-10-29 19:44:03 +00:00
// All done. Add us to the list
all_3d_panels.push_back(this);
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
}
FGPanelNode::~FGPanelNode()
{
delete _panel;
}
void FGPanelNode::draw()
{
// What's the difference?
draw_geometry();
}
void FGPanelNode::draw_geometry()
{
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glMultMatrixf(_xform);
2002-10-29 19:44:03 +00:00
// Grab the matrix state, so that we can get back from screen
// coordinates to panel coordinates when the user clicks the
// mouse.
glGetFloatv(GL_MODELVIEW_MATRIX, _lastModelview);
glGetFloatv(GL_PROJECTION_MATRIX, _lastProjection);
glGetIntegerv(GL_VIEWPORT, _lastViewport);
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
_panel->draw();
2002-10-29 19:44:03 +00:00
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
glPopMatrix();
}
2002-10-29 19:44:03 +00:00
bool FGPanelNode::doMouseAction(int button, int updown, int x, int y)
{
// Covert the screen coordinates to viewport coordinates in the
// range [0:1], then transform to OpenGL "post projection" coords
// in [-1:1]. Remember the difference in Y direction!
float vx = (x + 0.5 - _lastViewport[0]) / _lastViewport[2];
float vy = (y + 0.5 - _lastViewport[1]) / _lastViewport[3];
vx = 2*vx - 1;
vy = 1 - 2*vy;
// Make two vectors in post-projection coordinates at the given
// screen, one in the near field and one in the far field.
sgVec3 a, b;
a[0] = b[0] = vx;
a[1] = b[1] = vy;
a[2] = 0.75; // "Near" Z value
b[2] = -0.75; // "Far" Z value
// Run both vectors "backwards" through the OpenGL matrix
// transformation. Remember to w-normalize the vectors!
sgMat4 m;
sgMultMat4(m, *(sgMat4*)_lastProjection, *(sgMat4*)_lastModelview);
sgInvertMat4(m);
sgFullXformPnt3(a, m);
sgFullXformPnt3(b, m);
// And find their intersection on the z=0 plane. The resulting X
// and Y coordinates are the hit location in panel coordinates.
float dxdz = (b[0] - a[0]) / (b[2] - a[2]);
float dydz = (b[1] - a[1]) / (b[2] - a[2]);
int panelX = (int)(a[0] - a[2]*dxdz + 0.5);
int panelY = (int)(a[1] - a[2]*dydz + 0.5);
return _panel->doLocalMouseAction(button, updown, panelX, panelY);
}
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
void FGPanelNode::die()
{
SG_LOG(SG_ALL,SG_ALERT,"Unimplemented function called on FGPanelNode");
2002-10-29 19:44:03 +00:00
exit(1);
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
}