[Flightgear-devel] New panel code
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): Aircraft/a4/a4-panel.xml -3.21 -0.24 0.44 -3.21 0.24 0.44 -3.21 -0.24 0.69 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 and 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. RossNextBus 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
Re: [Flightgear-devel] New panel code
Andy Ross <[EMAIL PROTECTED]> said: > + 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. Actually both the model code and the viewer use the FGLocation class, so the data should be the same. The major difference is in the application of the various view offsets which are applied to the FGLocation data in the Viewer and not the model. Note that in cockpit view, the viewer actually accesses the same exact instance of FGLocation that the model uses, so it has to be the same orientation data going in. If there is, as it appears, a variance between the two matrices as they get applied to the view and model, it would have to be attributable to a mathematical error that varies in its effect depending on the specific values involved. Remember the viewer code does apply offsets. Otherwise, it would have to be an issue related to the copying of data that also varies in its effect depending on the specific values. At some point this week I should have time to trace these values and see what is going on. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New panel code
David Megginson wrote: > 1. Can you post a copy of your modified base-package files >(a4-yasim-set.xml and a4-blue.xml)? The -set files don't require any significant changes -- just remove the entries and that's it. The model files for the A-4 and 172 are attached. All they needed is a entry like the one I posted. > 2. Are you willing to do the 3D C172 file? I don't want to put your >patches in CVS if they'll kill the current 3D cockpit for the 172; OK, attached. I just lifted some rough coordinates from AC3D's demo program and twiddled a bit to get it to look more or less OK. It's not polished, but it'll do. The mag compass is partly obscured by geometry -- it should really move into its own panel somewhere else, or be modeled in full 3D. Also, the background texture doesn't quite match the geometry it's drawn on. But it's there, it works, and it's drawn *behind* the yoke. :) One thing is wrong, though: Something is drawing the 2D panel, even though I removed the entries from the -set.xml file. I'm flummoxed on this one. It's not part of my code changes, as it's there regardless of whether the 3D panel exists or not. It doesn't happen on the A-4; is it possible that something has hard-coded the 172's panel somewhere? Andy -- Andrew J. RossNextBus 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) c172-dpm.ac Aircraft/c172/Panels/c172-vfr-panel.xml -0.12 -0.64 -0.36 -0.12 0.64 -0.36 -0.17 -0.64 0.06 range 0 1 range Cabin Seat.1 Seat.2 Seat.3 Seat.4 0 50 range Yoke.1 Yoke.2 Pedal.1 Pedal.2 Pedal.3 Pedal.4 Throttle Mixture Compass Pedestal 0 3 select Propeller /engines/engine[0]/rpm 1500 select Propeller.2 /engines/engine[0]/rpm 1000 translate Throttle /controls/throttle[0] -0.1 1.0 0.0 0.0 translate Mixture /controls/mixture[0] -0.1 1.0 0.0 0.0 translate Yoke.1 /controls/elevator -0.1 1.0 0.0 0.0 rotate Yoke.1 /controls/aileron -45.0 1.0 0.0 0.0 0 -.26 -.29 translate Yoke.2 /controls/elevator -0.1 1.0 0.0 0.0 rotate Yoke.2 /controls/aileron -45.0 1.0 0.0 0.0 0 .27 -.29 translate Pedal.1 Pedal.3 /controls/rudder 0.1 1.0 0.0 0.0 rotate Pedal.1 Pedal.3 /controls/brakes[0] -15 0.0 1.0 0.0 -0.1 0 -0.9 translate Pedal.2 Pedal.4 /controls/rudder -0.1 1.0 0.0 0.0 rotate Pedal.2 Pedal.4 /controls/brakes[1] -15 0.0 1.0 0.0 -0.1 0 -0.9 rotate NoseWheel /surface-positions/rudder-pos-norm -20 -0.8 0.0 -0.8 0 0 1 spin Propeller /engines/engine[0]/rpm -1 0 0 -.25 1.0 0.0 0.0 rotate LeftAileron /surface-positions/left-aileron-pos-norm -1.0 15 0.0 0 1.0 -20 0.94 -3.83 0.40 -0.15 -1.00 0.03 rotate RightAileron /surface-positions/right-aileron-pos-norm -1.0 -20 0.0 0 1.0 15 0.94 3.83 0.40 -0.15 1.00 0.03 rotate LeftFlap RightFlap /surface-positions/flap-pos-norm 30 1.1 0.0 0.45 0.0 1.0 0.0 rotate LeftElevator RightElevator /surface-positions/elevator-pos-norm -1.0 -28 0 0 1.0 23 5.1 0.0 -0.45 0.0 1.0 0.0 rotate Rudder /surface-positions/rudder-pos-norm 17.5 5.45 0.0 0.0 0.72 0.0 1.0 a4-blue.ac Aircraft/a4/Models/attitude.xml -3.25 -0.058 0.54 Aircraft/a4/a4-panel.xml -3.21 -0.24 0.44 -3.21 0.24 0.44 -3.21 -0.24 0.69 select Pilot /sim/current-view/y-offset-m 0.77 rotate LeftGear /gear/gear[1]/position-norm -120 -1 0 90 0.76 -1.05 -0.68 0 1 0 rotate LeftGear /gear/gear[1]/position-norm -120 -1 0 90 0.76 -1.05 -0.68 0 0 -1 rotate LeftGearStrut /gear/gear[1]/position-norm 45 -1 -0.20 -1.0 -0.69 0 1 0 rotate LeftGearDoor /gear/gear[1]/position-norm -360 -0.25 0 90 -0.20 -1.20 -0.69 1 0 0 rotate RightGear /ge
