[Flightgear-devel] Re: Materials animation bug
* Jim Wilson -- Wednesday 25 May 2005 01:44: > It looks like setting up a materials animation with emission values clobers > the ambient values (sets them all to 0). This produces some pretty strange > looking shading. BTW: you don't need several material animations with lists of s. Just use the same material for all of these objects (or one for all needles, and one for all faces etc.). Then you can make one animation with true, and this will change emission for all objects that share the material. Makes the animation file less crowded and is faster, too. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Backing out Andy's p51d changes
Jim wrote > Hi Andy, > > On the p51d fdm configuration, it looks like the substantial change was > actually increasing the turbo multiplier from 2.0 to 5.5, and not > reducing the cruise speed as stated in the CVS log of March 23. The > cruise speed change does have an effect, but it is fairly small. > > The problem with putting the turbo multiplier up in that range is the > manifold pressure output is directly multiplied by that number. So full > throttle produces an output of 164 inHG manifold pressure. We should be > seeing about 61 inHG at sea level for this engine. > > Setting this multiplier lower to get the correct manifold pressure with > turbo at sea level should reduce the maximum flight level for the aircraft > since the second stage turbo cannot currently be modeled. On the other > hand, using this lower value should NOT produce incorrect lower altitude > performance since all the data I'm using is for below the 20,000 ft > altitude where the second stage kicks in. The drag numbers calculated by > YASim should be more or less correct up to at least up to 20,000 ft where > the second stage would be kicking in. > > If there is a problem that setting the multiplier to 5.5 fixes, I suspect > it is in the FDM design and not the P51D configuration. Any ideas how we > can fix or work around this? > Where do you get your numbers from for the boost? There are some contemporary figures around for the Rolls Royce built versions of the Mustang engine which indicate that the turbo multiplier should indeed be around 5: http://www.spitfireperformance.com/jf934climb.jpg Otherwise, you won't get the correct high-altitude performance. In the figure above extrapolate the boost curves back to sea-level, ignoring the effect of the Boost Controller (aka wastegate), and you will see that 5 is about right - even a bit more for the later Merlins. Don't forget that us Brits work in psi gauge, while the ex-colonies work in psi absolute: same thing +- 1 atmosphere. Although there is a bug in the current code which gives an incorrect readout of boost pressure (I forwarded a correction to Andy some weeks ago), the existing code gives pretty good results if you plug in the numbers right out of the book. I have just done it for the Merlin XX and was very impressed by the accuracy. Of course, we still have to model the gear-driven supercharger, but again I have forwarded some code to Andy which does this. We are still waiting to finalise some curves to match supercharger output. I've got some good-enough results here. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] How to control the simulation time of JSBSim (repost from JSBSim-devel)
This is actually a good question to pass along to the FlightGear developers list, too. I'll repost any good answers here to the JSBSim list. > Andreas wrote: > > > I want to use JSBSim to simulate an airplane (no matter which airplane, so > > I use > > the Cessna). > ... > > The problem now is that the simulation time is not the real time, e.g. 20 > > "simulation seconds" are executed in only 1 "real" second (clock time). But > > I > > need the simulation time to be equal (or almost equal) to the real time. I > > guess I can correct it by changing the value of 'dt' (e.g. 'dt=0.0001' > > instead > > of the default 'dt=0.008'), but then the autopilot cannot hold the > > altitude > > and always crashes :( > > ... interesting ... > > > Maybe someone can help me. It should not be that difficult, as FlightGear > > already does it (with 't' or 'T' you can change the speed of the time). > > Yes, this would probably be a simple change. It would involve creating a > timing loop in > JSBSim.cpp (for the standalone version), so that the FGFDMExec::Run() method > would be > called at the same rate as the "dt" value - in this case, at 120 Hz (0.008333 > seconds per > "frame"). > > Now that you bring this up, it sounds like a good option to have for the > standalone > version. That is, there could be an option: > > ./jsbsim --script=scripts/c1723.xml --realtime > > or, the script itself could specify "realtime" as an XML directive. > > I see a problem, though, because it is very OS-dependent. A Mac, a PC running > Linux, > Cygwin, Windows, and IRIX, etc. all will do timing differently. Yet, as you > mention, > FlightGear seems to do it OK. > > Any comments from anyone else? > > Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AS350B3 helicopter lands on Mt. Everest peak
OK, who's going to model an AS350B3? :-) http://www.eurocopter.com/publications/FO/scripts/newsFO_complet.php?lang=EN&news_id=317 m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Backing out Andy's p51d changes
Jim Wilson wrote: > The problem with putting the turbo multiplier up in that range > is the manifold pressure output is directly multiplied by that > number. So full throttle produces an output of 164 inHG > manifold pressure. We should be seeing about 61 inHG at sea > level for this engine. But that's irrelevant: at sea level the wastegate setting* (or boost input, see below) should be clamping it. In order to reach the POH MP numbers at altitude, where the solution values are specified, you need this value. If you want to use a lower than real-life MP, you will need to re-specify the cruise parameters to an altitude where the engine is developing real-life power. > Setting this multiplier lower to get the correct manifold > pressure with turbo at sea level should reduce the maximum > flight level for the aircraft since the second stage turbo > cannot currently be modeled. What's wrong with the BOOST control input for this purpose? The second stage turbine is a manual level. Just map the first stage to a boost of 0.5 (or whatever is appropriate). > If there is a problem that setting the multiplier to 5.5 fixes, > I suspect it is in the FDM design and not the P51D > configuration. Any ideas how we can fix or work around this? I'm just trying to reach the manifold pressures that the airplane is specified as reaching in its POH. What values are you using for cruise MP? Seriously: the supercharger in the Mustang *does* multiply the manifold pressure by this value. Are you sure it doesn't? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Backing out Andy's p51d changes
I wrote: > at sea level the wastegate setting* Sorry, forgot to write this note to go with that asterix: * Superchargers don't have wastegates, of course. Instead, their behavior is generally an altitude-independent mapping of RPM to manifold pressure added to ambient. But the wastegate setting is a relatively sane way to get the same effect. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Backing out Andy's p51d changes
> From: Andy Ross > > I wrote: > > at sea level the wastegate setting* > > Sorry, forgot to write this note to go with that asterix: > > * Superchargers don't have wastegates, of course. Instead, their > behavior is generally an altitude-independent mapping of RPM to > manifold pressure added to ambient. But the wastegate setting is a > relatively sane way to get the same effect. > Yes that makes sense, and actually this is what I remember from the original setup I did on that aircraft. But somehow I don't think it worked in terms of correctly approximating low end performance. We can try though with a 0.4 or whatever BOOST multiplier. The thing I'm wondering though is if the wastegate is working, why was the output 164 inHG at full throttle? It seems as though this used to work. Are the wastegate units inches of mercury? Thanks, Jim P.S. Any chance someone good with nasal could write me a quick script for changing the BOOST value to 1.0 at 20,000FT ASL and then back to 0.4 at 19,999.99FT? I'd try and figure it out, but my time is very limited right now. tia ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Backing out Andy's p51d changes
Jim Wilson > > From: Andy Ross > > > > I wrote: > > > at sea level the wastegate setting* > > > > Sorry, forgot to write this note to go with that asterix: > > > > * Superchargers don't have wastegates, of course. Instead, their > > behavior is generally an altitude-independent mapping of RPM to > > manifold pressure added to ambient. But the wastegate setting is a > > relatively sane way to get the same effect. > > > > Yes that makes sense, and actually this is what I remember from the > original setup I did on that aircraft. But somehow I don't think it > worked in terms of correctly approximating low end performance. We can > try though with a 0.4 or whatever BOOST multiplier. > > The thing I'm wondering though is if the wastegate is working, why was > the output 164 inHG at full throttle? It seems as though this used to > work. Are the wastegate units inches of mercury? > The wastegate is working - the bug already reported is that the displayed value in the property tree is taken before the wastegate code is applied. This is quite useful when developing, because it is possible to check that the supercharger output is reasonable. Anyway, my earlier diff retained that while adding boost readouts post wastegate. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Anyone likes helping with italian scenery?
C'è qualcuno che vuole contribuire a migliorare gli scenari del territorio italiano? Io mi stò divertendo con FGSD, i risultati li potete vedere all'indirizzo http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html . Anyone wants to help bringing a new feeling to visual flights over italian territory? I am having fun building the scenery around my town with FlightGear Scenery Designer; the results can be seen at http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html Roberto -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] .ac file format
I want to build a 3d model, and am finding the available tools difficult for my particular application. Since I know the geometry of the aircraft model I want to create, I think it might be easier to build the file myself. Is there a specification somewhere that describes how to construct a .ac file? Is this a FlightGear-specific format, or some kind of generic 3d model format? Thanks, Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: .ac file format
Never mind...I found it. http://www.ac3d.org/ac3d/man/ac3dfileformat.html On 5/25/05, Drew <[EMAIL PROTECTED]> wrote: > I want to build a 3d model, and am finding the available tools > difficult for my particular application. Since I know the geometry of > the aircraft model I want to create, I think it might be easier to > build the file myself. > > Is there a specification somewhere that describes how to construct a > .ac file? Is this a FlightGear-specific format, or some kind of > generic 3d model format? > > Thanks, > Drew > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: .ac file format
* Drew -- Wednesday 25 May 2005 17:46: > Is there a specification somewhere that describes how to construct a > .ac file? Is this a FlightGear-specific format, or some kind of > generic 3d model format? Google is your friend: http://www.google.com/search?q=ac3d+format No, it's not fgfs specific. It's the default format of the ac3d program. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Colditz Glider MkII
Folks: As most of you know, I've recently been working on a FDM for the Colditz Glider. I was surprised and encouraged by the amount of comment that the original thread generated. I've not been sitting still, and have now got a second version that you may like to play with: ftp://tallyho.bc.nu/pub/steve/flightgear/colditz_20050525.tgz Changes are as follows: After *much* grovelling the net, I eventually discovered a reputable claim (from Michael Selig at UIUC) that the Colditz Glider used the classic 1930's "Clark YH" wing profile. This ties up with a comment from P.Reid's "The Latter Days at Colditz" to the effect that the bottom surface of the wing was flat (most of it is indeed flat in the Clark YH). So I went looking for lift and drag coefficients for the Clark YH, and found them after a long search in a tutorial document on the web originating from Strathclyde University in Scotland. The new Colditz Glider FDM now uses these stated figures for the Clark YH, and though I don't have proper stall hysteresis figures for that wing, it seems almost impossible to fly the Colditz Glider model so that the airfoil actually does stall anyway. As airspeed decreases, the glider just loses lift to the point of mushing through the air below about 32 knots. With the machine flying normally, its best-case rate of descent is about 4 or 5 ft/sec, agreeing fairly well with the estimates of the original designers in Colditz. Likewise, its glide ratio is about 18:1 as estimated by the pilot who flew the replica in 1999 or 2000. I've adjusted my estimate of the locations of the CG and locations of the pilot and passenger after measuring around the reproduction of the original plans. I've played with (but commented out) an attempt to model the launch catapult with a very short-lived rocket engine. Basically, I need a rocket with a burn-time of 2.2 seconds and a thrust of 1866N (that's about 420 pounds in Flintstones units). However, my attempts have failed so far. Suggestions welcome. For instance, what are the units of fuel capacity for the tanks and fuel usage for the engine? [ Presumably tank capacity is in American Gallons or maybe "Barrels", and fuel usage is in Bushels per Nanofortnight, eh? :-) No chance of litres per second or cubic metres per second around here I suppose? ). The next version might even include a 3D model. Josh Babcock is working on one right now. Thanks, Josh. Whatever - enjoy escaping from Colditz. You should be able to make the intended landing site on the far side of the Mulde from the castle roof with height to spare if the prisoners' estimated distance to that landing site was right. Does anyone here actually live in or near Colditz? Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Quoting Roberto Inzerillo : > C'è qualcuno che vuole contribuire a migliorare gli scenari del territorio > italiano? Io mi stò divertendo con FGSD, i risultati li potete vedere > all'indirizzo http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html . > > Anyone wants to help bringing a new feeling to visual flights over italian > territory? I am having fun building the scenery around my town with > FlightGear Scenery Designer; the results can be seen at > http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html This is very impressive. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Colditz Glider MkII
Steve Hosgood wrote: > Does anyone here actually live in or near Colditz? Our long-time "Getting Started" manual maintainer Michal Basler lives in that region. BTW, I don't remember if these URL's have already been mentioned: http://www.pbs.org/wgbh/nova/naziprison/glider.html http://www.colditz-4c.com/glider-l.jpe Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On Tuesday 24 May 2005 18:32, Erik Hofman wrote: > Durk Talsma wrote: > > Maybe this is a good time time to formulate a though I've had for some > > time now: With rumours of a possible 1.0.0 version sometime in 2005, I > > don't think it's a good time to start digging into the basic architecture > > of FlightGear. However, once version 1.0 is out, wouldn't that be an > > excellent opportunity to carefully scrutinize the core architecture of > > FlightGear and redesign it with the goal of ruducing interdependencies, > > memory requirements, and improving startup time? > > I've been working on this regularly the in the past. It's not easy and I > doubt it will gain much. > > However, I think the current airport reading code is just a mixture of > code from the past adopted to read the new data. So it could be the code > currently is reading one file more than once ... > Erik, you are of course in a far better position to judge this than me. As far as I know, though there still seem to be a few design issues with the FlightGear architecture that have evolved into what they are today, yet being slightly less than ideal. For example, back in January (Jan 16) David Luff and I descussed dependencies and counter dependencies on location, weather, wind and location. I also seem to remember a similar depency and counter dependency between startup location, time, and sun position. Another issue that has been brought up a number of times is the ascii vs binary file format disussion. While I absolutely believe that ascii/xml files are ideal for development work, combined they may have a pretty big impact on loading time. Therefore, would it be an idea to 'precompile' the .xml files and use a binary version during runtime? I'm personally considering doing this for the trafficManager files, because the parsing, initialization, and checking against unknown airports is taking huge amounts of time. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
40 seconds for CVS vesion on Dell (laptop) running Linux Fedora Core 2, 1.6 GHz processor, 2 GB RAM. I can live with that. Mike --- Frederic Bouvier <[EMAIL PROTECTED]> wrote: > It takes 23 seconds to start my build on an amd64 > 3400, 1Gb ram. > > -Fred > > Drew a écrit : > > >I'm compiling a Release build. It takes me a bit > under a minute to > >bring it up, which isn't as bad as the 5 minutes > Vivian reported, but > >it's still longer than I'd like (and longer than I > believe is > >necessary). I'll see what I can do about disabling > navaids...that > >seems like it be a lot of help. I haven't found a > property in > >preferences.xml or a command-line option for this, > yet. > > > >Drew > > > >On 5/24/05, Frederic Bouvier <[EMAIL PROTECTED]> > wrote: > > > > > >>Drew a écrit : > >> > >> > >> > >>>FlightGear takes nearly a minute to start up from > my Windows build, > >>>and I'm just wondering if there's an easy way to > shorten this if I'm > >>>not using all of flightgear's features. Is there > one particular task > >>>that takes particularly long? > >>> > >>> > >>> > >>> > >>Do you use the Debug or the Release build ? > >>MSVC 7.x adds a lot of debug code in memory > management (assertion check, > >>corrupted heap) that makes the Debug build > **very** slow. > >>The Release build, as in the official win32 > releases, is way faster. > >>Maybe 5x to 10x. > >> > >>-Fred > >> > >> > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > __ Yahoo! Mail Stay connected, organized, and protected. Take the tour: http://tour.mail.yahoo.com/mailtour.html ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
> Von: Frederic Bouvier <[EMAIL PROTECTED]> > > Anyone wants to help bringing a new feeling to visual flights over > > italian > > territory? I am having fun building the scenery around my town with > > FlightGear Scenery Designer; the results can be seen at > > http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html > > This is very impressive. > > -Fred Fred is always very nice :-) Thx Roberto -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] .ac file format
> Is there a specification somewhere that describes how to construct a > .ac file? Is this a FlightGear-specific format, or some kind of > generic 3d model format? .ac file format is not specific to FG. You can use AC3D (I am pretty shure you already know that) for creating the file. Roberto -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Materials animation bug
> From: Melchior FRANZ > > * Jim Wilson -- Wednesday 25 May 2005 01:44: > > It looks like setting up a materials animation with emission values clobers > > the ambient values (sets them all to 0). This produces some pretty strange > > looking shading. > > BTW: you don't need several material animations with lists of s. > Just use the same material for all of these objects (or one for all needles, > and one for all faces etc.). Then you can make one animation with > true, > and this will change emission for all objects that share the material. Makes > the animation file less crowded and is faster, too. > Sorry about the report, I'm having trouble keeping up with the devel list reading. I did have your private email in my inbox. And I am aware of the global property. For the most part I am not using multiple materials, and do not want all objects emissive. There is one place (can't remember where) that the global tag is used on the P51D. There should be little difference in the performance since only one callback is generated per object group. BTW, most of those model xml files need to be fixed for grouping order. I'll commit more changes tonight (US time). Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Backing out Andy's p51d changes
> From: "Vivian Meazza" > > Jim wrote > > > Hi Andy, > > > > On the p51d fdm configuration, it looks like the substantial change was > > actually increasing the turbo multiplier from 2.0 to 5.5, and not > > reducing the cruise speed as stated in the CVS log of March 23. The > > cruise speed change does have an effect, but it is fairly small. > > > > The problem with putting the turbo multiplier up in that range is the > > manifold pressure output is directly multiplied by that number. So full > > throttle produces an output of 164 inHG manifold pressure. We should be > > seeing about 61 inHG at sea level for this engine. > > > > Setting this multiplier lower to get the correct manifold pressure with > > turbo at sea level should reduce the maximum flight level for the aircraft > > since the second stage turbo cannot currently be modeled. On the other > > hand, using this lower value should NOT produce incorrect lower altitude > > performance since all the data I'm using is for below the 20,000 ft > > altitude where the second stage kicks in. The drag numbers calculated by > > YASim should be more or less correct up to at least up to 20,000 ft where > > the second stage would be kicking in. > > > > If there is a problem that setting the multiplier to 5.5 fixes, I suspect > > it is in the FDM design and not the P51D configuration. Any ideas how we > > can fix or work around this? > > > > Where do you get your numbers from for the boost? There are some > contemporary figures around for the Rolls Royce built versions of the > Mustang engine which indicate that the turbo multiplier should indeed be > around 5: > > http://www.spitfireperformance.com/jf934climb.jpg > > Otherwise, you won't get the correct high-altitude performance. In the > figure above extrapolate the boost curves back to sea-level, ignoring the > effect of the Boost Controller (aka wastegate), and you will see that 5 is > about right - even a bit more for the later Merlins. Don't forget that us > Brits work in psi gauge, while the ex-colonies work in psi absolute: same > thing +- 1 atmosphere. > > Although there is a bug in the current code which gives an incorrect readout > of boost pressure (I forwarded a correction to Andy some weeks ago), the > existing code gives pretty good results if you plug in the numbers right out > of the book. I have just done it for the Merlin XX and was very impressed by > the accuracy. > > Of course, we still have to model the gear-driven supercharger, but again I > have forwarded some code to Andy which does this. We are still waiting to > finalise some curves to match supercharger output. I've got some good-enough > results here. > Hi Vivian, This sounds very interesting. I think I'll wait and see what Andy does with your patches before "fixing" the P51D again. Thanks, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Materials animation bug
* Jim Wilson -- Wednesday 25 May 2005 21:02: > And I am aware of the global property. Yes, I noticed that you are using it in one case after I had sent that message. > For the most part I am not using multiple materials, and do not want > all objects emissive. [...] There should be little difference in the > performance since only one callback is generated per object group. Agreed. That's another thing that I had missed when I read the cvs logs: that you have all the instruments in separate files. Having one "material" animation in each of them does of course make sense. And actually, it was me who should take the thing more seriously. I had a long list of twenty objects in my bo105 rotor animation. This meant to generate 19 copies of one existing ssgSimpleState, and then to visit each of them periodically. That's nonsnse. Now I ate my own dogfood and there's just one node left that is animated. All other rotor objects automatically adopt the state changes. Thanks to . :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AS350B3 helicopter lands on Mt. Everest peak
Le mercredi 25 mai 2005 à 15:14 +0200, Melchior FRANZ a écrit : > OK, who's going to model an AS350B3? :-) > > > http://www.eurocopter.com/publications/FO/scripts/newsFO_complet.php?lang=EN&news_id=317 > > m. > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > The model is not enough, we need a realistic FDM for it: I have done many simulation with yasim , that FDM suit only for light helicopters. may be with JSBSIM in the future. ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
> > Durk Talsma wrote: > > > > Erik, you are of course in a far better position to judge this than me. As > far > as I know, though there still seem to be a few design issues with the > FlightGear architecture that have evolved into what they are today, yet being > slightly less than ideal. For example, back in January (Jan 16) David Luff > and I descussed dependencies and counter dependencies on location, weather, > wind and location. I also seem to remember a similar depency and counter > dependency between startup location, time, and sun position. > > Another issue that has been brought up a number of times is the ascii vs > binary file format disussion. While I absolutely believe that ascii/xml files > are ideal for development work, combined they may have a pretty big impact on > loading time. Therefore, would it be an idea to 'precompile' the .xml files > and use a binary version during runtime? I'm personally considering doing > this for the trafficManager files, because the parsing, initialization, and > checking against unknown airports is taking huge amounts of time. > > Cheers, > Durk > > I am, mainly a user. I do like fgfs, because of, direct access to data and parameters. <===It is not a game==> The idea to precompile xml goes against that concept. I think: on the game side, it is existing many others products which could answer to "quick startup" and answer the players needs (products mainly closed) We can accept a delay when loading (the performance depends on the hard and soft configuration). -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3 USB Joysticks CH
Hi, as far as I know, they are not supported by the standard kernel. I am using the 2.4.27 and I have had the same problem. You have to apply a patch. Look at this http://baron.flightgear.org/pipermail/flightgear-users/2003-January/003401.html and this http://www.qbik.ch/usb/devices/showdev.php?id=211 With the patch everything works great Kind regards Hans-Georg Luuk van Hal wrote: I'm still using Red Hat 8.0 on kernel 2.4.24 with 3 joysticks from CH products on a Sweex usb 2.0 hub. /usr/src/make xconfig support for usb (usbcore.o) -- Y Preliminary USB device filesystem -- Y EHCI HCD -- Y UHCI alternate driver (JE) -- Y USB full HID support -- Y HID Input layer support -- Y Input core support -- Y Joystick support -- Y lsmod: Module Size Used by rtnet 53768 0 rtai_rtdm 12900 0 [rtnet] rtai_shm 7368 0 (unused) rtai_fifos 17672 0 (unused) rtai_sched_up 48241 0 [rtnet rtai_rtdm] rtai 39616 2 [rtnet rtai_rtdm rtai_shm rtai_fifos rtai_sched_up] 3c59x 29552 1 mousedev 5492 1 dmesg | grep usb: usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb.c: new USB bus registered, assigned bus number 1 usb.c: new USB bus registered, assigned bus number 2 usb.c: new USB bus registered, assigned bus number 3 usb.c: new USB bus registered, assigned bus number 4 usb.c: new USB bus registered, assigned bus number 5 usb.c: registered new driver hid input: USB HID v1.00 Joystick [CH PRODUCTS CH PRO PEDALS USB ] on usb1:3.0 input: USB HID v1.00 Joystick [CH PRODUCTS CH THROTTLE QUADRANT] on usb1:4.0 input: USB HID v1.00 Joystick [CH PRODUCTS CH FLIGHT SIM YOKE USB ] on usb1:5.0 So far so good, I would say ...BUT ...this is the output of js_demo: Joystick test program. ~~ Joystick 0 not detected Joystick 1 not detected Joystick 2 not detected Joystick 3 not detected Joystick 4 not detected Joystick 5 not detected Joystick 6 not detected Joystick 7 not detected I've tried every possible combination of modules concerning usb and joysticks but I can't get any of the USB joysticks to work. Can someone tell me why these joysticks don't work while they are installed correctly. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] working with the property tree
I need to learn how to work with the property tree in flightgear. Could someone refer me to material that might be helpful? Thanks! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Roberto Inzerillo wrote : Von: Frederic Bouvier <[EMAIL PROTECTED]> Anyone wants to help bringing a new feeling to visual flights over italian territory? I am having fun building the scenery around my town with FlightGear Scenery Designer; the results can be seen at http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html This is very impressive. -Fred Fred is always very nice :-) Thx Roberto No kidding, you are the first to show a convincing scenery enhancement without using photo-scenery. Generic textures are not dead ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Le mercredi 25 mai 2005 à 20:56 +0200, Roberto Inzerillo a écrit : > > Von: Frederic Bouvier <[EMAIL PROTECTED]> > > > Anyone wants to help bringing a new feeling to visual flights over > > > italian > > > territory? I am having fun building the scenery around my town with > > > FlightGear Scenery Designer; the results can be seen at > > > http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html > > Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Gerard ROBIN a écrit : Le mercredi 25 mai 2005 à 20:56 +0200, Roberto Inzerillo a écrit : Von: Frederic Bouvier <[EMAIL PROTECTED]> Anyone wants to help bringing a new feeling to visual flights over italian territory? I am having fun building the scenery around my town with FlightGear Scenery Designer; the results can be seen at http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. It is tricky but doable. Look at the release notes of version 0.3.0 on sourceforge ( click on the version in the file page ) BTW : Martin contributed an IRIX build -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery size constraints
Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. What I think I've learned so far from debugging: 1.) The FGFS FGBinObj reads with no errors. 2.) The access violation occurs during leaf generation. 3.) The breakage occurs shortly after the texture coordinate index exceeds the max value of a short (32767) and goes negative. 4.) The symbols (e.g., tris_tc) that carry the read-in indices are of type int 5.) Examination of the TerraGear bin writes, and the FGFS reads reveal the indices are stored as short types. 6.) So, my conclusion is the scenery of the 1-arcsec tile is limited to 32767 nodes. (or maybe polygons?) And, TerraGear will truncate any index above that when writing to the binary file. I'm a newbie to TerraGear/FGFS details, so please correct me if I'm wrong about any of this. I would appreciate any comments on what mess might result from any attempt to store/read ints, rather than shorts, to expand the scenery resolution. From a performance standpoint, the capacity of the short type may far exceed anything practical at the present time. Comments on that aspect are welcome, too. Thanks!! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Le mercredi 25 mai 2005 à 23:31 +0200, Frederic Bouvier a écrit : > > > > > > > > It is tricky but doable. Look at the release notes of version 0.3.0 on > sourceforge ( click on the version in the file page ) > BTW : Martin contributed an IRIX build > > -Fred > > > OK i tried it without success (both 2.3 and 3.) I have errors during compilation. But we are on "fgfs-devel mailing" and it is not the good media to discuss about FGSD difficulties. > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Gerard ROBIN wrote: > You where using FGSD, does it mean you are working on windows. > because on the linux side i could never make a compilation of that > program. Try the current release. It even compiles on IRIX (with a bit of tweaking) so you should not get into big trouble on Linux, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Tuesday 24 May 2005 22:14, Martin Spott wrote: > Wesley Alden Pegden wrote: > > glxgears gives me 700fps (as good as it's ever given me), > > [...] > > With a working OpenGL/DRI setup you typically get far more > than 1000 fps with 'glxgears'. Please run 'glxinfo' or > 'gl-info' - whatever you have on your machine - and have a > closer look at the OpenGL 'vendor', > > Martin. I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting < 1fps. Same with the heli & chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to < 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - > 20 fps, shift-6 < 1 fps, shift-3 > 20 fps. From 2 through to 8 are all < 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - > 20 fps. Try chase view and < 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to > 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at > 20 fps but then it dropped back down to < 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives > 3900 fps here. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiled terragear
Dear list members, I would like to show functions of flightgear and terragear to my boss. I have succeeded to compile flightgear, but not terragear. There is no problem with plib, metakit and openal, but I have add some constants (M_LN2, M_PI, M_E) for simgear and still got 16 errors with model.cxx. I have sent an e-mail to terragear-devel mailing list, but got nothing as answer. So I sent another mail to simgear mailing list, but I got a message to send my problem to flightgear mailing list. I have got flightgear-devel mailing list archives, but there are a lot of file to check for similar errors, and I do not have enough time. That is why, I would like to get windows compiled version of terragear. Best regards... Ayhan TEKGUL ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AS350B3 helicopter lands on Mt. Everest peak
Gerard ROBIN wrote: > Le mercredi 25 mai 2005 à 15:14 +0200, Melchior FRANZ a écrit : > >>OK, who's going to model an AS350B3? :-) >> >> >> http://www.eurocopter.com/publications/FO/scripts/newsFO_complet.php?lang=EN&news_id=317 >> >>m. >> >>___ >>Flightgear-devel mailing list >>Flightgear-devel@flightgear.org >>http://mail.flightgear.org/mailman/listinfo/flightgear-devel >>2f585eeea02e2c79d7b1d8c4963bae2d >> > > > The model is not enough, we need a realistic FDM for it: > > I have done many simulation with yasim , that FDM suit only for light > helicopters. > may be with JSBSIM in the future. ? > > Well, I have the EC-135 on my short list, but I have to finish the Colditz, the Superfortress and another surprise I'm working on. I also want to do a Mosquito and a B-47 first. A 350 should be nice though, I see more and more of those things every day. It's the new Jet Ranger. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery size constraints
Alberico, James F wrote: Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. What I think I've learned so far from debugging: 1.) The FGFS FGBinObj reads with no errors. 2.) The access violation occurs during leaf generation. 3.) The breakage occurs shortly after the texture coordinate index exceeds the max value of a short (32767) and goes negative. 4.) The symbols (e.g., tris_tc) that carry the read-in indices are of type int 5.) Examination of the TerraGear bin writes, and the FGFS reads reveal the indices are stored as short types. 6.) So, my conclusion is the scenery of the 1-arcsec tile is limited to 32767 nodes. (or maybe polygons?) And, TerraGear will truncate any index above that when writing to the binary file. I'm a newbie to TerraGear/FGFS details, so please correct me if I'm wrong about any of this. I would appreciate any comments on what mess might result from any attempt to store/read ints, rather than shorts, to expand the scenery resolution. From a performance standpoint, the capacity of the short type may far exceed anything practical at the present time. Comments on that aspect are welcome, too. Thanks!! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. But I am wondering if you won't have problem when rendering, isn't there an hardware limite on the number of tris we can send to glDrawElements and glDrawArrays in the plib code ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiled terragear
� wrote: Dear list members, I would like to show functions of flightgear and terragear to my boss. I have succeeded to compile flightgear, but not terragear. There is no problem with plib, metakit and openal, but I have add some constants (M_LN2, M_PI, M_E) for simgear and still got 16 errors with model.cxx. I have sent an e-mail to terragear-devel mailing list, but got nothing as answer. So I sent another mail to simgear mailing list, but I got a message to send my problem to flightgear mailing list. I have got flightgear-devel mailing list archives, but there are a lot of file to check for similar errors, and I do not have enough time. That is why, I would like to get windows compiled version of terragear. Best regards... Ayhan TEKGUL ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I can be a pain to compile some source with VS6. If Fred does not have the binaries you could try with the VC7 compiler freely available from the microsoft site. After installation you just change the path to executable, include and lib and you use it in VS6 like the old compiler. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: On Tuesday 24 May 2005 22:14, Martin Spott wrote: Wesley Alden Pegden wrote: glxgears gives me 700fps (as good as it's ever given me), [...] With a working OpenGL/DRI setup you typically get far more than 1000 fps with 'glxgears'. Please run 'glxinfo' or 'gl-info' - whatever you have on your machine - and have a closer look at the OpenGL 'vendor', Martin. I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting < 1fps. Same with the heli & chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to < 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - > 20 fps, shift-6 < 1 fps, shift-3 > 20 fps. From 2 through to 8 are all < 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - > 20 fps. Try chase view and < 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to > 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at > 20 fps but then it dropped back down to < 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives > 3900 fps here. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I have also 1fps, but that's with enhanced runway lighting at night ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AS350B3 helicopter lands on Mt. Everest peak
Le mercredi 25 mai 2005 à 18:38 -0400, Josh Babcock a écrit : > > Well, I have the EC-135 on my short list, but I have to finish the > Colditz, the Superfortress and another surprise I'm working on. I also > want to do a Mosquito and a B-47 first. A 350 should be nice though, I > see more and more of those things every day. It's the new Jet Ranger. > > Josh > We have seen your B29 Beta version, it is a beautiful project. And now we are waiting for the stable version. In spite of the history of the B29 which is not glorious (Hiroshima..) > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FDM freeze
Lately I've been flying around German terrain and have been getting an FDM freeze at seemingly random occasions after flying for ten minutes or so. Here's a screenshot of the freeze: http://home.comcast.net/~davidculp2/fdm_freeze.jpg The user airplane is frozen, but other things keep running fine. The AI aircraft keep going, as does the clock, frame rate, GUI, key bindings, mouse. It looks like just the FDM froze. Anyone else getting this? BTW, the HUD lat/lon *never* matches the "actual" lat/lon, so I don't think that has anything to do with it. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
Le mercredi 25 mai 2005 à 19:56 -0500, Dave Culp a écrit : > Lately I've been flying around German terrain and have been getting an FDM > freeze at seemingly random occasions after flying for ten minutes or so. > Here's a screenshot of the freeze: > >http://home.comcast.net/~davidculp2/fdm_freeze.jpg > > The user airplane is frozen, but other things keep running fine. The AI > aircraft keep going, as does the clock, frame rate, GUI, key bindings, mouse. > > It looks like just the FDM froze. Anyone else getting this? > > BTW, the HUD lat/lon *never* matches the "actual" lat/lon, so I don't think > that has anything to do with it. > > Dave > > ___ That happen often for me with message on the console: FGInterface is beeing called without scenery below the aircraf -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FDM freeze
> Lately I've been flying around German terrain and have been getting an FDM > freeze at seemingly random occasions after flying for ten minutes or so. > Here's a screenshot of the freeze: > >http://home.comcast.net/~davidculp2/fdm_freeze.jpg > > The user airplane is frozen, but other things keep running fine. The AI > aircraft keep going, as does the clock, frame rate, GUI, key bindings, mouse. > It looks like just the FDM froze. Anyone else getting this? Any correspondence with a single FDM? If it's JSBSim you might see if data is being logged first. Maybe there's a limit being reached. Otherwise, maybe the data log would shed some light on what is happening. The plane flies along just fine? Then, jsut freezes? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
> That happen often for me with message on the console: > >FGInterface is beeing called without scenery below the aircraf What logging level did you use? --log-level=? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting < 1fps. Same with the heli & chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to < 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - > 20 fps, shift-6 < 1 fps, shift-3 > 20 fps. From 2 through to 8 are all < 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - > 20 fps. Try chase view and < 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to > 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at > 20 fps but then it dropped back down to < 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives > 3900 fps here. LeeE I get this problem also with any of the Nvidia Linux 7xxx drivers. Other programs like torcs still run fine, only fgfs seems to be affected. I used to get 30 to 40 fps at KSFO. If I look down at the cockpit (still at KSFO) or up at the sky or I look to the right more than about 15 degrees or to the left at about 90 degrees it runs at normal speed. Look straight ahead and I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AS350B3 helicopter lands on Mt. Everest peak
Gerard ROBIN wrote: > Le mercredi 25 mai 2005 à 18:38 -0400, Josh Babcock a écrit : > > >>Well, I have the EC-135 on my short list, but I have to finish the >>Colditz, the Superfortress and another surprise I'm working on. I also >>want to do a Mosquito and a B-47 first. A 350 should be nice though, I >>see more and more of those things every day. It's the new Jet Ranger. >> >>Josh >> > > We have seen your B29 Beta version, it is a beautiful project. > And now we are waiting for the stable version. > In spite of the history of the B29 which is not glorious > (Hiroshima..) > Sadly, the 29 is waiting for a stable version of my machine. I have not been able to run fgfs for a while, it doesn't seem to find all the OpenGL calls it needs. Everything else works fine, and I just did a clean install of all the X stuff on my machine. I am wondering if I don't have a hardware problem. The only thing left to try is a clean install, which I haven't had time for yet. I've been working on it for two years, so in the big scheme of things it isn't a huge deal, but I was closing in on a release. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
I tried log-level=info and flew around Sembach until it happened again. Here's some console output: ... prepare_ground_cache(): ac radius = 11.7738, # leafs = 0, ground_radius = 0 prepare_ground_cache(): trying to build cache without any scenery below the aircraft FGInterface is beeing called without scenery below the aircraft! Updating Sun position Gst = 19.2257 t->cur_time = 1043061518 Sun Geodetic lat = -0.351757 Geocentric lat = -0.34959 sun angle relative to current location = 1.21658 Updating Moon position t->cur_time = 1043061518 Moon Geodetic lat = 0.307437 Geocentric lat = 0.305505 moon angle relative to current location = 1.86307 Updating light parameters. Sun angle = 69.7049 ambient = 0.2 diffuse = 0.977531 specular = 0.5 sky = 0.962797 prepare_ground_cache(): ac radius = 23.2997, # leafs = 0, ground_radius = 0 prepare_ground_cache(): trying to build cache without any scenery below the aircraft FGInterface is beeing called without scenery below the aircraft! ... I've heard others talk of this problem, but this is the first time I've seen it myself. Could it be the European terrain data resolution versus U.S. terrain data resolution? Anyway, it would seem that a fix would be to keep a copy of the last tile info, and if no tile is found on the next update then the last one can be used until a new one appears. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
> prepare_ground_cache(): ac radius = 11.7738, # leafs = 0, ground_radius = 0 > prepare_ground_cache(): trying to build cache without any scenery below the > aircraft > FGInterface is beeing called without scenery below the aircraft! The last line comes from JSBSim.cxx line 425, inside the function FGJSBsim::update(). If there is a ground cache problem then the function returns without ever calling copy_to_JSBsim() or copy_from_JSBsim(). That would explain the freeze. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Gerard ROBIN writes: > > > > Durk Talsma wrote: > > >> > > Another issue that has been brought up a number of times is the ascii vs > > binary file format disussion. While I absolutely believe that ascii/xml > > files > > are ideal for development work, combined they may have a pretty big impact > > on > > loading time. Therefore, would it be an idea to 'precompile' the .xml files > > and use a binary version during runtime? I'm personally considering doing > > this for the trafficManager files, because the parsing, initialization, and > > checking against unknown airports is taking huge amounts of time. > > > > Cheers, > > Durk > > > > > I am, mainly a user. > I do like fgfs, because of, direct access to data and parameters. > <===It is not a game==> > The idea to precompile xml goes against that concept. > > I think: > on the game side, it is existing many others products which could answer > to "quick startup" and answer the players needs (products mainly > closed) > > We can accept a delay when loading (the performance depends on the hard > and soft configuration). http://baron.flightgear.org/pipermail/flightgear-devel/2003-September/021434.html I don't see the XML files as being any different then any other source file and source code needs to be compiled. Thaks for bringing this up again :-) Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
* Dave Culp -- Thursday 26 May 2005 02:56:
> The user airplane is frozen, but other things keep running fine. The AI
> aircraft keep going, as does the clock, frame rate, GUI, key bindings, mouse.
>
> It looks like just the FDM froze. Anyone else getting this?
Yes. If it's the same that I got regularly when landing on KSFO/R28. The reason
turned out to be a beacon that the object database weirdly put shortly before
the runway. One had to overfly it. I talked with Mathias and we know now that
this is a bug in the ground cache code. The quite expensive beacon made the
ground cache too busy for too long (dt raised for FGInterface::_calc_multiloop
which results in a big "multiloop" value), and when the ground cache handler was
finally done, it had to catch up a lot of passed scenery, which made
dt/multiloop
even higher etc. It's positive feedback and basically keeps the FDM in a sort of
endless loop. Mathias is working on it. And I worked around it for now:
(1) I removed the beacon (which is silly there, anyway). It wouldn't stand there
longer than a day in real life. But the hang also happened on other places,
so:
(2) I don't allow multiloop to become higher than, currently, 80.
diff -u -p -r1.20 flight.cxx
--- flight.cxx 22 Nov 2004 10:10:33 - 1.20
+++ flight.cxx 26 May 2005 05:07:44 -
@@ -83,7 +83,13 @@ FGInterface::_calc_multiloop (double dt)
// ... ok, two times the roundoff to have enough room.
int multiloop = int(floor(ml * (1.0 + 2.0*DBL_EPSILON)));
remainder = (ml - multiloop) / hz;
- return (multiloop * speedup);
+
+ int result = multiloop * speedup;
+ if (result > 80) {
+ fprintf(stderr, "\033[31;1m_calc_multiloop=%d\033[m\n", result);
+ return 80;
+ }
+ return result;
}
This "fixed" the problem for me, and outputs some red warnings once in a while.
Sometimes it reports really big values (several thousands).
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Gerard ROBIN ha scritto: http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. That's right. But I don't like it very much. I'm just to lazy to compile all that stuff (FGFS + FGSD + Related libs) under Linux. It is a long time ago i wondered to make sceneries of France in Provence. You will need some time :-) But it pays. Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Frederic Bouvier ha scritto: Roberto Inzerillo wrote : Fred is always very nice :-) Thx Roberto No kidding, you are the first to show a convincing scenery enhancement without using photo-scenery. Generic textures are not dead ;-) Well, of course I choose to start with default textures but I'm not happy with that as you are. Those pictures you've seen are taken far distant from the coast line; you don't get the same good impression when you fly right on top of the city. Anyway, I think that basic scenery for Italy is very low quality, it's based on very low resolution data sets, roads are very approximate, land usage is not coherent with today real status. I guess this problem is related to almost every country outside USA. That's why, after having some fun with 3d modelling (i did some building and I'm currently concentrating on a few historical buildings of my town ... that's really very fun :-) I did come to spend some time with terrain modelling. I thought having a good terrain data set was to be done _before_ inserting any 3d object. Now I'm almost done with my town, I will upload the modified scenery files and some tips on importing that into the base fgfs data tree (there are many people who just want to know which file they need and where to copy, without warring about the details, so I'll try to be simple and clear with that). Photo-scenery are still what I'd love to have, I hope FGSD will have the right tools for that in a near future. I like fgsd (with all it's imperfections) and it looks like it's development is taking new directions (as you can read in the FGSD CVS mailing list). We'll see :-) Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
