Re: [Flightgear-devel] JSBSim initialization bug
On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
On Friday 02 April 2004 09:41, Vivian Meazza wrote: The Spitfire also had a drag-reducing radiator. I think the key _was_ the wing section. The Spitfire was eventually fitted with a Mustang-like laminar flow wing, which enabled the aircraft to reach 450+ mph. Pardon my lack of aero-engineering experience, but aren't all wings built for laminar flow? Or does the term mean more laminar? The Mustang was one of the first aircraft to use an airfoil designed for longer runs of laminar flow. The Spit and FW190 did not - at least in the early versions. The upper surface of the wing should have been able to support a laminar flow with transition occurring as far back as half the wing chord. In practice, however, only the first 15% of the wing chord saw laminar flow, due to wing imperfections. [This, according to an article by aerodynamicist David Lednicer] Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
The Mustang was one of the first aircraft to use an airfoil designed for longer runs of laminar flow. The Spit and FW190 did not - at least in the early versions. The upper surface of the wing should have been able to support a laminar flow with transition occurring as far back as half the wing chord. In practice, however, only the first 15% of the wing chord saw laminar flow, due to wing imperfections. [This, according to an article by aerodynamicist David Lednicer] Jon Additionally [from Quest for Performance: The Evolution of Modern Aircraft], The use of the in-line engine of low frontal area resulted in a fuselage of relatively low total wetted area and gave the aircraft a lean, streamlined appearance. The low frontal area of the in-line engine was one of the chief advantages cited for this type of power plant; the disadvantage was the vulnerability of the cooling system to enemy fire. The aft location of the cooling radiator and its associated inlet and internal flow system is of interest. The system was designed with the objective of obtaining a net thrust from the cooling air as a result of heat addition from the engine coolant. This feature no doubt contributed to the very low drag coefficient of the aircraft. The P-51 was also the first aircraft to utilize the NACA laminar-flow airfoil sections, discussed earlier. Although it is doubtful that any significant laminar flow was achieved on production versions of the Mustang, the low-drag airfoils did provide improved characteristics at high subsonic Mach numbers. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
Mathias Fröhlich said: On Freitag, 2. April 2004 05:47, Jim Wilson wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. Others don't work too. The A320 for example ends upside down too. The issue appears to be due to a difference between how the FDM is initialized on startup and how it is initialized on restart. On startup the FDM initialization is delayed until a tile is loaded for the startup location, giving an accurate ground elevation value (test for gound_elev -9990). This test is not possible during the reinit phase, because we're only passing through the reinitialize routine once. The more I look at the workarounds we have been accumulating for making flightgear initialize and reinitialize the more I realize that we may be frequently taking the wrong approach to solving such issues. We are failing to build self-sufficient and self-protecting subsystems. :) Hmm, I am not very familiar with the way flightgear interfaces with a FDM. What I can tell now is that JSBSim has a problem with it's timestepping method during reinitialization. But Jon and me are working on this. But this is not the whole problem. Doing this right is not sufficient. Which is why I'm calling this a JSBSim bug. If the altitude is -9990 and/or the ground_elelvation is -9990, would it be possible for JSBSim to not ground trim and instead go for a coffee or freeze or whatever it needs to do while the scenery system gets wound up? In other words, rather than try and find another bandaid, what I would like to do is remove the elevation test from following code in main.cxx and let the fdm take care of itself: I am not shure what happens here. But it appears to me that either FGInterface::update(double) or FGInterface::init() is called while the environment (ground level, etc ...) containes senseless data, true? So, for the coffee question, I think that this could be done. But you told about self-sufficient and self-protecting subsystems. I don't think that this goal could be achieved when code, which in effect tests for an error condition of the tile loader, which is something orthogonal to flightdynamics, is moved into a FDM. Just call FGInterface::init() when the FDM has *all* data required for initialization. The same goes for FGInterface::update(double), it should not be called when the FDM sees screwed up environment data ... Or, in other words, why should a FDM need to know that groundlevels below -9990ft are an error condition of the tile loader? My response is that the Init is merely for setting up and initializing data structures. This should happen independent of what is on the bus. The updates should basically noop until all the parts it needs are initialized, although with something like this case it might be fine to merely delay the ground trimming, but go ahead and process non-external data. BTW I'm not sure of your characterization of the relationship between these two subsystems. That was my question, is this more than just ground trimming? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. I don't use the reset feature, but I just tried a few runs with the 737 and T38 using the menu item Location | Position Aircraft (on ground), and this works every time. Is there a different reset function? If so, then the answer might be in the code attached to the above menu item. Dave -- David Culp davidculp2[at]comcast.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] How to fly a Piper Cub
I just ran across the following and thought it might look interesting to someone since FG has a nice cub ... http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItemitem=3185540829category=34056 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
[Flightgear-devel] Adding lights to a 3d model
Hi everyone, I'm created the model of mb339PAN and now I'm trying to add the lights to it. I'm working wirh 3dsMAX and exporting all in the ASE format that it's supported by FlightGear. I've found that the lights, in the ASE format, are created thorought changing the vertex colors. In this way they appear in FlightGear but they aren't very realistic. When I downloaded the 0.9.4 version I've seen the lights of the bo105 and I've tried to do the same with my model. So I reused some files of the bo105 and I changed the names in the model to match the one's used in animations but the lights doesn't appear. I reused the nasal file and the light off corectly appear and disappear, but the light on ones doesn't. Which is the problem? Another question: There's a way to use the lights that could be exported into the ASE file? This could improve the realism of all the model. Hi, Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
On Friday 02 April 2004 13:33, Jon Berndt wrote: [...] drag coefficient of the aircraft. The P-51 was also the first aircraft to utilize the NACA laminar-flow airfoil sections, discussed earlier. Although it is doubtful that any significant laminar flow was achieved on production versions of the Mustang, the low-drag airfoils did provide improved characteristics at high subsonic Mach numbers. How is the situation in this area today? Do for instance modern jet fighters have laminar flow over the whole wing? (I guess the whole picture changes a lot when you go supersonic.) -- best regards, Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ systems | ez.no ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Adding lights to a 3d model
* Luca Masera -- Friday 02 April 2004 16:47: I'm working wirh 3dsMAX and exporting all in the ASE format that it's supported by FlightGear. [...] I reused some files of the bo105 and I changed the names in the model to match the one's used in animations but the lights doesn't appear. I reused the nasal file and the light off corectly appear and disappear, but the light on ones doesn't. Which is the problem? Hard to say without seeing the code. The ASE format isn't very well tested in fgfs. Everyone uses ac3d models -- the few imported mdl models do AFAIK not use animations. So, what could your problem be? Wrong object names, wrong material definitions, wrong animation code, plib loader bug, ... m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire Hurricane manuals
On Wednesday 31 Mar 2004 11:09 am, Vivian Meazza wrote: snip I now have the Spitfire IIa model well underway. I have all the drawings and data I need (far too much probably). I've rather lost the bubble on the recent changes to the piston engine simulation in YASim: Vivian The pictures here http://www.raf.mod.uk/news/limage_bbmf.html appeared on our intranet and I thought you might find them useful. 'Desert Spitfire' clearly has a four-bladed propeller, while 'Spitfire Head-On' is equally clearly three-bladed. There's some good detailed views for modellers, though. Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim initialization bug
On Friday 02 Apr 2004 2:23 pm, David Culp wrote: Earlier we had a report of a reset issue on the list. It appears that the problem only affects a couple JSBSim aircraft...the c172 (all of them) and the 737. Everything else seems to trim fine. I don't use the reset feature, but I just tried a few runs with the 737 and T38 using the menu item Location | Position Aircraft (on ground), and this works every time. Is there a different reset function? If so, then the answer might be in the code attached to the above menu item. Dave The reset function I (hardly ever) use is bound to Shift-Esc in data/keyboard.xml: key n=27 nameESC/name descPrompt and quit FlightGear./desc binding commanddialog-show/command dialog-nameexit/dialog-name /binding mod-shift descReset FlightGear./desc binding commandold-reinit-dialog/command /binding /mod-shift /key 'Location | Position Aircraft (on ground)' didn't work for me at a number of Californian airfields with the C172-3d - an external view shows the plane tumbling around the sky like an empty plastic bag! I also tried to position in air, which was more successful, except I wasn't quite ready for the magneto switch being in the OFF position :¬) Good job I didn't have to get out and swing the propeller, eh? Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multi-pass-clouds + sun + fog
Melchior FRANZ wrote: The new code works (almost) well for me. Doesn't even slow my fps down considerably. But: As soon as I get the sun in my view, fog disappears. It comes back when the sun is out of view again. So I can only have sun *or* fog. Erik thinks that this is an nVidia bug. Makes the multi-pass-clouds more or less unusable. :-/ This should be fixed in CVS now, after some discussion about it in IRC. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multi-pass-clouds + sun + fog
Melchior FRANZ wrote: The new code works (almost) well for me. Doesn't even slow my fps down considerably. But: As soon as I get the sun in my view, fog disappears. It comes back when the sun is out of view again. So I can only have sun *or* fog. Erik thinks that this is an nVidia bug. Makes the multi-pass-clouds more or less unusable. :-/ For the record, we tracked down the problem on IRC and the fix is in CVS -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: multi-pass-clouds + sun + fog
* Melchior FRANZ -- Friday 02 April 2004 20:18: As soon as I get the sun in my view, fog disappears. Fixed in CVS now. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with Reset
On Thu, 1 Apr 2004, Jim Wilson wrote: In either case the aircraft is a little too high off the pavement on restart and crashes. I'll take a look later today or tomorrow unless someone else gets to it first. I've had problems like this just *starting* the sim with the fokker 50 100. They just flip over on their backs. It's almost like there's no contact point on the wingtips to stop them falling over if they don't balance perfectly on the wheels. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
Gunnstein Lye wrote On Friday 02 April 2004 13:33, Jon Berndt wrote: [...] drag coefficient of the aircraft. The P-51 was also the first aircraft to utilize the NACA laminar-flow airfoil sections, discussed earlier. Although it is doubtful that any significant laminar flow was achieved on production versions of the Mustang, the low-drag airfoils did provide improved characteristics at high subsonic Mach numbers. How is the situation in this area today? Do for instance modern jet fighters have laminar flow over the whole wing? (I guess the whole picture changes a lot when you go supersonic.) I think that any aircraft designed post-1950 to operate in the trans-sonic region would have a laminar flow wing. For example: the De Havilland Venom was a Vampire with a laminar flow wing. Supersonic aerofoil sections are whole new subject. This may be of interest http://www.aae.uiuc.edu/m-selig/ads/aircraft.html That said that list shows a different NACA number for the Spitfire to a contemporary paper so ... Regards Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
On Fri, 2 Apr 2004 00:39:34 -, Jim Wilson [EMAIL PROTECTED] wrote: snip Is it fair to say that the 400lbs of drag returns at approach speeds though? That number isn't apparent there. BTW YASim is reporting that the p51d is putting out about 2000 lb.+ maximum, which seems like a lot. I think that the article was referring to net thrust from the propellor-powerplant combination. 2000lb of engine ;power' doesn't necessarily make for 2000lb of thrust from the prop. I think its more that the drag returns, to some extent, when the engine is at lower power settings although, being a ramjet type arrangement, there may be a loss of efficiency (and hence higher drag) at lower speeds. Rick -- Help the Waterway Recovery Group to help restore the Uks canal network Make a donation to the 'Right Tool' Appeal http://www.wrg.org.uk/cgi-bin/fmaker.pl?appeal.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
Rick Ansell wrote: I think that the article was referring to net thrust from the propellor-powerplant combination. 2000lb of engine ;power' doesn't necessarily make for 2000lb of thrust from the prop. Actually, 2000 pounds of thrust doesn't sound that far off. To start with an intuitive argument: 2000 lbs is about half of what a light bizjet of the same weight as the Mustang gets, so we're not too far from the right ballpark. More numerically: The engine is listed as 1590 horsepower. Figure that it can develop that power at sea level while going at 360 knots (~180m/s). One HP is 745 watts, and figure about 80% efficiency (peak for most propellers is 85%) so we have: 1590 * 745 * 0.8 / 180 = 5264 Newtons == 1180 pounds of force. That's at max speed. If you develop the same power and get the same prop efficiency at 200 knots (which is still well within a normal environment), then you'll see 2000 pounds from the prop. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
On Thu, 1 Apr 2004 18:52:03 -0600, Jon Berndt [EMAIL PROTECTED] wrote: BTW I never said 'whole aircraft drag' - always just the drag due to the cooling system. In this article we have some better numbers: 350lb of additional thrust on an aeroplane generating c. 1000lb of thrust via the prop. Or 400lbs worth of drag reduced to 50lbs. The Spitfire MkIX wasn't a particularly inefficient aeroplane, there has to be a reason why the Mustang (unquoted Mk but assumed to be roughly equivalent) was (according to this article) 30mph faster. Wing, duct or both? I've got plenty of articles around here somewhere ... this sounds familiar. I'll see if I can find a reference. Some comparative numbers from WWII RAF (late 1943) testing. The Mustang was a P51B. Vs Spitfire IX: '... the Mustang is a much cleaner aircarft...' Wing Loading: 43.8 vs 31 lbs per sq ft Range with full fuel: 1.5 to 1.75 that of Spitfire Fuel Load: 183 vs 101 US Gal Oil: 13.3 va 7.5 US Gal Fuel with long range tanks: 330 vs 210 US Gal 20-30 mph faster at all heights. Heights for best performance: Similar, 10,000-15,00 ft and 25,000 to 30,000 ft Full power climb inferior: Spitfire formates with 5lb less boost with Mustang at full power. (full power in 18lbs boost) Climb at 175mph similar. Pulls away from Spitfire rapidly in a dive. Spitfire requires 4-6lbs more boost to remain in formation Inferior in turn. Turning circle not noticeably improved by flaps. Inferior in roll at normal speeds. Equivalent at 400 mph Vs Spitfire XIV Speed: No practical difference. Climb: Spitfire 'very much better' Dive: Advantage less marked than with Mk IX Vs FW190 A-3 (no water-methonol boost) Speed: c 50 mph faster than FW190, 70 mph above 28,000 ft. Climb: 'little to choose' Dive: Mustang can always out-dive FW190 Turn: Slightly superior. Roll rate: FW190 markedly better. Vs Bf109G-2 (no water-methonol of nitrous oxide) Faster at all heights. Bf109 best heights 16,000ft (Mustang 30 mph faster) and above 25,000 ft (30mph increasing to 50mph at 30,000 ft) Climb: Similar, Mustang slightly better above 25,000 ft, slightly worse below 20,000 ft Dive: Better in prolonged dive. turn: Mustang greatly superior. Roll: Not much to choose. In a tight turn the Bf109s wing slots open when a rapid change of bank is attempted producing an 'embarrassing' rate of roll. Wing tanks effect on performance: 40-50 mph loss of speed. Still faster than FW190 above 25,000 ft (but still slower than BF109). Climb: Out climbed by FW90 and Bf109. Followed by FW190, 'definitely outstripped' by Bf109 Dive: With 'fairly full' tanks still out dives FW190 and Bf109 turn: As tightly aa FW190, definitely better than Bf109 Roll: Handling very little effected. Vs Tempest V Speed: Mustang 15-20 mph slower up to 15,000 ft, same to 24,000 ft, Mustang 30 mph faster at 30,000 ft. Climbs 'Compare directly with speed tests' Rate of turn: Mustang slightly better Roll: Tempest V inferior. On power, the '1000 lb' quoted by Atwood probably referred to the P51A's powerplant, I don't have figures but the P51D may well have double the power. Rick -- Help the Waterway Recovery Group to help restore the Uks canal network Make a donation to the 'Right Tool' Appeal http://www.wrg.org.uk/cgi-bin/fmaker.pl?appeal.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
On Fri, 2 Apr 2004 08:41:02 +0100, Vivian Meazza [EMAIL PROTECTED] wrote: snip The Spitfire also had a drag-reducing radiator. I think the key _was_ the wing section. The Spitfire was eventually fitted with a Mustang-like laminar flow wing, which enabled the aircraft to reach 450+ mph. it was to be known as the Spiteful. 373 aircraft were originally ordered from a revised Spitfire F21 contract although production was cancelled with the end of the war and the introduction into service of the new jet powered Meteor and Vampire. The aircraft eventually evolved into the Seafang for Royal Navy service which in its turn was also cancelled. The Spitfire radiator was fitted into the wing. The result was that a sharp turn in the duct was required. This produced turbulent flow through the radiator, largely negating the effect (there was _some_ benefit). Despite its other disadvantages the Spitfire wing had a higher compressibility threshold. Atwood made the point that, discounting losses due to production issues, the Mustang wing needed to be clean and polished to prevent a rapid drop off in efficiency - which didn't always apply in the field. This is one of the reasons why he regarded the radiator arrangement as more important. Rick -- Help the Waterway Recovery Group to help restore the Uks canal network Make a donation to the 'Right Tool' Appeal http://www.wrg.org.uk/cgi-bin/fmaker.pl?appeal.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
On Fri, 2 Apr 2004 08:22:49 +0100, Vivian Meazza [EMAIL PROTECTED] wrote: Not only the clever radiator, but also the ejector exhausts ... They have both been exercising my mind recently. I think both could be modelled within the existing Yasim framework. They are both a source of additional thrust, and both have an associated drag penalty. From 'Combat Development in World War II: Fighter Aircraft': For a Spifire V changing from 'fishtail' to 'ejector' type exhausts improved maximum speed by 7 mph. Rubbing down, polishing and filing gaps gave 6 mph more, waxing 3 mph more. On the other hand, the contribution of both is marginal, I feel. I would be surprised if the radiator drag, or lack of it effected the overall behaviour of the P51d model. I think there is something bigger at work here - an incorrect entry in the Yasim file, or an FDM error. I suspect something to do with the propeller right now. IIRC Yasim doesn't model drag due to the prop yet. Rick -- Help the Waterway Recovery Group to help restore the Uks canal network Make a donation to the 'Right Tool' Appeal http://www.wrg.org.uk/cgi-bin/fmaker.pl?appeal.htm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgfs aborting
I am planning a real flight to Des Moines, Iowa from Longmont, CO and have tried to use fgfs to prefly the route. In fgfs, flying the return trip (departing from KIKV) I pick up V172 to Omaha VOR 116.3. All is well until I am very near to this VOR and fgfs aborts. I am using the current Scenery and --disable-specular-highlight --prop:/environment/params/real-world-weather-fetch=true. I have Atlas running. I have tried several different aircraft. I believe I have tried it without the real-world weather and get the same abort at the same place. The error message is fgfs: ssg.h:288: void ssgBase::deadBeefCheck(): Assertion `type != (int) 0xDeadBeef' failed. Aborted Current cvs for plib, SimGear, and fgfs as of Wednesday evening running an updated Suse 9.0 linux on Athlon 1800+ XP, Nvida FX 5600 Ultra, 512MB DDR, Asus A7M266. By the way, there is a large shear in the current scenery just west of Des Moines. Not complaining, Dave Perry ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FW: [osg-user]Handling whole earth databases
FYI -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Robert Osfield Sent: Thursday, April 01, 2004 4:50 PM To: [EMAIL PROTECTED] Subject: [osg-user]Handling whole earth databases Hi All, As I write this, my other machine is churning away generating a PagedLOD database with about a billion polygons. Its only a chunk of the earth, but its wide enough area to see the curvature of the earth clearly when you a zoomed out. With such wide area models a number of issues arise, but first I'd like to open out two of these issue for discuccsion : 1) management of near and far clipping planes as one moves for a distant view of the the whole earth to a local view with objects visible within a meter away from the viewer. 2) how to adjust the local up vector used in drive manipulators and flight manipulators physics models. I'd like feedback on the community on my own thoughts below, and any funky suggestions that might save us all some time :-) -- My first thoughts on 1) near and far clipping are: We basically need to a class that takes as input of the current position in world coordinates, and output a new near and far value, which all sounds rather easy... except we need to have need formula for computing the near and far from the current position, and a framework for attaching this class to the scene graph, and for the cull traversal to be able to use this. As for the formula I have been thinking about having an ellipsode model for computing the local height of the control point above the ellipsode and from this compute the near and far value to use in some magical way. Another addition to this would be the automatic control of glFog (via osg::Fog) to make the far distance gradually disappear before the actual far plane cuts in. As you get lower and the far planes moves inward, so does the fog so you never see a line of terrain disappearing into the clipping plane. The framework might be as simple as just a cull callback attached to a node above the world with a reference to a Fog object which decorates the world. Only once I get to implementing it will I know for sure. Thoughts? Have others done similar things before? Any ideas of your own? -- My first thoughts on 2) adjusting for a local up are: Up in our world is generally defined by us as away from the earth, or to be more exact orthogonal to surface of the earth (ignore local gradients), or perhaps better as the axis that gravity acts. Since objects most physical models use gravity as part of the computation it seems to make sense to create an local gravity vector. We are now back to having a class which takes as input a control position and outputs a vector, with possibly the length of the vector the strength of gravity which could neatly allow us to have a model for other planets. The orientation of gravity vector could either just be modelled on sphere, or on an ellipsode, or perhaps even allow for local variations in the gravitational fields (this is the type of stuff that virtual functions were invented for:-) Once we have this class we are back to the issue of a framework for physics models/manipulators accessing the local orientation. For osgGA and other codes to be able to access this data we'll need a standard framework, most probably in the core OSG itself otherwise the dependencies list will just spiral away. osg::GravitationField anyone :-) -- So I'd love your feedback, is this stuff you've been thinking about before, and have already tackled and solved? Does the above look promising, or fall into any traps that need to be avoided. Cheers, Robert. ___ osg-user mailing list [EMAIL PROTECTED] http://dburns.dhs.org/mailman/listinfo/osg-user ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
