Re: [Flightgear-devel] control surface normalization
Hi, I agree with Norman. As long as control system is of concern, it is much better to use normalized units. surface deflections in degrees, and for good reason: it's natural, it's physical. From the point of view of JSBSim, normalized aerosurface Degrees are not natural, nor physical. We may argude that *radians* might be natural, but *not* degrees. This would lead us to another class of problems, what system of measurements is used? (I'm used to SI system) or what about input (I mean stick, pedals positions...)? Should the input be expressed in natural or normalized units? And about FDM itself, aerodata to be used are not unified... I have seen some using degrees as a control surface deflections units, and others using radians. What would you choose as a natural? I think normalized deflections *are* the best solution. just my 2$ :) cheers, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Curtis L. Olson wrote: I think we are limiting the discussion here to only flying control surface positions, i.e. - left aileron deflection - right aileron deflection - elevator deflection - rudder deflection - nose/tail wheel deflection. I wouldn't like this one to end up in degrees. Not because it isn't possible, but because it is very hard to match the 3d model with the real number. You will always need to cheat with the deflection angles to get it properly inside the fuselage. - various flap deflections - various spoiler deflections. However, what about slats which often deploy linearly rather than via a rotation. What about speed brakes that deploy linearly rather than via rotation. Even flaps themselves can be a complex combination of pieces that move together and don't necessarily have one particular angle you can assign to them. Yep, getting slotted flaps to animate properly using animations is quite a bit harder using degrees. Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. Please, not for the wheels. Really. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ..can FG be run on graphics card rather than the CPU?
Hi ..another way to run code: http://gpgpu.org/ , for a wee quick intro, chk out: http://www.ece.ucdavis.edu/~jowens/talks/owens-hpec04-gpgpu.pdf ..note how they waaail for killer apps. ;-) ..formation flight: http://wwwx.cs.unc.edu/~tgamblin/gpgp/ ;-) ...more gory details: http://gamma.cs.unc.edu/GPGP/ http://www.daimi.au.dk/~mosegard/GPGPU_E04 ..and, ahem, an app: http://flightgear.org/ ;-) ..so, if I cheat, by stuffing in 5 pci nVidea math cards beside my new 1xAGP 9250, my trusty 5 yr old AMD K6-2 450MHz can run in circles around anything on the market for another 5 years? ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
David Luff wrote: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095.html It requires openGL-1.2 for the patch to take effect, which I don't have on Cygwin. If your SGI is openGL-1.2 capable, then perhaps you could see if it makes any difference on your system? I'll have a look tonight, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Arnt Karlsen wrote: ..FG-lawfully. ;-) Gamers obviously wanna buzz the White House in an X-15 or in 747 formations, or touch-and-go the Space Shuttle on any nice wee town's drag strip. We have the Shuttle launching? Set it up as a submodel on top of the 747? :-) How about dropping the X-15 from a B52 -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Next release planning ...
* Erik Hofman -- Thursday 16 December 2004 14:26: Melchior FRANZ wrote: z-offset-m alias=/sim[0]/chase-distance-m[0]/ In the archives I noticed you had a patch for this. No. I said it's fixed and I'd send you the patch after some more testing. The bug is in the load function, but While working on this I noticed that there's also a writing bug. Hold on until tomorrow. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Thu, 16 Dec 2004 14:28:12 +, Jon wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..FG-lawfully. ;-) Gamers obviously wanna buzz the White House in an X-15 or in 747 formations, or touch-and-go the Space Shuttle on any nice wee town's drag strip. We have the Shuttle launching? Set it up as a submodel on top of the 747? :-) ..too easy, I wanna buzz town with all 5 rockets going nuts! ;-) ..the shuttle that broke up, could have aborted the launch had they learned about the wing hole in time, and that would left them with enough fuel to buzz a lot of the lower 48. ;-) How about dropping the X-15 from a B52 ..we have all the bits to do it, no? :-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Erik Hofman wrote: Personally, I would be in favor of using angles to describe the positions of left/right aileron, elevator, rudder and nose/tail wheel. Please, not for the wheels. Really. It doesn't probably matter too much for 3d animation if your conversion factor get's you close. However, the FAA tests actually do care about nose wheel deflection angle, so that's a good thing to get out of the FDM in degrees, not normalized values. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Thursday 16 December 2004 10:38, Thomas Förster wrote: Am Mittwoch 15 Dezember 2004 14:48 schrieb Oliver C.: On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? For integration with existing desktops it's possibly best to use their native libs. QT for example provides an OpenGL widget, so all of the gui (menu, dialogs) could be native QT Widgets. Also if the sim runs in the context of a GUI it will be easy to switch between them at startup, i.e. 'fgfs --gui-gnome' runs a GTK based GUI, whereas 'fgfs --gui-qt' runs a qt based one. Don't know about possible performance issues, though. :-( Using native none OpenGL GUI APIs for a in game menu ist not a good idea, this might be acceptable for a remote display menu but not for a in game menu. The reason is, that openGL GUIs allow to display the menu in game in front of the 3d scenery that's not possible with none openGL Guis because you need to switch from OpenGL to a 2d mode to display them. This is mainly a comfort, performance and usability issue. The other reason is, QT is not free on MS windows systems (only the X-Window version is under GPL) and GTK does offer OpenGL support only with an addional GTK OpenGL library which depends on 3 other gtk related librarys for OpenGL support, the next problem is that the OpenGL Window runs on top of the GTK window and not the other way. Using QT and win32 for each plattform makes no sense, we need a GUI API that is crossplattform compatible and runs directly in a OpenGL window. Gigi the library Dave proposed could do that job. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Thursday 16 December 2004 05:13, Ampere K. Hardraade wrote: A user may be able to access a lot of planes due to his/her experience points, but it will be necessary to pass the tests before he/she can truly unlock these planes. Similarly, a user may unlocked a lot of scenarios, but enough experience points must be gained so that the required aircrafts in some of the scenarios can be unlocked. Personaly i don't like it when features (especially things like airports or areas) are looked and require to do some other things first. But it would be ok to lock only the learn to fly lessons, so that everyone needs to fly each lessons in the correct order first. As for the Scenario Flight option, I think it will be better to include it within the Learn to Fly experience or the Quick Flight option, and leave the space for an option to the multiplayer menu in the future. I think there is enough space to put the multiplayer option below or above the Sceneraio Flight options. Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi, Control law block diagrams I have seen take stick input in pounds force (pilot inputs) and output in degrees to actuators. I've never seen one that output control commands to an aerosurface actuator in a range from 0 to 1. Have you? I have seen (and I've seen more than few) control law diagrams taking some generalized input (0-1 range), taking target speed, or attitude, or something,... but havent seen any, taking as a input force that pilot has to produce. Could you pls give some pointers? I'd like to take a look; it's never to late to learn something new :) As far as the force in the stick is of concern, I've seen exactly oposite situation: one has position of the stick, speed of the stick, dynamic properties of the linkage, and all data from FDM. Using those as input, force to be produced on the stick is calculated, and generated. By natural I mean that it's: the most commonly seen angular command unit for aerosurfaces, that it's what is used by the rendering routines to rotate 3D objects, that it completely specifies the commanded angular position without the need for a range (a range of 0 to 1 by itself specifies nothing without the definition of what the maximum is - there is no standard here for that), and much aero data is non-dimensionalised using degrees (or radians, see below). So, sorry, but based on the above description, for this application, yes, degrees are natural. Ok, I see your point as: natural -- most common. But IMO, degrees are wrong choice; in that case I would use radians. After all, isn't the standard that RAD-ians are used deep in CPU math unit, meaning the need for yet another conversion? best regards, Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thu, 16 Dec 2004 11:15:52 -0800 Richard Harke [EMAIL PROTECTED] wrote: A rotation whether in degrees or radians only makes sense if the axis of rotation is specified. This would have to be on a per aircraft basis. Also I'm sure that many if not most control surfaces do not simply rotate about a single axis but involve sliding motion and rotation of multiple parts and often, rotation while sliding. No, this is only really relevant for the 3D model. But even complicated multi-segment flaps are indexed by degrees with respect to aero coefficients. Further, the flight control system still outputs degrees - not normalized units. Once you get to a certain level of detail of course the signal to an actuator might be in volts. How do you normalize that? For any normalized aerosurface command, you still need two pieces of data to make an absolute: the normalized value and the travel range. Plus, as I've mentioned before, if you output in degrees (or radians) you are outputting an absolute, which is also eeffectively what is require for the rendering system directly. When I did IRIX GL programming ten years ago the API call used degrees to rotate. Converting to a normalized value, then back again is a waste. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On 12/16/04 at 12:16 PM Curtis L. Olson wrote: David Luff wrote: I've commited a work-around to the base that wraps all the symetrical runway panels in the v direction (everything except the threshold panel has identical upper and lower borders, and so can safetly be wrapped in v given that we're only wrapping a handfull of pixels). This removes the vast majority of the lines (all except at the threshold, and the longitudional line where rwy numbers are made of 2 digits). You can still test Andy's plib patch by using the 2D c172 (--aircraft=c172p-2dpanel) which will almost certainly exhibit panel jointing problems if you've been seeing runway lines. Dave, Based on all my knowledge of OpenGL, this is the wrong thing to do and will introduce additional (although possibly less visible) artifacts at the edges. The visual results should be examined *very* carefully. I don't think this is what we want to do. Hi Curt, I had a feeling I'd cop some flak for this ;-) I'm quite prepared to be proved wrong and to revert it if need be. Lets look at the benefits first though and give it a couple of days to see if there really are some downsides. Here's some screenshots to look at - 2 before the change, and 2 after. KDPA screenshots from my Cygwin build, KSFO from the official binary, both with an ATI Radeon 7200 32Meg card. http://www.nottingham.ac.uk/~eazdluf/KSFO-default.jpg http://www.nottingham.ac.uk/~eazdluf/KSFO-new.jpg http://www.nottingham.ac.uk/~eazdluf/KDPA-default.jpg http://www.nottingham.ac.uk/~eazdluf/KDPA-new.jpg Without any change thousand of users who download the official binary and use (an unknown but significant subset of) non-NVidia cards are going to be seeing those lines in the runway. They don't look good :-( Explanation of the ATI vs. NVidia differences is given by Andy Ross, a full two years ago: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095.h tml http://sourceforge.net/mailarchive/forum.php?forum_id=4479max_rows=25style =nestedviewmonth=200212 His patch never got included in Plib though (looking at the current source), and even if it did I don't have the knowhow to get OpenGL-1.2 stuff working under Windows. I can think of 3 possible avenues for fixing this: 1 - Look at the airport generator. Perhaps we've got tiny over or underruns on the tex co-ords. Maybe lining them up perfectly or even with slight overlap would fix it. Disadvantage - need to regenerate scenery to see benefits - not practical for this release. 2 - Fred compiles Plib with Andy's patch and gets the official binary to use GL_CLAMP_TO_EDGE if available. Apparently most modern cards should handle this. Disadvantage - AFAICT using 1.2 extensions on Windows is possibly somewhat non-trivial - win32api supplies openGL 1.1 by default if I'm not mistaken. 3 - My, erm, hack. I can't theoretically see where it's going to cause artifacts. AFAICT, I'm just wrapping in one direction where the bottom and top pixels of the texture are practically the same anyway. That's why I can't do the threshold piece. I'm quite prepared to be proved wrong though - I thought I'd better do this with enough time before the release to back it out if need be ;-) We could almost certainly wrap all the full width pieces in u and v if it's the 1D wrapping you're concerned about, since the left and right are identical, as long as we don't overrun the small runway shoulder. Can't do the 9r, 7l etc bits in that direction though. I guess I'd better go and see what it looks like on an NVidea card now... Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thu, 16 Dec 2004 18:21:24 +0100 Gordan Sikic [EMAIL PROTECTED] wrote: I have seen (and I've seen more than few) control law diagrams taking some generalized input (0-1 range), taking target speed, or attitude, or something,... but havent seen any, taking as a input force that pilot has to produce. Could you pls give some pointers? I'd like to take a look; it's never to late to learn something new :) As far as the force in the stick is of concern, I've seen exactly oposite situation: one has position of the stick, speed of the stick, dynamic properties of the linkage, and all data from FDM. Using those as input, force to be produced on the stick is calculated, and generated. Look here at the X-15 data and FCS diagram: http://jsbsim.sourceforge.net/X-15Aero.html The USAF F-16 (Block 40) FCS diagram is the same way: stick force is the input. Same with Space Shuttle control Law diagrams. The JSBSim X-15 model simulates the X-15 control laws as shown in the link above. We take the -1 to +1 joystick input from FlightGear and turn it into a stick force, mapping to the force range described in Etkin's book as a sort of standard. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [OT] Spectacular ground transport
Tonight an old KLM-747 will be shipped through the canals of Amsterdam on it's way from Schiphol Airport (EHAM) to the new Aviodrome (http://www.aviodrome.nl) museum at Lelystad airport (EHLE). I found some pictures at: http://www.ruudleeuw.com/phbuk-15dec04.htm The transport will pass near where I live in a few hours, so I'm tying to see if I can catch a glimpse. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thu, 16 Dec 2004 20:47:03 - Jim Wilson [EMAIL PROTECTED] wrote: Jon's concern is quite valid, but there are problems. As I work through these concepts in my mind, I can see that although the current method sounds more complicated for the 3D animator, having to deal with the real values could be a lot worse (at least with the current architecture). For simple aerosurface movements I fail to see how it could be anything but easier. For more difficult cases, whether you are scaling an angle or a normalized value, it should be similar. It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. Not sure I agree here. It should not be a big deal to have two subclasses, one to handle normalized and one to handle not normalized. It's not such a big deal to me except in that I don't want the FDM to be dealing with things it does not need to be dealing with - I want to work towards reducing excess baggage from JSBSim proper. I'd be content with moving normalization into the interface class. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Jon S Berndt said: Also, ask yourself the question, does the normalized value of, say, 0.5 really correspond to 30 degrees of flaps when the total range is 0 to 60? No telling. How many angles can you discern at 50 meters on a 1600 pixel screen (not to mention 800)? :-) Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. Not sure I agree here. It should not be a big deal to have two subclasses, one to handle normalized and one to handle not normalized. The 3D modeler would need to know which class object X belonged to. Well...I suppose...as usual I'm just too easily confused :-) It's not such a big deal to me except in that I don't want the FDM to be dealing with things it does not need to be dealing with - I want to work towards reducing excess baggage from JSBSim proper. I'd be content with moving normalization into the interface class. That's an option. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Regards aircraft 3d modelling and CVS
Just a brief question, I'm getting back into 3d modelling and would like to contribute geometry corrections for the C172P (I have a fairly extensive library of photos/drawings for the type). I'm just getting into AC3D as it seems rather pleasant to use compared to my usual tool, Blender, which while excruciatingly powerful is also slower to work with. My question is, can I commit changes to the C172 without 'stepping on someones toes' ? (I promise to make changes as accurate as my measurements and knowledge will allow). Or if there someone I should contact who is leading design for the model?. Thanks. Notes: Geometries I am looking to correct are the struts to the last spar before the wing taper, the thickness of the strut as viewed from the side (+30%), the angle of the exhaust, the nose leg and wheel and possible addition of the P's port-wing dual landing lights. I do not intend to add extra vertices except in the case of the port-wing landing lights. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Hi Jon, I see you are really mad :) Look here at the X-15 data and FCS diagram: http://jsbsim.sourceforge.net/X-15Aero.html The USAF F-16 (Block 40) FCS diagram is the same way: stick force is the input. Same with Space Shuttle control Law diagrams. The JSBSim X-15 model simulates the X-15 control laws as shown in the link above. We take the -1 to +1 joystick input from FlightGear and turn it into a stick force, mapping to the force range described in Etkin's book as a sort of standard. These are 3 particular examples only. (about F16) AFAIK, it has nonmoving joystick, and force transducers, and it is normal for that plane to ise output from the transduced as a input. (about X15) AFAIK, it had 2 completely different (unconnected?) sticks, one for lower speeds (usual stick), and the other one (joystick actually) used for control in higer speeds regimes. Does it apply for both sticks? As I mentioned, these are 3 particular examples only, not a general rule . cheers, :) Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Spectacular ground transport
More picutures can be found here: http://www.airliners.net/search/photo.search?regsearch=PH-BUKdistinct_entry=true Ampere On December 16, 2004 03:43 pm, Durk Talsma wrote: Tonight an old KLM-747 will be shipped through the canals of Amsterdam on it's way from Schiphol Airport (EHAM) to the new Aviodrome (http://www.aviodrome.nl) museum at Lelystad airport (EHLE). I found some pictures at: http://www.ruudleeuw.com/phbuk-15dec04.htm The transport will pass near where I live in a few hours, so I'm tying to see if I can catch a glimpse. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
David Luff writes: I guess I'd better go and see what it looks like on an NVidea card now... Well, I've had a very good pan round the Chicago scenery in the ufo with both the old and new materials.xml on a Linux box with a Geforce3, and I can't find a shred of difference in any of the runways, regardless of surface or marking type. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Spectacular ground transport
Well, I can only respond with an air transport: http://www.flugzeugbilder.de/show.php?id=256867 (I haven't scanned my own pictures yet; if you search for Beluga and MUC you'll find lots of pictures on the net) There an A310 (history of this plane: http://www.planemad.net/Production_List/Airbus/A310/276.html) was cut and the front part was brought to the Fraunhofer Institute in Holzkirchen to serve as an laboratory for research of the effects of long distance flying on humans. The first part of the plane was carried by an Beluga to MUC (EDDM) and from there by a extra heavy road transport to its destination. As my dad is/was responsible for this laboratory (the last thing before retirement) I could be at the airport as the Beluga arrived and unloaded the plane. Currently I'm trying to convince them to use FlightGear for their visuals... CU, Christian Ampere K. Hardraade schrieb: More picutures can be found here: http://www.airliners.net/search/photo.search?regsearch=PH-BUKdistinct_entry=true Ampere On December 16, 2004 03:43 pm, Durk Talsma wrote: Tonight an old KLM-747 will be shipped through the canals of Amsterdam on it's way from Schiphol Airport (EHAM) to the new Aviodrome (http://www.aviodrome.nl) museum at Lelystad airport (EHLE). I found some pictures at: http://www.ruudleeuw.com/phbuk-15dec04.htm The transport will pass near where I live in a few hours, so I'm tying to see if I can catch a glimpse. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Spectacular ground transport
On December 16, 2004 06:11 pm, Christian Mayer wrote: Currently I'm trying to convince them to use FlightGear for their visuals... You will need to write a technical report for that. Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On Thu, 16 Dec 2004 23:04:30 + David Luff [EMAIL PROTECTED] wrote: Well, I've had a very good pan round the Chicago scenery in the ufo with both the old and new materials.xml on a Linux box with a Geforce3, and I can't find a shred of difference in any of the runways, regardless of surface or marking type. FWIW, I just did the same with a GF4 Ti4600, checked asphalt and concrete rwys with both materials.xml's, took snapshots from identical perspectives so I could compare them directly, and I can't see any differences . . . -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpTMp8npj6Oz.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Spectacular ground transport
Any more background on why the aircraft is being transported this way? The obvious solution to getting the aircraft there would be to fly it in. EHLE has 4,265ft of runway; more than enough to get a 747 down with nil payload and a light fuel load. (A 747 with payload + light fuel can reputedly stop in 3,000ft). Was there a major mechanical problem with the A/C while it was at EHAM? Or had it just been out of service there for a long time? Anecdotally; Several VC-10s were mothballed in the UK for years and then flown out for recomissioning to the RAF with nothing more than a basic VFR panel and still wearing their protective coat of storing-wax. On Thursday 16 Dec 2004 20:43, Durk Talsma wrote: Tonight an old KLM-747 will be shipped through the canals of Amsterdam on it's way from Schiphol Airport (EHAM) to the new Aviodrome (http://www.aviodrome.nl) museum at Lelystad airport (EHLE). I found some pictures at: http://www.ruudleeuw.com/phbuk-15dec04.htm The transport will pass near where I live in a few hours, so I'm tying to see if I can catch a glimpse. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regards aircraft 3d modelling and CVS
On Friday 17 Dec 2004 01:30, Curtis L. Olson wrote: Dave, Is the the default aircraft? The current C172 models are very functional, but pretty basic. They certainly could be spiffed up a bit. I'm not opposed to adding a few polygons if they contribute to the model. Part of the trick of 3d modeling is figuring out the most effective places to spend your polygon budget. As far as I know, no one is currently working on updating the c172 3d models, so I would say feel free to move forward. You could always work with a copy, leaving the original intact, and then we could vote or if it's clearly better, we could just replace the current model. You will have to send your changes to one of the core developers in order to get them committed to cvs. Best regards, Curt. Yes, its the default 172 which I believe represents the 'P' model. Initially (while I get used to AC3D) I'd like to just get the geometries right compared to photos and diagrams that I have of a real 172P. I think your idea would be best that I work on a duplicate of the aircraft which can later be merged or be a seperate model. Working on a seperate model would also allow for accidental breakages of the model in CVS while the default aircraft remains sound. I shall get what I can done and then contact a core developer and massage their soul into letting my design into FlightGear ;) Also In the pipeline I've been working out how to produce other variants of the piper 'Indians' from the Warrior PA28 in FG. A Warrior can quite easily be converted to represent a Cherokee (chocolate-bar wing), Arrow or an Apache. A twin-engine Seminole is even possible with slightly more intense modifications. Following the methods used by Piper to develop the real aircraft, the Cherokee 6 and Saratoga could be derived from the same model and that, of course, paves the way for a Seneca. (Of course, all of the above would take a lot of time so it is something to be anticipated for the future I hope). Hopefully, I will have plenty of time over Christmas to work on the Geometries of the 172 - Time I will need as I am only just getting used to the XML model animation format used by FlightGear which is thankfully fairly intuitive. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] PATCH: two changes to data/Aircraft/737/Instruments/pfd2.xml
The first: In going from version 1.3 to 1.4, Melchior Franz noted that there was no /velocities/vertical-speed-fpm property to display, and changed the property referenced to /velocities/vertical-speed-fps, which does exist. But the display should show fpm; so a scale parameter is inserted to make what's displayed feet-per-minute. The second: In going from version 1.1 to 1.2, properties with '[0]' indices had the '[0]' dropped. But for some reason, a reference to property dme/indicated-distance-nm[0] got changed to dme/distance-nm. In other words, not only did [0] get dropped, but 'indicated-' got dropped from the property name. This broke DME on the 737 -- there is no 'dme/distance-nm' property. This patch fixes it back. Index: pfd2.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/737/Instruments/pfd2.xml,v retrieving revision 1.4 diff -u -r1.4 pfd2.xml --- pfd2.xml13 Dec 2004 20:35:34 - 1.4 +++ pfd2.xml17 Dec 2004 01:51:56 - @@ -353,6 +353,7 @@ chunk typenumber-value/type property/velocities/vertical-speed-fps/property + scale60/scale format%6.0f/format /chunk /chunks @@ -387,7 +388,7 @@ chunks chunk typenumber-value/type - property/instrumentation/dme/distance-nm/property + property/instrumentation/dme/indicated-distance-nm/property format%6.1f/format /chunk /chunks -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgph5hjqoBKHh.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS Build error
Hi, Building CVs pre-release: FGNozzle.cpp:74: implicit declaration of function 'int JSBSim::snprintf(...)' what's missing? library? upgrade compiler? still running with 2.95.4 Moving up from 0.9.5 which works fine, skipped 0.9.6. Did I miss something that happened in 0.9.6? Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Wed, 15 Dec 2004 23:13:05 -0500, Ampere wrote in message [EMAIL PROTECTED]: On December 14, 2004 10:39 pm, Oliver C. wrote: What would you think about the following options: - Learn to Fly - Quick Flight - Scenario Flight - Configuration or Settings - Quit Best Regards, Oliver C. I think the Learn to Fly option is an excellent idea. As you have pointed out, the tutorial can be educational as well as keeping the users' interests in FlightGear. I actually expanded on this idea a bit. Tell me what you think. Here is a general idea of mine: - Multiple scenarios (lessons) should be grouped together to form a course. Each course has a topic and objective(s), and the lessons in the course will teach the user about the important knowledge regarding the subject. We all went through school, so this is pretty self explanatory and I won't make any example. - As the user progress through the course, he/she will be rewarded with experience points. These will be useful later. - The last scenario of each course should be (dun dun dun) a test. In these tests, the user will have to complete some tasks, say: fly one circuit with a cessna and land dead on the center line of the runway. safely. The user will earn points on 1) safety 2) following regulations 3) completing the tasks. - When a course is passed, new course(s)/scenarios will be unlocked. Also, the more experience points the user has, the more aircrafts he/she will have access to. ..FG-lawfully. ;-) Gamers obviously wanna buzz the White House in an X-15 or in 747 formations, or touch-and-go the Space Shuttle on any nice wee town's drag strip. We have the Shuttle launching? The purpose of the above idea is not only to be educational and fun, but to also give motivation and provide encouragement to the users so that they will utilize the tutorials. It can also prevent newbies from flying a 747 before he/she can handle a cessna. A user may be able to access a lot of planes due to his/her experience points, but it will be necessary to pass the tests before he/she can truly unlock these planes. Similarly, a user may unlocked a lot of scenarios, but enough experience points must be gained so that the required aircrafts in some of the scenarios can be unlocked. Of course, being developers, we will definately want to bypass the above mess. To do so, we may want to have: a) special codes to unlock some or everything. b) the ability to boot into FlightGear directly by including any parameters in the command line. As for the Scenario Flight option, I think it will be better to include it within the Learn to Fly experience or the Quick Flight option, and leave the space for an option to the multiplayer ..ahem; traffic, advanced flight traing and formation flight. ;-) menu in the future. Ampere -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Andrew Midosn wrote: It seems slightly odd to me to feel that 'serious' users don't want/need a decent user interface, while gamers do. As a Linux user, and a developer who is happy to use command line tools, I'm certainly not afraid of not having a GUI available. But if someone I'm talking about full-blown simulators here, where there is no keyboard (or mouse) in sight of the visual system and everything has to be done remote, using an instructor station. Often this implies multiple display systems. That's one of the audiences we are targeting at. Not just the Joe Regular home user. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Am Mittwoch 15 Dezember 2004 14:48 schrieb Oliver C.: On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? For integration with existing desktops it's possibly best to use their native libs. QT for example provides an OpenGL widget, so all of the gui (menu, dialogs) could be native QT Widgets. Also if the sim runs in the context of a GUI it will be easy to switch between them at startup, i.e. 'fgfs --gui-gnome' runs a GTK based GUI, whereas 'fgfs --gui-qt' runs a qt based one. Don't know about possible performance issues, though. :-( Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
On Thursday 16 Dec 2004 09:07, Erik Hofman wrote: I'm talking about full-blown simulators here, where there is no keyboard (or mouse) in sight of the visual system and everything has to be done remote, using an instructor station. Often this implies multiple display systems. That's one of the audiences we are targeting at. Not just the Joe Regular home user. Erik I second this. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Next release planning ...
* Melchior FRANZ -- Wednesday 15 December 2004 22:38: fgfs doesn't like *.sav files with property alias (see below). It doesn't really crash, but abort. z-offset-m alias=/sim[0]/chase-distance-m[0]/ fixed. Need to make some more tests before sending to Erik. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] control surface normalization
Hi, I agree with Norman. As long as control system is of concern, it is much better to use normalized units. Control law block diagrams I have seen take stick input in pounds force (pilot inputs) and output in degrees to actuators. I've never seen one that output control commands to an aerosurface actuator in a range from 0 to 1. Have you? surface deflections in degrees, and for good reason: it's natural, it's physical. From the point of view of JSBSim, normalized aerosurface Degrees are not natural, nor physical. We may argude that *radians* might be natural, but *not* degrees. By natural I mean that it's: the most commonly seen angular command unit for aerosurfaces, that it's what is used by the rendering routines to rotate 3D objects, that it completely specifies the commanded angular position without the need for a range (a range of 0 to 1 by itself specifies nothing without the definition of what the maximum is - there is no standard here for that), and much aero data is non-dimensionalised using degrees (or radians, see below). So, sorry, but based on the above description, for this application, yes, degrees are natural. This would lead us to another class of problems, what system of measurements is used? (I'm used to SI system) or what about input (I mean stick, pedals positions...)? Should the input be expressed in natural or normalized units? I've said several times that we expect INPUTS in a range from zero to 1. We can process the inputs to arrive at a force unit to match the FCS block diagram. Note that for JSBSim we are also changing the config file format. When the next major version of JSBSim is released (early next year) supporting the new configuration file format, many items will now take a UNIT= attribute, allowing aircraft to be defined in different unit systems. And about FDM itself, aerodata to be used are not unified... I have seen some using degrees as a control surface deflections units, and others using radians. What would you choose as a natural? True, I've seen both. JSBSim has used both, and we accept both, but normalized units are anything but normal - you have to provide a range for it to mean anything, and as far as I can tell, there is no standard here. It's defined on a per-aircraft basis. And, as I have pointed out above, for aerosurfaces it requires an intermediate conversion twice. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Next release planning ...
Melchior FRANZ wrote: * Chris Metzler -- Wednesday 15 December 2004 19:15: - attempting to load a saved state from the menu crashes the program. fgfs doesn't like *.sav files with property alias (see below). It doesn't really crash, but abort. z-offset-m alias=/sim[0]/chase-distance-m[0]/ In the archives I noticed you had a patch for this. My email eems to be a bit slow today, so could you post an URL to the patch, then I'll fetch it from the list archives. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Thomas Förster schrieb: Am Mittwoch 15 Dezember 2004 14:48 schrieb Oliver C.: On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? Well, I don't think that replacing PUI has a high priority. I doesn't look that bad (but doesn't mirror the OS style). And it get's drawn by OpenGL with a low overhead. So we should improve the underlaying functionality first, bevore we consider exchanging PUI. For integration with existing desktops it's possibly best to use their native libs. QT for example provides an OpenGL widget, so all of the gui (menu, dialogs) could be native QT Widgets. Also if the sim runs in the context of a GUI it will be easy to switch between them at startup, i.e. 'fgfs --gui-gnome' runs a GTK based GUI, whereas 'fgfs --gui-qt' runs a qt based one. Don't know about possible performance issues, though. :-( This sounds like unlimited resources where you can afford the luxurity to code a GNOME, as Qt, a Windows, a MacOS, a [...] interface... A Qt only interface sounds good - but Qt isn't free for Windows (you'll only get an 30 day evaluation copy IIRC), so we can't use it :( CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On 12/16/04 at 11:43 AM Martin Spott wrote: David Luff wrote: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095. html It requires openGL-1.2 for the patch to take effect, which I don't have on Cygwin. If your SGI is openGL-1.2 capable, then perhaps you could see if it makes any difference on your system? I'll have a look tonight, I've commited a work-around to the base that wraps all the symetrical runway panels in the v direction (everything except the threshold panel has identical upper and lower borders, and so can safetly be wrapped in v given that we're only wrapping a handfull of pixels). This removes the vast majority of the lines (all except at the threshold, and the longitudional line where rwy numbers are made of 2 digits). You can still test Andy's plib patch by using the 2D c172 (--aircraft=c172p-2dpanel) which will almost certainly exhibit panel jointing problems if you've been seeing runway lines. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
David Luff wrote: On 12/16/04 at 11:43 AM Martin Spott wrote: David Luff wrote: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095. html It requires openGL-1.2 for the patch to take effect, which I don't have on Cygwin. If your SGI is openGL-1.2 capable, then perhaps you could see if it makes any difference on your system? I'll have a look tonight, I've commited a work-around to the base that wraps all the symetrical runway panels in the v direction (everything except the threshold panel has identical upper and lower borders, and so can safetly be wrapped in v given that we're only wrapping a handfull of pixels). This removes the vast majority of the lines (all except at the threshold, and the longitudional line where rwy numbers are made of 2 digits). You can still test Andy's plib patch by using the 2D c172 (--aircraft=c172p-2dpanel) which will almost certainly exhibit panel jointing problems if you've been seeing runway lines. Dave, Based on all my knowledge of OpenGL, this is the wrong thing to do and will introduce additional (although possibly less visible) artifacts at the edges. The visual results should be examined *very* carefully. I don't think this is what we want to do. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
On Thursday 16 December 2004 04:06, Jon Berndt wrote: True, I've seen both. JSBSim has used both, and we accept both, but normalized units are anything but normal - you have to provide a range for it to mean anything, and as far as I can tell, there is no standard here. It's defined on a per-aircraft basis. And, as I have pointed out above, for aerosurfaces it requires an intermediate conversion twice. A rotation whether in degrees or radians only makes sense if the axis of rotation is specified. This would have to be on a per aircraft basis. Also I'm sure that many if not most control surfaces do not simply rotate about a single axis but involve sliding motion and rotation of multiple parts and often, rotation while sliding. I think a normalized value makes good sense. For complicated cases, on the FDM side, it can be converted into an index into a table of effective force while on the GUI side, it could index into a table of drawing routines. Just my 2 cents. Richard Harke ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Richard Harke said: A rotation whether in degrees or radians only makes sense if the axis of rotation is specified. This would have to be on a per aircraft basis. Also I'm sure that many if not most control surfaces do not simply rotate about a single axis but involve sliding motion and rotation of multiple parts and often, rotation while sliding. snip This is just what was going through my mind when reading this discussion. Jon's concern is quite valid, but there are problems. As I work through these concepts in my mind, I can see that although the current method sounds more complicated for the 3D animator, having to deal with the real values could be a lot worse (at least with the current architecture). It might be useful for someone to work through the values as that would be report for the various stages of deployment on a 747 flap system. As Richard message suggests here the detail required by the 3D modeler is sometimes quite a bit more than what is required by the FDM. Also, to have some objects reported normalized and other objects reported actual would be too confusing...even if the distinctions and reasons were logically sensible. In the long run we'll benefit the most from consistency even if it means more work at the FDM interface. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
Pilots are taught to think in terms of pressure on stick not displacement. That is part of the reason that the F-16 is built the way it is. -- Adam Dershowitz, Ph.D., CFI, MEI From: Gordan Sikic [EMAIL PROTECTED] Reply-To: FlightGear developers discussions [EMAIL PROTECTED] Date: Thu, 16 Dec 2004 23:08:30 +0100 To: FlightGear developers discussions [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] control surface normalization Hi Jon, I see you are really mad :) Look here at the X-15 data and FCS diagram: http://jsbsim.sourceforge.net/X-15Aero.html The USAF F-16 (Block 40) FCS diagram is the same way: stick force is the input. Same with Space Shuttle control Law diagrams. The JSBSim X-15 model simulates the X-15 control laws as shown in the link above. We take the -1 to +1 joystick input from FlightGear and turn it into a stick force, mapping to the force range described in Etkin's book as a sort of standard. These are 3 particular examples only. (about F16) AFAIK, it has nonmoving joystick, and force transducers, and it is normal for that plane to ise output from the transduced as a input. (about X15) AFAIK, it had 2 completely different (unconnected?) sticks, one for lower speeds (usual stick), and the other one (joystick actually) used for control in higer speeds regimes. Does it apply for both sticks? As I mentioned, these are 3 particular examples only, not a general rule . cheers, :) Gordan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
David Luff wrote: It requires openGL-1.2 for the patch to take effect, which I don't have on Cygwin. If your SGI is openGL-1.2 capable, then perhaps you could see if it makes any difference on your system? Hmmm this is IRIX-6.5.22: sirius: 22:33:55 ~ glxinfo display: :0.0 server glx vendor string: SGI server glx version string: 1.3 Irix 6.5 server glx extensions (GLX_): EXT_import_context, EXT_visual_info, EXT_visual_rating, SGI_make_current_read, SGI_swap_control, SGI_video_sync, SGIX_fbconfig, SGIX_pbuffer, SGIX_swap_group. client glx version 1.3 client glx extensions (GLX_): EXT_import_context, EXT_visual_info, EXT_visual_rating, SGI_make_current_read, SGI_swap_control, SGI_video_sync, SGIX_fbconfig, SGIX_pbuffer, SGIX_swap_group. OpenGL vendor string: SGI OpenGL renderer string: IMPACT/2/2/4 OpenGL version string: 1.1 Irix 6.5 [...] Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
