Re: [Flightgear-devel] glHorizon
Tony Peden wrote: On Thu, 2003-09-04 at 22:06, Jon Berndt wrote: Did I mention this link yet? http://www.web-discovery.net/ Very cool! Indeed. I knew it exists but didn't know it used JSBSim (or doesn't it?) It looks like a nice simulator, too bad it's Windows only. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
Martin Spott wrote:
"Jon S Berndt" <[EMAIL PROTECTED]> wrote:
Which is better:
awk
gawk
nawk
I think it depends on what platform you are running. The best solution would
be to use 'awk' and stick to the least common denominator in the command
set,
That's what I do:
awk -F';' '{print $1"="$2}' temp.txt > test
Anything fancier is for other tools.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
David Culp schrieb: On a related note, here are some airports that the FAA considers "special", as of 1990, and why: > [...] EUROPEAN REGION AIRPORT COMMENTS Berlin, Germany Political sensitivity of corridor adherence. Thank God that's gone since 1990 (October 3rd to be presice...) [...] WESTERN-PACIFIC REGION AIRPORT COMMENTS Hong Kong Int'l.Special approach; (British Colony, S.E. China)mountainous terrain. That'll be the old Hong Kong Airport. Isn't "special approach" quite an understatement? CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glHorizon
Erik Hofman <[EMAIL PROTECTED]> wrote: > Tony Peden wrote: >> On Thu, 2003-09-04 at 22:06, Jon Berndt wrote: >> >>>Did I mention this link yet? >>> >>>http://www.web-discovery.net/ >> >> >> Very cool! > Indeed. I knew it exists but didn't know it used JSBSim (or doesn't it?) > It looks like a nice simulator, too bad it's Windows only. When he uses parts of JSBSim, then I assume the license is compatible with the GPL. This means, it should be possible to use DFM data, aircraft models, textures and probably scenery rendering alorithms from glHorizon. Right ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] glHorizon
Martin Spott wrote: When he uses parts of JSBSim, then I assume the license is compatible with the GPL. This means, it should be possible to use DFM data, aircraft models, textures and probably scenery rendering algorithms from glHorizon. Right ? Not really. When he uses JSBSim he should make his changes to the code available, should sent the source code to every user who wants it (upon request, but he might ask a fee for it). The same counts for all JSBSim aircraft models he uses. There is no relation between FDM configuration files and 3d models, textures and scenery rendering algorithms provided he didn't use any of that from another GPL'ed program (like FlightGear). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] move in/out
Do we have any move in/out option in FlightGear (in contrast to zoom in/out). If not, is it hard to... :) - Matevz ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery samples
On Thu, 4 Sep 2003, Curtis L. Olson wrote: > Probably worth some screen shots, but it looks nicer when everything > is moving. One thing I should warn people of, with these new tiles, I > kind of screwed up the road/river flattening. I came up with a tweak > to make that look *much* nicer ... crunching data again tonight. Is that in CVS now? (and does it require a tgvpf re-run for the roads, or just a rebuild of the tiles?) > I also added support for displaced thresholds in genapts, so I need to > go through and recrunch those as well. Hopefully Erik can whip up > some appropriate textures for us. Ooooh, nice - looks like my system is gonna be busy again :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery samples
Curtis L. Olson wrote: > I also added support for displaced thresholds in genapts, so I need to > go through and recrunch those as well. Hopefully Erik can whip up > some appropriate textures for us. Nice ! Are displaced threshold on grass runways supported too ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] glHorizon
I think he just used JSBSim to figure out how to write his own EOM. Not sure, though. > Martin Spott wrote: > > > When he uses parts of JSBSim, then I assume the license is > compatible with > > the GPL. This means, it should be possible to use DFM data, > aircraft models, > > textures and probably scenery rendering algorithms from glHorizon. > > > > Right ? > > Not really. > > When he uses JSBSim he should make his changes to the code available, > should sent the source code to every user who wants it (upon request, > but he might ask a fee for it). The same counts for all JSBSim aircraft > models he uses. > > There is no relation between FDM configuration files and 3d models, > textures and scenery rendering algorithms provided he didn't use any of > that from another GPL'ed program (like FlightGear). > > Erik > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery samples
Jon Stockill writes: > On Thu, 4 Sep 2003, Curtis L. Olson wrote: > > > Probably worth some screen shots, but it looks nicer when everything > > is moving. One thing I should warn people of, with these new tiles, I > > kind of screwed up the road/river flattening. I came up with a tweak > > to make that look *much* nicer ... crunching data again tonight. > > Is that in CVS now? (and does it require a tgvpf re-run for the roads, or > just a rebuild of the tiles?) Nothing changed with the tgvpf tool so you just need to rebuild the tiles. > > I also added support for displaced thresholds in genapts, so I need to > > go through and recrunch those as well. Hopefully Erik can whip up > > some appropriate textures for us. > > Ooooh, nice - looks like my system is gonna be busy again :-) Mine too ... :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new scenery samples
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > Anyway, what I have can be found here: > ftp://ftp.flightgear.org/pub/fgfs/Scenery-0.9.2/ Probably it would have been wise to coordinate the rename of the Scenery/ directory, so the ftp mirrors would not have to pull the complete Scenery-0.7.9/ directory from scratch. Outch Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
Tony Peden writes: > I don't know, maybe it's just me but I've written a lot of perl I > couldn't read a month later ... You just haven't rewired your brain chemistry yet. After about 12 years, perl code starts to look normal and everything else (C/C++, the sky, your family) looks strange. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
--- David Megginson <[EMAIL PROTECTED]> wrote: > Tony Peden writes: > > > I don't know, maybe it's just me but I've written a lot of perl I > > couldn't read a month later ... > > You just haven't rewired your brain chemistry yet. After about 12 > years, perl code starts to look normal and everything else (C/C++, > the > sky, your family) looks strange. And you are suggesting that this is a good thing? > > > All the best, > > > David > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
David Megginson wrote: Tony Peden writes: > I don't know, maybe it's just me but I've written a lot of perl I > couldn't read a month later ... You just haven't rewired your brain chemistry yet. After about 12 years, perl code starts to look normal and everything else (C/C++, the sky, your family) looks strange. I can imagine that someone who has twelve kids can understand the beauty of perl ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] move in/out
Matevz Jekovec <[EMAIL PROTECTED]> said: > Do we have any move in/out option in FlightGear (in contrast to zoom > in/out). If not, is it hard to... :) > > > - Matevz Look at the view offset properties (X, Y, and Z). Also, there is a pui dialog that used to be called "pilot offset" (I'm not able to check the name right now). It's still there on the menu somewhere but needs a little work to be really useful in all view modes. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Animation documentation
Hi, Can someone point me to the most recent document that contains information on how to animate FlightGear models? Want to add a description of the new blending animation, but although I found it on three different locations, none of them include the scale animation which Curtis added recently. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Pink plane
The AI plane, which used to be white with N301DP on it, is now appearing pink and featureless. I assume this means that the 'texture not found' texture is being used. The file I'm referencing is "Aircraft/c172/Models/c172-dpm.ac" which exists. Within that directory the correct textures exist. Within c172-dpm.ac itself all the references to the textures are preceded by paths on David's machine - I thought this might be the problem but replacing all instances of texture "/home/david/src/blender/c172-01.rgb" with texture "c172-01.rgb" etc. didn't fix it. Any ideas? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
Erik Hofman <[EMAIL PROTECTED]> wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/fokker50/Models > In directory baron:/tmp/cvs-serv715 > Modified Files: > fokker50.ac fokker50.xml The F-50 has evolved to a really nice aircraft. But there are still a few issues that appear very strange to me: 1.) I need do accelerate the aircraft up to almost 200 knots before I manage to lift the nose. After this is done, the aircraft has an impressive climb rate (well, at over 200 kts ). 2.) The aircraft needs a bit of damping. Every change of a control surface leads to excessive oscillation and it's really hard to get the plane back to straight flight. 3.) I know, you should not employ the flaps at 200 kts But if you do so, the aircraft climbs like attached to a high speed elevator :-) Please remember the standard disclaimer: I don't want to urge anyone to fix this, these notes are only meant as an informal notice and I _assume_ it would be worth fixing before the next release, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
David Megginson <[EMAIL PROTECTED]> said: > Tony Peden writes: > > > I don't know, maybe it's just me but I've written a lot of perl I > > couldn't read a month later ... > > You just haven't rewired your brain chemistry yet. After about 12 > years, perl code starts to look normal and everything else (C/C++, the > sky, your family) looks strange. > Hehe... Well, you know, not being able to read the code a month later could be a good thing. You see, if you are working with one of those slick self documenting Basic derivative or natural/english language derivative or what-ever-is-like-a-cpu-with-esp derivative languages you are able to go back in to the code a year later and easily understand what is going on, apply a quick modification, run a few tests, and deploy all before lunch. Only to find out a week later that a huge bug has been introduced that has left the database hopelessly corrupted and erroneously distributed tens of thousands of dollars in cash to customers. The company goes into Chapter 11 and of course you, the programmer, are now unemployed with a big black splotch on your resume. Since you are now home all the time, your family and the sky, etc., all start to look _really_ familiar. Perl must be better then, since it makes you think about what you are doing, before you do it. :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman <[EMAIL PROTECTED]> said: > Can someone point me to the most recent document that contains > information on how to animate FlightGear models? > > Want to add a description of the new blending animation, but although I > found it on three different locations, none of them include the scale > animation which Curtis added recently. In CVS it's docs/Model/fgfs-model-howto.html. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] scenery update
Ok, my latest beta scenery from last night's build has been uploaded to the main ftp server: ftp://ftp.flightgear.org/pub/fgfs/Scenery-0.9.2/ This build has much better road/river smoothing. The roads no longer carve huge V's into the terrain. I might want to add a bit more smoothing for rivers in the next build, but they aren't too bad. They do run up and down the hills a bit, but in most situations it's not noticable. This motly happens when the river location is very mismatched with SRTM and the river is climbing up and down the canyon sides. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Jim Wilson wrote: Erik Hofman <[EMAIL PROTECTED]> said: Can someone point me to the most recent document that contains information on how to animate FlightGear models? Want to add a description of the new blending animation, but although I found it on three different locations, none of them include the scale animation which Curtis added recently. In CVS it's docs/Model/fgfs-model-howto.html. Thanks. I've found it. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
Martin Spott wrote: The F-50 has evolved to a really nice aircraft. But there are still a few issues that appear very strange to me: 1.) I need do accelerate the aircraft up to almost 200 knots before I manage to lift the nose. After this is done, the aircraft has an impressive climb rate (well, at over 200 kts ). 2.) The aircraft needs a bit of damping. Every change of a control surface leads to excessive oscillation and it's really hard to get the plane back to straight flight. 3.) I know, you should not employ the flaps at 200 kts But if you do so, the aircraft climbs like attached to a high speed elevator :-) Please remember the standard disclaimer: I don't want to urge anyone to fix this, these notes are only meant as an informal notice and I _assume_ it would be worth fixing before the next release, I know it's current limitations. It's still the basic output from aeromatic and needs tweaking. At the moment it is also a testbed for me to test certain changes. Thanks for the list by the way. It makes it easier where to look at :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman writes: > Jim Wilson wrote: > > Erik Hofman <[EMAIL PROTECTED]> said: > > > > > >>Can someone point me to the most recent document that contains > >>information on how to animate FlightGear models? > >> > >>Want to add a description of the new blending animation, but although I > >>found it on three different locations, none of them include the scale > >>animation which Curtis added recently. > > > > > > In CVS it's docs/Model/fgfs-model-howto.html. > > Thanks. I've found it. I wonder if we should call the animation "transparency" instead of "blending", just in case we do add an animation for texture blending later (say, to animate ice accumulating on the airframe). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
On Friday, September 5, 2003, at 03:12 pm, Martin Spott wrote: 3.) I know, you should not employ the flaps at 200 kts But if you do so, the aircraft climbs like attached to a high speed elevator :-) I've been flying the Fokker 100 quite a bit, and I've noticed similar instabilities. Roughly (I am not a pilot) - very rapid control response, especially on the roll axis). This sometimes extends to a 'snap' condition where I command an aileron reversal (okay, I just pull my joystick to the other side), and there is a very prolonged period with no response (for example, 8 or 10 seconds, usually continuing the previous roll command) until the roll suddenly flips over. - a similar elevator effect to that martin described, when deploying the flaps at high speeds - very odd high pitch angle behavior ... I can't really describe it, alas. It seems like way too much lift is getting developed at high angles of attack, without a corresponding increase in drag to slow the aircraft. Essentially, the aircraft flies pretty well (if a bit twitchy) providing you stick to a 'good' flight regime, but handling deteriorates exponentially when I go even moderately beyond it. I'm aware that part of this may be running 'past the end of the data' in JSBsim, but other models do not seem to have these problems. Can this be alleviated by tuning the last data point for various coefficients, which I assume is what JSBsim extrapolates from? (I was about to say the 747 is much more forgiving of my 80-degree banks, but of course, it uses YASim). Anyway, aside from the nit-picking, it's a lovely plane, at least until we get an ERJ ;-) James -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
On Fri, 5 Sep 2003 16:01:59 +0100 James Turner <[EMAIL PROTECTED]> wrote: - a similar elevator effect to that martin described, when deploying the flaps at high speeds - very odd high pitch angle behavior ... I can't really describe it, alas. It seems like way too much lift is getting developed at high angles of attack, without a corresponding increase in drag to slow the aircraft. The aerodynamics will only be as good as the coefficient data that is input. :-) Essentially, the aircraft flies pretty well (if a bit twitchy) providing you stick to a 'good' flight regime, but handling deteriorates exponentially when I go even moderately beyond it. I'm aware that part of this may be running 'past the end of the data' in JSBsim, but other models do not seem to have these problems. Can this be alleviated by tuning the last data point for various coefficients, which I assume is what JSBsim extrapolates from? IIRC, the JSBSim data tables are NOT extrapolated. If you fly in conditions outside envelopes for which there is data IN the tables, you will get the value for a coefficient that corresponds to the most xtreme data point available - but not outside the table (is that clear?). So, the advice is to make sure you have made your tables cover all of the regime you want it to cover - e.g. if your table has alpha as a lookup index, make sure it goes to 90 degrees. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
David Megginson <[EMAIL PROTECTED]> said: > Erik Hofman writes: > > > > > Thanks. I've found it. > > I wonder if we should call the animation "transparency" instead of > "blending", just in case we do add an animation for texture blending > later (say, to animate ice accumulating on the airframe). > Just out of curiosity...what is it being used for? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Jim Wilson wrote: David Megginson <[EMAIL PROTECTED]> said: Erik Hofman writes: > > Thanks. I've found it. I wonder if we should call the animation "transparency" instead of "blending", just in case we do add an animation for texture blending later (say, to animate ice accumulating on the airframe). That might not be a bad idea. I didn't think of that. Just out of curiosity...what is it being used for? It can be used to make the object blend into the scenery. The alpha value of the vertices is adjusted by it. You can see the effect when looking at the propeller disks of the Fokker 50 as you push the throttle, or to see the ufo blend into the scenery as it gains speed. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Jim Wilson wrote: > David Megginson <[EMAIL PROTECTED]> said: > > > Erik Hofman writes: > > > > > > > > Thanks. I've found it. > > > > I wonder if we should call the animation "transparency" instead of > > "blending", just in case we do add an animation for texture blending > > later (say, to animate ice accumulating on the airframe). > > > > Just out of curiosity...what is it being used for? I wonder if it could be used to transition between Level Of Details, in cooperation with the range animation -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
James Turner wrote: I've been flying the Fokker 100 quite a bit, and I've noticed similar instabilities. Roughly (I am not a pilot) - very rapid control response, especially on the roll axis). This sometimes extends to a 'snap' condition where I command an aileron reversal (okay, I just pull my joystick to the other side), and there is a very prolonged period with no response (for example, 8 or 10 seconds, usually continuing the previous roll command) until the roll suddenly flips over. This is also like the Fokker 50, still using the direct output from aeromatic without any modifications. If David manages to create a new version of aeromatic that would make it easy to replace the current version. - a similar elevator effect to that martin described, when deploying the flaps at high speeds - very odd high pitch angle behavior ... I can't really describe it, alas. It seems like way too much lift is getting developed at high angles of attack, without a corresponding increase in drag to slow the aircraft. The Fokker 100 supposedly has a very efficient airfoil (e.g. much lift, low drag) which might add to this a bit, but there is a problem. I guess it's the CG or aero reference point (or both) that needs tweaking. Anyway, aside from the nit-picking, it's a lovely plane, at least until we get an ERJ ;-) Heh :-) Well, no ERJ until someone creates one ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Frederic BOUVIER wrote: I wonder if it could be used to transition between Level Of Details, in cooperation with the range animation It is available as an animation for all models. Keep in mind that when the model is invisible (1.0) it won't be set invisible (culled) by the code yet (which might actually be a good idea now that I think of it). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman wrote: Jim Wilson wrote: David Megginson <[EMAIL PROTECTED]> said: Erik Hofman writes: > > Thanks. I've found it. I wonder if we should call the animation "transparency" instead of "blending", just in case we do add an animation for texture blending later (say, to animate ice accumulating on the airframe). That might not be a bad idea. I didn't think of that. Thinking about it again, all current texture animations start with tex so adding texblend wouldn't be much of a problem. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman wrote: > Frederic BOUVIER wrote: > > > I wonder if it could be used to transition between Level Of Details, in > > cooperation with the range animation > > It is available as an animation for all models. Keep in mind that when > the model is invisible (1.0) it won't be set invisible (culled) by the > code yet (which might actually be a good idea now that I think of it). Yes, but if we want the model fade (in or out) with the distance from the viewer, we will need more than just a property. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Airports basic.dat.gz, 1.2, 1.3
"Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > Update of /var/cvs/FlightGear-0.9/data/Airports > In directory baron:/tmp/cvs-serv7323 > Modified Files: > basic.dat.gz > Log Message: > Updated airport data (including new airports from Robin Peel.) Wohoo, he even includes Chambley Airbase in France. Unfortunately Robin chose 'LFZZ' for airport code, like for two others too. Maybe - Robin, are you reading this list ? - he wants to replace the code with FX01 for Chambley. This is not an official ICAO code, Chambley will never get an official code), but it appears to be unique for Chambley (http://www.fortunecity.com/marina/harbourside/2145/id28_m.htm) Robin, could you tell me the source for your data on this airbase ? The numbers are not the same that I sent to you, so I'd wish to talk to the guy who submitted these numbers. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Frederic BOUVIER wrote: Erik Hofman wrote: Frederic BOUVIER wrote: I wonder if it could be used to transition between Level Of Details, in cooperation with the range animation It is available as an animation for all models. Keep in mind that when the model is invisible (1.0) it won't be set invisible (culled) by the code yet (which might actually be a good idea now that I think of it). Yes, but if we want the model fade (in or out) with the distance from the viewer, we will need more than just a property. True, that makes it harder to implement. But you can use the same code for that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman writes: > Frederic BOUVIER wrote: > > > I wonder if it could be used to transition between Level Of Details, in > > cooperation with the range animation > > It is available as an animation for all models. Keep in mind that when > the model is invisible (1.0) it won't be set invisible (culled) by the > code yet (which might actually be a good idea now that I think of it). It might be late to throw this in, but in opengl, the convention is for 1.0 to be fully opaque and 0.0 to fully transparent. It might be useful to match that from the standpoint of "least surprise." Regards, Curt.-- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Curtis L. Olson wrote: Erik Hofman writes: Frederic BOUVIER wrote: I wonder if it could be used to transition between Level Of Details, in cooperation with the range animation It is available as an animation for all models. Keep in mind that when the model is invisible (1.0) it won't be set invisible (culled) by the code yet (which might actually be a good idea now that I think of it). It might be late to throw this in, but in opengl, the convention is for 1.0 to be fully opaque and 0.0 to fully transparent. It might be useful to match that from the standpoint of "least surprise." This is done deliberately. It is almost impossible to get from RPM=4000 to 0.0 using an offset and a factor. Think of it as a percentage of transparency ranging from 0.0 to 1.0 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman writes: > Curtis L. Olson wrote: > > Erik Hofman writes: > > > >>Frederic BOUVIER wrote: > >> > >> > >>>I wonder if it could be used to transition between Level Of Details, in > >>>cooperation with the range animation > >> > >>It is available as an animation for all models. Keep in mind that when > >>the model is invisible (1.0) it won't be set invisible (culled) by the > >>code yet (which might actually be a good idea now that I think of it). > > > > > > It might be late to throw this in, but in opengl, the convention is > > for 1.0 to be fully opaque and 0.0 to fully transparent. It might be > > useful to match that from the standpoint of "least surprise." > > This is done deliberately. > > It is almost impossible to get from RPM=4000 to 0.0 using an offset and > a factor. Negative factor? > Think of it as a percentage of transparency ranging from 0.0 to 1.0 Sure, it's not that big of deal, but it's just that it is opposite of how OpenGL people are used to thinking about transparency. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Curtis L. Olson wrote: This is done deliberately. It is almost impossible to get from RPM=4000 to 0.0 using an offset and a factor. Negative factor? Ah, I see. This decision is because I started with: alpha = (prop + offset) * factor I used this because the other animations use it also. But for blending it is not a convenient way, hence the change to: alpha = prop * factor + offset. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Erik Hofman writes: > > Curtis L. Olson wrote: > > > Erik Hofman writes: > > > > > >>Frederic BOUVIER wrote: > > >> > > >> > > >>>I wonder if it could be used to transition between Level Of Details, in > > >>>cooperation with the range animation > > >> > > >>It is available as an animation for all models. Keep in mind that when > > >>the model is invisible (1.0) it won't be set invisible (culled) by the > > >>code yet (which might actually be a good idea now that I think of it). > > > > > > > > > It might be late to throw this in, but in opengl, the convention is > > > for 1.0 to be fully opaque and 0.0 to fully transparent. It might be > > > useful to match that from the standpoint of "least surprise." > > > > This is done deliberately. > > > > It is almost impossible to get from RPM=4000 to 0.0 using an offset and > > a factor. > > Negative factor? > > > Think of it as a percentage of transparency ranging from 0.0 to 1.0 > > Sure, it's not that big of deal, but it's just that it is opposite of > how OpenGL people are used to thinking about transparency. H...wish I had my red book with me...but i'm pretty sure that talking about the gl_alpha component of material properties, 1.0 is fully transparent. BTW it'd be nice to have a similar function to adjust the rgb values for luminosity on the flyor even as a single value for brightness (r*n,b*n,g*n). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Jim Wilson <[EMAIL PROTECTED]> said: > H...wish I had my red book with me...but i'm pretty sure that talking > about the gl_alpha component of material properties, 1.0 is fully transparent. U...scratch that...that can't be right. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] data/Aircraft/fokker50/Models
The present Fokker 50 is modeled as a "Transonic Transport" by Aero-Matic, and since no wing area is specified in the inputs, Aero-Matic guessed a wing loading of 110 lb/sq-ft, resulting in an estimated wing area of 399 sq-ft, which is too low. It's best to have Aero-Matic model it as a "Light Twin", and the latest version of Aero-Matic calls this option "Light Twin, Prop Transport" to make it more clear. Aero-Matic will then guess a wing loading of 29 lb/sq-ft, resulting in an estimated wing area of 1517 sq-ft (which is too high). Aero-Matic really needs a separate category for Prop Transports, if for no other reason than to better guess the wing area. The best result now can be obtained from Aero-Matic by calling it a "Light Twin, Prop Transport", and entering the actual wing area of 753.5 sq-ft. The wing loading calculation will then be bypassed, as it is only used for guessing wing area. I don't know if the Fokker 50 has a yaw damper, but the model will fly much better with one, so I recommend using one. It has a mean dutch roll now, which means I need to tweak some coefficients for damper-less airplanes. Also, the Fokker 50 model is using an experimental turbine/prop combination that is putting out too much thrust. If you let Aero-Matic create a 2500 hp turboprop for you, it will fake it with a 4175 lb-thrust turbine, which I think will give a better thrust model, even if it is a fake. -- David Culp [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
On Fri, 05 Sep 2003 10:34:05 +0200, Christian Mayer <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > David Culp schrieb: > > > > On a related note, here are some airports that the FAA considers > > "special", as of 1990, and why: > > > > [...] > > > > EUROPEAN REGION > > > > AIRPORT COMMENTS > > > > Berlin, Germany Political sensitivity > > ofcorridor adherence. > > Thank God that's gone since 1990 (October 3rd to be presice...) ..amen! > > [...] > > > > WESTERN-PACIFIC REGION > > > > AIRPORT COMMENTS > > > > Hong Kong Int'l.Special approach; > > (British Colony, S.E. China)mountainous terrain. > > That'll be the old Hong Kong Airport. Isn't "special approach" quite > an understatement? ..heh, try ENHV. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery update
On Fri, 5 Sep 2003 09:43:34 -0500, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > This build has much better road/river smoothing. The roads no longer > carve huge V's into the terrain. ..some places, like a lot of places in Norway, this is a RL feature, and keeping this code available might be the right thing to model the terrain better. Compile or run time flag? " --norse-roads"? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery update
Curtis L. Olson schrieb: Ok, my latest beta scenery from last night's build has been uploaded to the main ftp server: ftp://ftp.flightgear.org/pub/fgfs/Scenery-0.9.2/ This build has much better road/river smoothing. The roads no longer carve huge V's into the terrain. I might want to add a bit more smoothing for rivers in the next build, but they aren't too bad. They do run up and down the hills a bit, but in most situations it's not noticable. This motly happens when the river location is very mismatched with SRTM and the river is climbing up and down the canyon sides. I'm surprsed how well FGFS looks now (I haven't run it for a while...). Now I tried a flight at Hell's Canyon (see "Places to Fly"). It's a quite amazing scenery. But now to the point that could be done better: 1) The river doesn't allways flow on the lowest point. 2) The trees are too spare. To 1): could we perhaps add an algorithm that checks if there is a local minimum in the DEM next to the river and if there's one displace the river a bit until if flows there? To 2) I don't know how our trees are made up. If they are simple billboards we should be able to increase their number. If they are "real" objects we should try to add billboard support (can't PLIB do that already?) The only problem with billboard-trees is if you look straight down. But there we could define 2 radii 0 < r_1 < r_2 If the tree location is further away than r_1 from the viewer the vertical billboard will be painted. If the tree location is closer than r_2 the horizontal billboard is painted. CU, Christian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery update
Arnt Karlsen wrote: On Fri, 5 Sep 2003 09:43:34 -0500, "Curtis L. Olson" <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: This build has much better road/river smoothing. The roads no longer carve huge V's into the terrain. ..some places, like a lot of places in Norway, this is a RL feature, and keeping this code available might be the right thing to model the terrain better. Compile or run time flag? " --norse-roads"? If this is the case then the SRTM data should take care of that. The only problem are places where tunnels are used. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery update
Christian Mayer wrote: I'm surprsed how well FGFS looks now (I haven't run it for a while...). Now I tried a flight at Hell's Canyon (see "Places to Fly"). It's a quite amazing scenery. But now to the point that could be done better: 1) The river doesn't allways flow on the lowest point. 2) The trees are too spare. To 1): could we perhaps add an algorithm that checks if there is a local minimum in the DEM next to the river and if there's one displace the river a bit until if flows there? To 2) I don't know how our trees are made up. If they are simple billboards we should be able to increase their number. If they are "real" objects we should try to add billboard support (can't PLIB do that already?) They are billboards. But my machine definately can't handle more billboards right now (how does the 3d clouds code do that? I looks like the trees and clouds together doesn't make a hughe difference). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
On Fri, 2003-09-05 at 08:01, James Turner wrote: > On Friday, September 5, 2003, at 03:12 pm, Martin Spott wrote: > > > 3.) I know, you should not employ the flaps at 200 kts > > But if you do so, the aircraft climbs like attached to a high > > speed elevator :-) > > I've been flying the Fokker 100 quite a bit, and I've noticed similar > instabilities. Roughly (I am not a pilot) > > - very rapid control response, especially on the roll axis). This > sometimes extends to a 'snap' condition where I command an aileron > reversal (okay, I just pull my joystick to the other side), and there > is a very prolonged period with no response (for example, 8 or 10 > seconds, usually continuing the previous roll command) until the roll > suddenly flips over. > > - a similar elevator effect to that martin described, when deploying > the flaps at high speeds > - very odd high pitch angle behavior ... I can't really describe it, > alas. It seems like way too much lift is getting developed at high > angles of attack, without a corresponding increase in drag to slow the > aircraft. > > Essentially, the aircraft flies pretty well (if a bit twitchy) > providing you stick to a 'good' flight regime, but handling > deteriorates exponentially when I go even moderately beyond it. I'm > aware that part of this may be running 'past the end of the data' in > JSBsim, but other models do not seem to have these problems. Can this > be alleviated by tuning the last data point for various coefficients, > which I assume is what JSBsim extrapolates from? Just for the record, JSBSim never extrapolates a table and always holds last value. In practice, this can have as bad an effect as extrapolation, but at least we're not making up data as we go along. > > (I was about to say the 747 is much more forgiving of my 80-degree > banks, but of course, it uses YASim). > > Anyway, aside from the nit-picking, it's a lovely plane, at least until > we get an ERJ ;-) > James > > -- > There is a very fine line between 'hobby' and 'mental illness' > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden <[EMAIL PROTECTED]> ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery update
Erik Hofman writes: > They are billboards. But my machine definately can't handle more > billboards right now (how does the 3d clouds code do that? I looks like > the trees and clouds together doesn't make a hughe difference). Imposters might work for distant trees as well. Implementing imposters is beyond my skill, however. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
