RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Is SDL something we want to commit to? FWIW - I don't see what this gets us but . since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option i.e. since all of the pertinent routines are supposedly hidden in the 'misnamed' fg_os.cxx file the underlying toolkit could be a compile time option. this module has *nothing* to do with the OS involved i.e there is no #include windows.h :-) IMHO It would be a mistake to get rid of one dependency by just replacing with another Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Mon, 2004-04-05 at 16:04, Jim Wilson wrote: As it is now we need to test every single JSBSim aircraft every time a modification is made to flightgear because the trim routine is lacks robustness. Sorry, but this is simply not true. In this case it is a thing of an interface definition. If you tell me that I can rely on /sim/presets, I *will* rely on them. If I could not rely on these values, I ask myself why they are there. Or at least why they are accessible to my FDM. You just have to fulfill your own claims how this interface works. Suggestion: Create and give each FGInterface an own subdirectory of the property tree. An FDM itself should then restrict its accesses to the property tree to values inside this directory. This would 1. open the possibility of different FDM in the same flightgear instance. 2. make clear which properties are thought to be for this FDM. For point 1 think of a fdm of our current aircraft and a net fdm's from a different machine. You will then be able to see all aircraft full animated just by including the whole property subtree in the net fdm. Eric called some time ago not to use a leading / for animation properties. I think that he is heading in this direction anyway. True, Eric? For point 2 I would think that this subtree must look exactly the same if I reset the simulation. Values outside need not meet this requirement. This would just clearify what to expect and what is required to provide. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Mathias Fröhlich wrote: Suggestion: Create and give each FGInterface an own subdirectory of the property tree. An FDM itself should then restrict its accesses to the property tree to values inside this directory. This would 1. open the possibility of different FDM in the same flightgear instance. 2. make clear which properties are thought to be for this FDM. For point 1 think of a fdm of our current aircraft and a net fdm's from a different machine. You will then be able to see all aircraft full animated just by including the whole property subtree in the net fdm. Eric called some time ago not to use a leading / for animation properties. I think that he is heading in this direction anyway. True, Eric? True. I was working on David Culp's AIModel class and wanted to get animations working for every independent model. The way it was the animations where shared with the main FDM (like the default c172), but the AIModel class now holds it's own set of FDM specific properties in the /a1/models/aircraft[] subtrees. This is actually quite flexible and I want to urge anyone to follow that approach because it opens up a whole new set of possibilities for further development (the radar class being one of them). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Lights and plib
I've not even tried if moving the objects in (0,0,0) makes them work fine. I'll try today (perharps, if I've enought time). About the textures problem I've asked some time ago on the PLIB mailing list and we've found that 3dsMAX doesn't use a standard to read the rgb files. So it seems that it load them upside down respect to PLIB loader. However it's a minor problem, that could be solved quicky. Or are there different 3ds format versions? If I understand the question, I could tell you that the ASE format is different from 3ds format. It's like the ac3d files, where all the informations about the scene are readable (the data it's not compressed or codified). Hi, Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TaxiDraw website
I've put an initial revision of a website for TaxiDraw up, including a tutorial on it's use. http://www.nottingham.ac.uk/~eazdluf/taxidraw.html Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] More on JSBSim ground trimming issue
Jon Berndt said: Thanks for the explanation. This does more than I originally thought. Would some sanity checks at the JSBSim.cxx level help? I'm not sure what they would be, other than the one mentioned before (that relates to this latest bug): make sure we have wheels above the ground. To test that we'd need to know where the wheels were (e.g. z distance from the vrp). Best, Jim The VRP is really for FlightGear only. We know where the CG is and everything else is relative to that. We explicitly calculate the offset from the CG to the gear contact points during the ground reactions calculations, so we do know (or can determine) the Z _offset_ of the gear contact points below the CG -- which, in turn, would allows us to calculate where the CG would need to be placed to make sure the gear would be above ground. If the airplane is on a steeply-incline triangle near the edge, all bets are off. That makes sense. When and if gear compression modeling: will that complicate this or vice versa? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] More on JSBSim ground trimming issue
That makes sense. When and if gear compression modeling: will that complicate this or vice versa? Do you mean visual modeling of gear compression? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw website
David Luff wrote: I've put an initial revision of a website for TaxiDraw up, including a tutorial on it's use. http://www.nottingham.ac.uk/~eazdluf/taxidraw.html Good work -- thanks for putting that up. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option Uh, that's the whole point. What would you prefer, if not SDL? If you want to write a windows-only implementation, feel free. The problems with glut are well-documented. It is no longer developed, doesn't track changes in the underlying systems (mode switching has never worked under XFree86, for example), is not free software, is being dropped by most linux distributions, and is filled with cruft that we don't use. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] More on JSBSim ground trimming issue
Jon Berndt said: That makes sense. When and if gear compression modeling: will that complicate this or vice versa? Do you mean visual modeling of gear compression? As opposed to? I suppose you could say everything I'm asking about is visual, since I'm neither a pilot nor an engineer :-) It would be nice to eventually have the compression values to pull off visual modeling, similar to YASim's output (or an alternative that might be better). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 6 Apr 2004 14:05:38 - Jim Wilson [EMAIL PROTECTED] wrote: Jon Berndt said: As opposed to? I suppose you could say everything I'm asking about is visual, since I'm neither a pilot nor an engineer :-) It would be nice to eventually have the compression values to pull off visual modeling, similar to YASim's output (or an alternative that might be better). We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt wrote: On Tue, 6 Apr 2004 14:05:38 - Jim Wilson [EMAIL PROTECTED] wrote: Jon Berndt said: As opposed to? I suppose you could say everything I'm asking about is visual, since I'm neither a pilot nor an engineer :-) It would be nice to eventually have the compression values to pull off visual modeling, similar to YASim's output (or an alternative that might be better). We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? normalized compression would be great: gear/gear[]/compression-norm Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 06 Apr 2004 16:46:53 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon wrote: We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? normalized compression would be great: gear/gear[]/compression-norm Erik Now, the question is how do we match up the 3D model gear strut with the FDM gear? Is there a common gear numbering scheme? How about gear that have swiveling bogeys (747, etc.)? Skids (X-15)? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 11:41:43 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: To Whom it May Concern, and to Whomever may be of assistance, I'm working on modifying a jsbsim FDM to represent an RPV with an autonomous autopilot. The autopilot and gnc systems are designed in Simulink, and we're using flight gear as the visual and dynamics model for the aircraft. I'm having a hard time maintaining an altitude hold, and I believe it is due to my lack of knowledge in terms of incorporating an engine and propeller model. I'm using an existing engine, and prop model, but our specific aircraft is equipped with an electric motor, and I don't see any examples of these in Flight Gear. The GNC system seems to be responding correctly, as is the velocity hold portion of the autopilot, but I'm not getting any response from the aircraft with an increase in thrust or power. Any advice on how to modify the engine or prop file for an electric motor would be greatly appreciated. thanks for the time Very interesting. As you point out, we have not modeled an electric engine, yet, so I guess somehow you have hacked together an electric engine. I'd be interested to see that ... Without seeing your configuration file, it's hard to make a good recommendation, but I would ask if you have tried the data logging feature of JSBSim, yet? You can log a lot of data that I would use to diagnose the problem. You would adjust the OUTPUT section of the aircraft config file to do this. Are you aware of this capability? What are you allowed to share (for debugging purposes) as far as config files go? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Modifying Existing FDM
To Whom it May Concern, and to Whomever may be of assistance, I'm working on modifying a jsbsim FDM to represent an RPV with an autonomous autopilot. The autopilot andgnc systems are designed in Simulink, and we're using flight gear as the visual and dynamics model for the aircraft. I'm having a hard time maintaining an altitude hold, and I believe it is due to my lack of knowledge in terms of incorporating an engine and propeller model. I'm using an existing engine, and prop model, butour specific aircraft is equipped with an electric motor, and I don'tsee any examples of these in Flight Gear. The GNC system seems to be responding correctly, as is the velocity hold portion of the autopilot, but I'm not getting any response from the aircraft with an increase in thrust or power. Any advice on how to modify the engine or prop file for an electric motor would be greatly appreciated. thanks for the time sonny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt wrote: On Tue, 06 Apr 2004 16:46:53 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon wrote: We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? normalized compression would be great: gear/gear[]/compression-norm Now, the question is how do we match up the 3D model gear strut with the FDM gear? Is there a common gear numbering scheme? How about gear that have swiveling bogeys (747, etc.)? Skids (X-15)? Hmm, Andy has done this already for YASim so he (or Lee Elliott who has been using them) might explain how gear numbering is solved for YASim. That way the animation files would work between FDM's. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt said: On Tue, 06 Apr 2004 16:46:53 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Jon wrote: We do have those values. I just never thought about publishing them. What do you need? What does YASim provide? What would be best? normalized compression would be great: gear/gear[]/compression-norm Erik Now, the question is how do we match up the 3D model gear strut with the FDM gear? Is there a common gear numbering scheme? How about gear that have swiveling bogeys (747, etc.)? Skids (X-15)? How do you id them in JSBSim? With YASim the gear entries are specified in configuration xml including physical location, spring and damping features, existance of brakes, etc. Each gear entry is numbered 0,1,2, and the output paths correspond. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jim Wilson wrote: Jon S Berndt said: Now, the question is how do we match up the 3D model gear strut with the FDM gear? Is there a common gear numbering scheme? How about gear that have swiveling bogeys (747, etc.)? Skids (X-15)? How do you id them in JSBSim? With YASim the gear entries are specified in configuration xml including physical location, spring and damping features, existance of brakes, etc. Each gear entry is numbered 0,1,2, and the output paths correspond. JSBSim does basically the same (although there is a name allocated for it), but the real question is: Is left most defined 0, or is right mos define d0, or is it something completely different (numbered in order of appearance)? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 06 Apr 2004 18:58:03 +0200 Erik Hofman [EMAIL PROTECTED] wrote: JSBSim does basically the same (although there is a name allocated for it), but the real question is: Is left most defined 0, or is right mos define d0, or is it something completely different (numbered in order of appearance)? Erik Here is an example of our gear definition: AC_GEAR NOSE -6.8 .0 -20.0 1800 600 .5 .8 .02 STEERABLE NONE 10 FIXED AC_GEAR L_MAIN 58.2 -43.0 -17.9 5400 1600 .5 .8 .02 CASTERED LEFT 0 FIXED AC_GEAR R_MAIN 58.2 43.0 -17.9 5400 1600 .5 .8 .02 CASTERED RIGHT 0 FIXED AC_GEAR TAIL_SKID 188.0 .0 8.0 2 1000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR LEFT_TIP 43.2 -214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED See, we have contact points in addition to actual wheeled bogeys defined. The X, Y, Z coords of the contact point for each gear us there, as are the static and dynamic friction coefficients, rolling resistance, steering type, brake group membership, maximum steering angle, and retreactability. They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Perhaps there should be another identifier that relates a specific gear instance with an associated 3D model gear item? Perhaps there ought to be an ordering standard? Suggestions? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Modifying Existing FDM
Actually Jon, I haven't hacked together an electric motor. Sorry my post implied that. I was hoping someone could help me get started with that. The Config file that I've been modifying is one of a glider. ASK21, so there is no powerplant, but many of the geometrical characteristics are the same, and I just went through and changed out some of the SC Derivatives. Thanks in advance for any help sonny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Erik Hofman wrote: JSBSim does basically the same (although there is a name allocated for it), but the real question is: Is left most defined 0, or is right mos define d0, or is it something completely different (numbered in order of appearance)? Maybe I'm confused: why do we care? The 0 gear is the first one listed. If it happens to be the nose gear, then the 3D modeller will use .../gear[0]/... to animate it, etc... The only time we need to worry is when synchronizing the number across FDMs, and even then it's just a convention: make sure than gear N in the YASim configuration matches the corresponding gear in JSBSim. Notions like left, right, nose, main, etc... don't seem relevant to me. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Dienstag, 6. April 2004 19:32, Erik Hofman wrote: Jon S Berndt wrote: They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Maybe we should do the same as we did for the braking group, define a left (most), right (most) and nose gear compression and let the animation derive any values from that? No, I don't think so. It will be much harder to determine the actual compression length of any gear if we have only leftmost and rightmost compression. As Andy told in a recent mail. A modeller just has to take care that the gears in a jsbsim model are defined in the same order than in yasim. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Andy Ross wrote: Erik Hofman wrote: JSBSim does basically the same (although there is a name allocated for it), but the real question is: Is left most defined 0, or is right most defined 0, or is it something completely different (numbered in order of appearance)? Maybe I'm confused: why do we care? The 0 gear is the first one listed. If it happens to be the nose gear, then the 3D modeller will use .../gear[0]/... to animate it, etc... The only time we need to worry is when synchronizing the number across FDMs, and even then it's just a convention: make sure than gear N in the YASim configuration matches the corresponding gear in JSBSim. Notions like left, right, nose, main, etc... don't seem relevant to me. Unless you want to use the same model for different FDM's (where did we hear that again?). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Erik Hofman wrote: Jon S Berndt wrote: They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Maybe we should do the same as we did for the braking group, define a left (most), right (most) and nose gear compression and let the animation derive any values from that? Thinking about it again I think the solutions (for JSBSim) is quite simple, use the name of the entry (in lower letters) to define the gear: AC_GEAR NOSE -6.8 .0 -20.0 1800 600 .5 .8 .02 STEERABLE NONE 10 FIXED AC_GEAR L_MAIN 58.2 -43.0 -17.9 5400 1600 .5 .8 .02 CASTERED LEFT 0 FIXED AC_GEAR R_MAIN 58.2 43.0 -17.9 5400 1600 .5 .8 .02 CASTERED RIGHT 0 FIXED AC_GEAR TAIL_SKID 188.0 .0 8.0 2 1000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR LEFT_TIP 43.2 -214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED /gear/nose /gear/l_main /gear/r_main /gear/tail_skid /gear/left_top /gear/right_tip The only change might be that YASim should allow for defining named gear locations. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt wrote: They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Maybe we should do the same as we did for the braking group, define a left (most), right (most) and nose gear compression and let the animation derive any values from that? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Dienstag, 6. April 2004 19:41, Erik Hofman wrote: Thinking about it again I think the solutions (for JSBSim) is quite simple, use the name of the entry (in lower letters) to define the gear: Good idea. Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 06 Apr 2004 19:41:08 +0200 Erik Hofman [EMAIL PROTECTED] wrote: /gear/nose /gear/l_main /gear/r_main /gear/tail_skid /gear/left_top /gear/right_tip The only change might be that YASim should allow for defining named gear locations. Erik I don't know anything about how the 3D animation stuff works, but the above idea seems good to me. Andy: Regarding the LEFT|RIGHT group membership thing, there is a reason for it. There also are probably several ways to accomplish the same things - maybe even better ones, but this is the way it occurred to me to do it at the time. The problem is that if we have, say, four main gear (like on a 747) and a nose gear, how do we know which gear to apply braking commands to, since there are only two brake pedals? In JSBSim we can define bogeys in any order, so we can't really take the order to mean anything. We _could_ use some kind of AI to say that if the gear has a negative Y coordinate, then it is on the left side. But, what about (for instance) the outrigger struts on a B-52? I am guessing those have no brakes to speak of. Specifying the brake group membership was a way for us to sort of connect a bogey definition in JSBSim with the relevant brake command coming from FlightGear. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
--- Erik Hofman [EMAIL PROTECTED] wrote: Erik Hofman wrote: Jon S Berndt wrote: They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Maybe we should do the same as we did for the braking group, define a left (most), right (most) and nose gear compression and let the animation derive any values from that? Thinking about it again I think the solutions (for JSBSim) is quite simple, use the name of the entry (in lower letters) to define the gear: AC_GEAR NOSE -6.8 .0 -20.0 1800 600 .5 .8 .02 STEERABLE NONE 10 FIXED AC_GEAR L_MAIN 58.2 -43.0 -17.9 5400 1600 .5 .8 .02 CASTERED LEFT 0 FIXED AC_GEAR R_MAIN 58.2 43.0 -17.9 5400 1600 .5 .8 .02 CASTERED RIGHT 0 FIXED AC_GEAR TAIL_SKID 188.0 .0 8.0 2 1000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR LEFT_TIP 43.2 -214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED /gear/nose /gear/l_main /gear/r_main /gear/tail_skid /gear/left_top /gear/right_tip The only change might be that YASim should allow for defining named gear locations. It seems like this would break down pretty quick when faced with all the variations e.g. a glider, a 172, 747, B-52, DC-10, etc. etc. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt said: On Tue, 06 Apr 2004 18:58:03 +0200 Erik Hofman [EMAIL PROTECTED] wrote: JSBSim does basically the same (although there is a name allocated for it), but the real question is: Is left most defined 0, or is right mos define d0, or is it something completely different (numbered in order of appearance)? Erik Here is an example of our gear definition: AC_GEAR NOSE -6.8 .0 -20.0 1800 600 .5 .8 .02 STEERABLE NONE 10 FIXED AC_GEAR L_MAIN 58.2 -43.0 -17.9 5400 1600 .5 .8 .02 CASTERED LEFT 0 FIXED AC_GEAR R_MAIN 58.2 43.0 -17.9 5400 1600 .5 .8 .02 CASTERED RIGHT 0 FIXED AC_GEAR TAIL_SKID 188.0 .0 8.0 2 1000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR LEFT_TIP 43.2 -214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED AC_GEAR RIGHT_TIP 43.2 214.8 59.4 1 2000 .2 .2 .2 FIXED NONE 0 FIXED See, we have contact points in addition to actual wheeled bogeys defined. The X, Y, Z coords of the contact point for each gear us there, as are the static and dynamic friction coefficients, rolling resistance, steering type, brake group membership, maximum steering angle, and retreactability. They are not now expected to be in any particular order, nor are they given specific names. The layout is somewhat free form. A questions is, how do you set up the gear model to support animation when you may want to model things as varied as a 747, a C-172, a P-51D, a Harrier, etc.? Perhaps there should be another identifier that relates a specific gear instance with an associated 3D model gear item? Perhaps there ought to be an ordering standard? Suggestions? That looks easy enough. If there aren't any indications otherwise, the order they are listed in the config file would be fine. Maybe adding the text description in the gear/gear[n] path (the NOSE, L_MAIN, R_MAIN, etc) might help someone trying to figure out which was which. But of course they could just look at the config file and count (e.g. R_MAIN must be gear[2]). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 6 Apr 2004 18:05:30 - Jim Wilson [EMAIL PROTECTED] wrote: Maybe adding the text description in the gear/gear[n] path (the NOSE, L_MAIN, R_MAIN, etc) might help someone trying to figure out which was which. But of course they could just look at the config file and count (e.g. R_MAIN must be gear[2]). I like Erik's suggestion - but then my assumption is that the 3D modeler will know to look at the FDM and see how the gear is named. A big remaining issue there, however, is that this would require all FDMs to name the gear the same way if there were multiple flight models for a given 3D model. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Norman Vine wrote: since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option Uh, that's the whole point. What would you prefer, if not SDL? If you want to write a windows-only implementation, feel free. The problems with glut are well-documented. It is no longer developed, doesn't track changes in the underlying systems (mode switching has never worked under XFree86, for example), is not free software, is being dropped by most linux distributions, and is filled with cruft that we don't use. Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Tony Peden wrote: --- Erik Hofman wrote: /gear/nose /gear/l_main /gear/r_main /gear/tail_skid /gear/left_top /gear/right_tip It seems like this would break down pretty quick when faced with all the variations e.g. a glider, a 172, 747, B-52, DC-10, etc. etc. Maybe to clear it up a bit, this is not a convention. The designer can name them whatever (s)he wants, (s)he just has to make sure a name isn't used more than once. This way it is easy to change the YASim or the JSBSim or the animation configuration file to match each other. Fixed (non compatible numbers) don't allow for that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Modifying Existing FDM
In the prop file "prop_75in2f.xml" what is the input column for the Look up tables of C_THRUST, and C_POWER. The first column that is thanks ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. One big issue is that out of the box, glut is either broken, or non-existant now on many linux distributions. It just became broke for debian users that run nvidia drivers. (Along with all the other issues Andy mentioned.) This isn't so much an issue of functionality right now, but more of an issue of supporting what people are already likely to have installed on their machines (or can easily get installed on their machines.) As is well documented, the glut licensing makes it almost impossible to fix it's known issues, free glut has show stopping limitations or doesn't support all platforms we want to support. Perhaps we could say that what is better is that FlightGear might build more easily, or more cleanly, or with fewer issues on more people's boxes if we go with SDL (or at least allow a choice which is the current direction we are heading.) I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt wrote: On Tue, 6 Apr 2004 18:05:30 - Jim Wilson [EMAIL PROTECTED] wrote: Maybe adding the text description in the gear/gear[n] path (the NOSE, L_MAIN, R_MAIN, etc) might help someone trying to figure out which was which. But of course they could just look at the config file and count (e.g. R_MAIN must be gear[2]). I like Erik's suggestion - but then my assumption is that the 3D modeler will know to look at the FDM and see how the gear is named. A big remaining issue there, however, is that this would require all FDMs to name the gear the same way if there were multiple flight models for a given 3D model. Yes, but at least it is possible to change either of them to match, it looks like this can't be done right now. Another advantage is that the names actually mean something to the 3d modeler, gear[1] doesn't (at least to not to me). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Erik Hofman wrote: This way it is easy to change the YASim or the JSBSim or the animation configuration file to match each other. Fixed (non compatible numbers) don't allow for that. I'm not arguing against having names for the gear, which actually sounds kind of elegant. But it should be pointed out that the numbers aren't fixed: YASim numbers the gear in the order they appear in the configuration file. There's no reason you couldn't move them around to match a JSBSim configuration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 14:42:48 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: In the prop file prop_75in2f.xml what is the input column for the Look up tables of C_THRUST, and C_POWER. The first column that is thanks This is a 75 inch diameter, 2 bladed, fixed-pitch propeller. The first column is the advance ratio, J: J = Vel / (Diameter * RPS); Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Andy Ross wrote: Erik Hofman wrote: This way it is easy to change the YASim or the JSBSim or the animation configuration file to match each other. Fixed (non compatible numbers) don't allow for that. I'm not arguing against having names for the gear, which actually sounds kind of elegant. But it should be pointed out that the numbers aren't fixed: YASim numbers the gear in the order they appear in the configuration file. There's no reason you couldn't move them around to match a JSBSim configuration. Ah, ok. I didn't know that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Off the top of my head: + Build out of the box on Fedora, which no longer ships glut. Other linux distributions are likely to drop it in the future as well, I suspect. It has portability issues when built against current versions of the X libraries and has a license which disallows redistribution of modified versions. + Switch video modes on an XFree86/Xorg server, which has supported this capability for 4+ years but have never had a complete game mode glut port written. + Be able to handle stuff like Shift-3 instead of #, so the Europeans don't think our key mappings are on drugs. + Future features we might like to investigate: SDL has a portable threading API, so we could enable threads by default. SDL has an audio library which is more featureful and portable than SL (it speaks to APIs like ALSA, arts, ESD, and DirectSound; SL doesn't even work on my laptop) Seriously, glut has not been maintained for almost 6 (!) years. Almost no one else uses it. It was a nice demo library in its time, but it has long since faded. Everybody doing portable open source OpenGL development is using SDL. I don't like everything about the library, but I can feel where the wind is blowing. And I'm serious: if you want to write a Win32 implementation of the stuff in fg_os.hxx, feel free. The whole point of having an abstraction API under our own control is that it allows us to do things our way. I'm not wedded to SDL, by any means. Honestly, I thought you of all people would enjoy this change. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Under Linux, resolution switching (i.e. go fullscreen at 1024x768 when your desktop is 1600x1200, and so on). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jon S Berndt said: On Tue, 6 Apr 2004 18:05:30 - Jim Wilson [EMAIL PROTECTED] wrote: Maybe adding the text description in the gear/gear[n] path (the NOSE, L_MAIN, R_MAIN, etc) might help someone trying to figure out which was which. But of course they could just look at the config file and count (e.g. R_MAIN must be gear[2]). I like Erik's suggestion - but then my assumption is that the 3D modeler will know to look at the FDM and see how the gear is named. A big remaining issue there, however, is that this would require all FDMs to name the gear the same way if there were multiple flight models for a given 3D model. Keep it simple: gear[0], gear[1], gear[2] ...same order as listed in the FDM config. The aircraft configs for different fdm's will have to match each other's order if they want to share a 3Dmodel, but making up unique names, fixing typos, etc won't be an issue. You can optionally put names inside each gear[n] path but that would just be for documentation purposes. Try naming these: http://thomas.grand.free.fr/kz/00air.jpg Lee did it, by numbering them! (with an L or R designation for each side) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jim Wilson wrote: Keep it simple: gear[0], gear[1], gear[2] ...same order as listed in the FDM config. Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to remember the order in which I put them in the file ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Raised Runways
On Tuesday 06 Apr 2004 3:22 am, Lee Elliott wrote: snip * Curtis L. Olson -- Monday 05 April 2004 04:55: Could you send me an example or two or three of airports that are especially glaringly wrong? I hope to dig into this problem in the upcoming week to see if I can get to the bottom of it. snip It's certainly curious. Using EGLL (London Heathrow) and EGSS (London Stanstead) as examples - EGLL is fine but EGSS is about -100ft agl, yet the two are only about 30 miles apart and on similar terrain. Assuming, because of the geographical closeness, that the relative terrain and airport data come from the same sets, it implies an error in one set of data. People have checked out various airport data and confirmed that they seem ok, so it looks like the terrain data is less than consistant I built 3 arcsec terrain for the UK [1] over the last couple of days using SRTM data from ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/Eurasia/ and the runways in the current cvs version of runways.dat.gz I've just checked, and both EGLL and EGSS mesh perfectly with the landsape. This may or may not be illuminating! Jonathan [1] This is still work in progress. I'll share it around when it's ready. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Curtis L. Olson wrote: I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... Ah. I honestly didn't know this. I just assumed that cygwin was one of their native platforms. I just checked, and it's true that cygwin doesn't ship an SDL library as part of the distribution. I did find the following README on the SDL website which seems to imply that the process is pretty straightforward: http://www.libsdl.org/extras/win32/cygwin/README.txt It basically sounds like configure make make install is all that is needed, with a few caveats about making sure to install extras packages containing OpenGL and DirectX headers. But remember: I think a native Win32 implementation would be pretty cool, too. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Erik Hofman said: Jim Wilson wrote: Keep it simple: gear[0], gear[1], gear[2] ...same order as listed in the FDM config. Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to remember the order in which I put them in the file ... Yep. It just depends on how your brain is organized I think :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Andy Ross wrote: Ah. I honestly didn't know this. I just assumed that cygwin was one of their native platforms. I just checked, and it's true that cygwin doesn't ship an SDL library as part of the distribution. I did find the following README on the SDL website which seems to imply that the process is pretty straightforward: http://www.libsdl.org/extras/win32/cygwin/README.txt It basically sounds like configure make make install is all that is needed, with a few caveats about making sure to install extras packages containing OpenGL and DirectX headers. But remember: I think a native Win32 implementation would be pretty cool, too. :) Norman, please jump in if I get any of the details wrong here. Andy, as I understand it, the SDL Readme is slightly optimistic. The configure/make/make install process either breaks, or doesn't produce a usable result under Cygwin. The SDL people argue that it works for MSVC and MingWin so apparently no one is motivated to figure out why things don't work for Cygwin. That's my recollection of what Norman reported to me some months ago. Obviously the solution is to fix SDL under Cygwin, but I don't know who would do that. Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? If we can get SDL working well for all but cygwin people, it might make sense to make SDL be the default rather than glut, or default to SDL if it is detected and fall back to glut if there is no SDL? Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Dienstag, 6. April 2004 21:16, Jim Wilson wrote: Yep. It just depends on how your brain is organized I think :-) Using names you can also name it gear0, gear1 ... But using numbers you are fixed to remembering how you configured ... Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tue, 6 Apr 2004 19:16:18 - Jim Wilson [EMAIL PROTECTED] wrote: Erik Hofman said: Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to rememberthe order in which I put them in the file ... Yep. It just depends on how your brain is organized I think :-) Or, if ... B^P Personally, I like the naming scheme better. What ought we do, I ask? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Modifying Existing FDM
So if I know the range of velocity in which our plane will be flying, and the specs on the electric motor (600 speed motor), along with the Diameter of the single blade prop (11"), than I could calculate the advance ratio along eachvarying flight conditon. Is that Correct? The next thing would be to somehow correlate this to the actual output from the motor (Column 2) sonny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Tuesday 06 April 2004 20:16, Norman Vine wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Using SDL has many positive effects. 1. It is widely accepted, easy to use and even commerical companys do use it for their commercial games. This means also that there is a large user base that can jump in and improve flightgear. 2. (my favourite one) A very nice input and event handling system. It uses a virtual keysym to each key on the keyboard which map to some level to the operating systems's keyboard scancodes. So it is very easy to nicely support non US keyboard layouts plattform independet. You can also use the same input infrastructure to support joystick, mouse and other input devices the same easy way. 3. It can be easily used together with OpenAL as our default sound API and SDL sound as a backup system in the case OpenAL is not supported on other plattforms. IMHO OpenAL is a must, because it is crossplattform capable and allowes us to easily implement 3d sound in flightgear, doppler shift effects, attenuation and hardware sound accerlation (if the soundcard supports it). It is also very easy to use because it is rather similar to the way OpenGL works and is used. 4. SDL has its own portable threading API which is plattform independent. That feature could be very usefull. And much more. I think GLUT is dead, we should realize that and SDL seems to be the best solution today to replace GLUT. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Consistent gear modeling for animation compatibility
On Tue, 06 Apr 2004 20:58:24 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to remember the order in which I put them in the file ... Erik So ... to get some closure on this issue, do we give the FGLGear class some bindings based on the gear name? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Modifying Existing FDM
thanks for the tips. So you're suggesting that I leave the J (advance ratio), and coefficients alone, and just modify the Ixx and Diameter parameters accordingly? DONE! Well, this kind of leads me back to the original problem. My plane is supposed to be flying to a set of waypoints, lat, long, and altitude, and along this flight, should be tracking a.)velocity and b)altitude. It fly's to the specified lat, and long, but there is no response from the aircraft when the actual alt. drops below the setpoint altitude. I can see the thrust increase, and with this increase I expect an increase in lift, but I continues to ever so slowly loose altitude.It never shows an increase, and hence never tracks the setpoint. Now, this could be afunction of my SC derivatives, so maybe I'll go and revisit them. Earlier, you mentioned controlling theOUTPUT portion of the FDM.Why is it that the aircraft reacts differently when different options are enabled? With the right subset enabled, it fly's pretty well, but without, it's a disaster thanks ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Curtis L. Olson wrote: Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) If we can get SDL working well for all but cygwin people, it might make sense to make SDL be the default rather than glut, or default to SDL if it is detected and fall back to glut if there is no SDL? Another option might be for someone to fight through the SDL installation just once and provide a binary package for cygwin folks to install. Dumb question for windows folks: would it not work to simply use the mingw library? My understanding is that windows SDL is built entirely on the Win32 API, and won't conflict with cygwin.dll or the C library. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Andy Ross wrote: Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) Be a man and dive in. I still don't understand automake either, but after a lot of trial and error, I managed to make a few configuration changes work. After all, we all managed to learn Perl, didn't we? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 16:47:42 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: thanks for the tips. So you're suggesting that I leave the J (advance ratio), and coefficients alone, and just modify the Ixx and Diameter parameters accordingly? DONE! Well, this kind of leads me back to the original problem. My plane is supposed to be flying to a set of waypoints, lat, long, and altitude, and along this flight, should be tracking a.)velocity and b)altitude. It fly's to the specified lat, and long, but there is no response from the aircraft when the actual alt. drops below the setpoint altitude. I can see the thrust increase, and with this increase I expect an increase in lift, but I continues to ever so slowly loose altitude. It never shows an increase, and hence never tracks the setpoint. Now, this could be a function of my SC derivatives, so maybe I'll go and revisit them. First, let me get clear on what you are using. You are using a JSBSim flight model, within FlightGear, using the FlightGear autopilot? Earlier, you mentioned controlling the OUTPUT portion of the FDM. Why is it that the aircraft reacts differently when different options are enabled? With the right subset enabled, it fly's pretty well, but without, it's a disaster The OUTPUT/OUTPUT section **only** affects how data is logged for post-processing and it has **no** effect on the flight characteristics. I thought you might want to make some plots to see what was happening. Can you send me your aircraft config file so I can see if it is defined properly? Another thing: you can control how JSBSim outputs some debugging messages that are displayed during aircraft loading. This might be helpful. Try setting the environment variable JSBSIM_DEBUG to 1, or 3, or 7, then run again. This ought to echo in what the program thinks it is reading in from your input file. That might help eliminate any parsing errors. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CG Location
I thought I read somewhere, that in Flight Gear, the CG of your aircraft isn't specific to the aircraft itself, but rather related to some sort of reference. Is this true? Or did I misinterpret something? It also mentioned that you could put the coordinates of (0,0,0) for CG location. sonny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Modifying Existing FDM
Some good thoughts again. Actually, I'm using a JSBSim flight model, within flightgear, but interfacing it to my own autopilot inside of Simulink. I might however switch over to the Flight Gear Autopilot, and see what kind of handling I get. Which address should I send the file to? sonny ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying Existing FDM
On Tue, 6 Apr 2004 17:16:01 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: Some good thoughts again. Actually, I'm using a JSBSim flight model, within flightgear, but interfacing it to my own autopilot inside of Simulink. I might however switch over to the Flight Gear Autopilot, and see what kind of handling I get. Which address should I send the file to? sonny jsbathal-pc.org Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CG Location
On Tue, 6 Apr 2004 16:59:55 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: I thought I read somewhere, that in Flight Gear, the CG of your aircraft isn't specific to the aircraft itself, but rather related to some sort of reference. Is this true? Or did I misinterpret something? It also mentioned that you could put the coordinates of (0,0,0) for CG location. sonny For a JSBSim flight model, there are a few reference frames of interest. I just published a newsletter for JSBSim that describes within it some of the various coordinate frames. Go to www.jsbsim.org, and click on the newsletter announcement at the top of the main page. All points that are specified in the config file are referenced to a coordinate frame that has the X axis increasing aft, the Y axis increasing right, and the Z axis increasing up. The origin technically could be anywhere, but is usually at or near the nose of the aircraft - although, technically, it *could* be placed coincident with the CG - even though the CG moves during flight. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
On Tuesday 06 April 2004 20:25, Jon S Berndt wrote: On Tue, 6 Apr 2004 19:16:18 - Jim Wilson [EMAIL PROTECTED] wrote: Erik Hofman said: Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to rememberthe order in which I put them in the file ... Yep. It just depends on how your brain is organized I think :-) Or, if ... B^P Personally, I like the naming scheme better. What ought we do, I ask? Jon How would naming the gear units work with something like the AN-225? It has two nose units and seven mains each side. Each of the sixteen units needs to be animated independently. Also, I believe Nasal has the capability to run through an indexed series - would this still be possible with names? I don't know if these could be problems or not but I thought I'd better mention it. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Raised Runways
On Tue, 6 Apr 2004, Jonathan Richards wrote: I built 3 arcsec terrain for the UK [1] over the last couple of days using SRTM data from ftp://edcsgs9.cr.usgs.gov/pub/data/srtm/Eurasia/ and the runways in the current cvs version of runways.dat.gz I've just checked, and both EGLL and EGSS mesh perfectly with the landsape. I'd be interested in the settings you've used at each stage of the build. Have a look at EGNM (Leeds Bradford) and EGPH (Edinburgh). Leeds was in a trench, while the Edinburgh runways were on an embankment. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Curtis L. Olson writes: I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... I haven't heard of any one not being able to compile CVS FGFS because of GLUT but this is not the point I am trying to make which is since we are now agnostic as pertains to the lowlevel OpenGL initialization routines I don't see why the choice of OpenGL toolkit used couldn't just be an option This is easy todo as long as we only use those routines that are GFX agnostic i.e those defined in fg_os.hxx and pure OpenGL This way it is up to the user compiling the code which underlaying library is used Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Norman wrote: Out of curiosity what can't you do today that would make FlightGear better because we are using GLUT that you would do differently today if we were using SDL and what exactly is it that would make FGFS better. Off the top of my head: + Build out of the box on Fedora, which no longer ships glut. I wonder who sparked that :-) + Switch video modes on an XFree86/Xorg server, which has supported this capability for 4+ years but have never had a complete game mode glut port written. + Be able to handle stuff like Shift-3 instead of #, so the Europeans don't think our key mappings are on drugs. why not use freeglut ? FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Andy Ross writes: Curtis L. Olson wrote: I understand that there are (or at least were) issues between SDL and cygwin, but perhaps it would be more productive to address that problem directly ... Ah. I honestly didn't know this. short memory :-) http://baron.flightgear.org/pipermail/flightgear-devel/2003-April/017006.html But remember: I think a native Win32 implementation would be pretty cool, too. :) If we only use pure OpenGL calls outside of the fg_os functions liike I suggest this would still be possible Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads The argument is still open. Sell us on OpenProducer. I've never heard of it, but would be willing to investigate. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Tue, 06 Apr 2004 13:52:28 -0700 Andy Ross [EMAIL PROTECTED] wrote: Curtis L. Olson wrote: Probably the best short term solution is to make sure we can build with both SDL and glut and let the builder decide? Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) For starters we could change the glut test in configure.ac to something like: --- dnl Check for SDL if enabled. AC_ARG_ENABLE(sdl, [ --enable-sdlConfigure to use SDL instead of GLUT], enable_sdl=yes, enable_sdl=) if test x$enable_sdl = xyes ; then sdl_version=1.2.0 AM_PATH_SDL($sdl_version, use_sdl=yes, use_sdl=) CPPFLAGS=$CPPFLAGS $SDL_CFLAGS LIBS=$LIBS $SDL_LIBS else dnl check for glut location AC_CHECK_HEADER(GL/glut.h) if test x$ac_cv_header_GL_glut_h = xyes; then AC_DEFINE([FG_GLUT_H], GL/glut.h, [Define as glut.h include location]) else AC_CHECK_HEADER(GLUT/glut.h) if test x$ac_cv_header_GLUT_glut_h = xyes; then AC_DEFINE([FG_GLUT_H], GLUT/glut.h, [Define as glut.h include location])else echo Neither GL/glut.h nor GLUT/glut.h found. Cannot continue exit fi fi fi --- Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent gear modeling for animation compatibility
Jon S Berndt said: On Tue, 06 Apr 2004 20:58:24 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Your idea of simple is different then mine. Most of the time I know the names I've given objects for 3d animations, I never seem to remember the order in which I put them in the file ... Erik So ... to get some closure on this issue, do we give the FGLGear class some bindings based on the gear name? I'm fine with Erik's idea, but I would like to get David M's take on it first because he is the xml / property system guru and AFAIK this diverges from anything we've done before. Rather than having variable attribute names, it might actually be more consistant to have a gear[n]/name string attribute. All we need is a way to specify references to that in animation xml (or could nasal do it?). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] vector.push_back() and the d'tor
I'm not positive, but it seems (roughly) like a vector push_back() operation causes the d'tor to be called after the first element is stored. To me, this seems to say that the push_back() operation copies the existing stored element[s] to a new location (resizing the container) and destroys the old copy of the object stored in the vector. I'm looking into this in Stroustrup, but if anyone has any insights to share on this I'd be interested to hear them. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Raised runways
Curt wrote: Could you send me an example or two or three of airports that are especially glaringly wrong? I hope to dig into this problem in the upcoming week to see if I can get to the bottom of it. There are a number of airports on the front range in Colorado with similar raised or sunken runways. KBJC (Jeffco) and 2V2 (Vance Brand, where I fly from for real) are examples. But several airports near these are fine: KFNL and KGXY for example. Also, I mentioned in another note that just West of KDSM (Des Moines, IA), or West of KIKV (Ankeny Regional in Des Moines), there is a fairly large drop off or shear in the scenery. This area for real is very flat. Hope these examples help. Dave Perry ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] vector.push_back() and the d'tor
I'm not positive, but it seems (roughly) like a vector push_back() operation causes the d'tor to be called after the first element is stored. To me, this seems to say that the push_back() operation copies the existing stored element[s] to a new location (resizing the container) and destroys the old copy of the object stored in the vector. I'm looking into this in Stroustrup, but if anyone has any insights to share on this I'd be interested to hear them. Jon Looks like indeed that is the case, though where possible reserve() may help me out. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CG Location
On Tue, 2004-04-06 at 14:21, Jon S Berndt wrote: On Tue, 6 Apr 2004 16:59:55 -0400 Sonny Hammaker [EMAIL PROTECTED] wrote: I thought I read somewhere, that in Flight Gear, the CG of your aircraft isn't specific to the aircraft itself, but rather related to some sort of reference. Is this true? Or did I misinterpret something? It also mentioned that you could put the coordinates of (0,0,0) for CG location. sonny For a JSBSim flight model, there are a few reference frames of interest. I just published a newsletter for JSBSim that describes within it some of the various coordinate frames. Go to www.jsbsim.org, and click on the newsletter announcement at the top of the main page. All points that are specified in the config file are referenced to a coordinate frame that has the X axis increasing aft, the Y axis increasing right, and the Z axis increasing up. The origin technically could be anywhere, but is usually at or near the nose of the aircraft - although, technically, it *could* be placed coincident with the CG - even though the CG moves during flight. or put another way, it could be put at one location of the cg, the origin of the structural frame does not move with the cg. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Raised runways
Dave Perry wrote: There are a number of airports on the front range in Colorado with similar raised or sunken runways. KBJC (Jeffco) and 2V2 (Vance Brand, where I fly from for real) are examples. But several airports near these are fine: KFNL and KGXY for example. Today (I *think*) I tracked down the problem with odd airport elevations and surfaces, although I need to do more extensive testing. I also believe I've fixed the problem with grassy runway center sections. Also, I mentioned in another note that just West of KDSM (Des Moines, IA), or West of KIKV (Ankeny Regional in Des Moines), there is a fairly large drop off or shear in the scenery. This area for real is very flat. I noticed that ... it definitely seems wrong ... I wonder if it's an artifact of the SRTM terrain data? We should probably look at that chunk of data in a separate viewer to verify if it's processing bug, or a problem with the source data. This probably warrants an Iowa joke (being from a neighboring state) but I can't think of anything tasteful. :-) Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What on earth ...
The North American Aviation division of Rockwell International was aquired by Boeing in the mid 90's, and Douglas, part of McDonald Douglas, became part of Boeing when the merger of Boeing and McDonald Douglas occured. Lee Elliott wrote: On Wednesday 31 March 2004 19:16, Jon S Berndt wrote: http://www.boeing.com/news/frontiers/archive/2002/may/ts_pw.html I wonder what sort of aerofoil is used on the rotor... I was surprised to read of Boeing's involvement with the X-3, X-10 X-15 - both the X-10 X-15 were North American Aviation and the X-3 was Douglas. Perhaps Boeing were referring to the launch ship (NB-52A), although I wasn't aware that the X-3 had done any air-launches. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Bruce Finney [EMAIL PROTECTED] Auburn, WA ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Raised runways
Curtis L. Olson wrote: Today (I *think*) [...] Yeah. Daylight savings time always confuses me too. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
