Re: [Flightgear-devel] Java FlightGear airport viewer (very alpha)
On 10/12/03 at 6:03 PM David Megginson wrote: I've been hacking around with Java Swing classes during free moments over the Canadian Thanksgiving weekend, and I have managed to come up with a minimally-used FlightGear airport viewer. I'm using JDK 1.4, but 1.3 might work as well (if it has the Java2D graphics API bundled). To try it out, follow these steps: snip I'm going to try to make this into a proper editor, but for now, it just makes for a cute, minimalist viewer. I'll package up the source code when I have time -- so far, it's not commented or even sorted into packages. Neat! However, I'll see your Java airport viewer and raise you a C++ one :-) www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0-preAlpha-w32bin.zip - Windows Binary (statically linked) [266K] www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p0-preAlpha-src.tar.gz - Source [34K]. 'make' should compile it cleanly on Linux if you apt-get install wxGTK-devel first. (I used version 2.4.0). Can't be any worse than having to download the Backdown jre ;-)) I was hoping to statically link it and have a Linux binary as well, but it appears there might be, urm, 'issues', related to statically linking to GTK. Needs runways.dat in working directory. Use 'LoadRawAirport' menu entry and enter ICAO code. F4/F5 zoom in/out, arrows pan. j/k rotate all taxiways (not runways). d/f/r/c translate all taxiways. w writes out all taxiways in FG format to ICAO.dat. Try it on KSQL. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I am new here/ helicopter flight model
Hi, now I understand my problem. 1.) the rotations specified in the bo105.xml are done bottom to top (not a big problem, but surprising) 2.) if you rotate more than one object in rotation, than these objects seem to be grouped, so that if you want to rotate a single object of this group in another rotation all objects are rotated. I wanted to do the rotation for the incidence first and then the one for the flapping angle, both for every blade separately. In a last step I wanted to rotate the head and the 4 blades with one single rotation around the rotor mast. This last rotation is now separated in 5 single rotations and everything works :-) Maik Melchior FRANZ schrieb: On Tue, Oct 07, 2003 at 07:21:45PM +0200, Erik Hofman wrote: Since Melchior is away for some time [...] Yeah. Military exercises out in the woods ... I'll be back ... in about a week. :-) I did look at the animation file and it looks like he didn't add animation for separate blades yet. Yes, rotor is just the rotor head, and each blade is a separate object. I thought about animating the blade twist, but this can be changed at any time. Just don't tweak the ac model too much, because the master file is in Blender format! Animation of the whole rotor disc can and will be done. I'd also like to have the blades bended down if they stand still and building a disc at higher rotational speeds, similar to the Wright Flyer wings. But I need glass and at least rudimentary interior first, so that the Bo isn't transparent from inside. m. ___ 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] IMMERSIVE HELMET implementation.....HELP ME!
[EMAIL PROTECTED] writes: Can youu answer some of my question about the code, dave.. But for the future if I will be albe to afford the time to learn some driver programming I could try it. We take mouse input from GLUT and handle it in src/Input/input.cxx. Take a look at the method FGInput::doMouseClick() for details. For the moments, to embed the helmet view, i need to write thirty-forty lines od code, I don't think it is so simple to write a driver Is this a helmet you made yourself, or one you bought? If it's one you bought, and has a USB connection, then it probably already works with the Linux hid driver (and thus, the plib Joystick library). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Java FlightGear airport viewer (very alpha)
David Luff writes: However, I'll see your Java airport viewer and raise you a C++ one :-) Excellent -- I'll take a look. Do you plan to make it into a full-fledged editor, like the one in XPlane? I've had a lot of fun learning the Java2D API for my Java viewer, but I won't go through all the work needed to support creating and dragging around runways and taxiways if you're already planning to do it in C++. Thanks, and all the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] that ssgStripify fix
Could someone running plib cvs submit a patch for this? For now, I don't
believe we need to make this adjustable. Maybe the 1U=parsec people would
want to do so, but it is safe to say that the 0.01f value would already be a
worse problem there.
In src/ssg/ssgOptimiser.cxx, line 29:
static float optimise_vtol [3] =
{
- 0.01f, /* DISTANCE_SLOP = One centimeter */
+ 0.001f, /* DISTANCE_SLOP = One millimeter */
0.04f, /* COLOUR_SLOP = Four percent */
0.004f, /* TEXCOORD_SLOP = One texel on a 256 map */
} ;
Thanks,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Java FlightGear airport viewer (very alpha)
On 10/13/03 at 9:33 AM David Megginson wrote: David Luff writes: However, I'll see your Java airport viewer and raise you a C++ one :-) Excellent -- I'll take a look. Do you plan to make it into a full-fledged editor, like the one in XPlane? I've had a lot of fun learning the Java2D API for my Java viewer, but I won't go through all the work needed to support creating and dragging around runways and taxiways if you're already planning to do it in C++. Hey, a bit of friendly competition was meant to spur you to greater heights, not bin it :-) It was originally intended (and is intended primarily) as a facilities editor similar to afcad - to edit the logical networks, parking places, circuit directions, that sort of stuff. However, it seemed pretty reasonable to add simple taxiway / runway editing to it since I'm visualising them anyway. I'm not familiar with the X-plane editor, but yes, I'm planning on enabling editing of individual X-plane type taxiways and runways (centre, length, heading) with the mouse and keyboard. Not at an individual scenery polygon level though - I'll leave that to fgsd. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I am new here/ helicopter flight model
Hello, I've mailed the source and the files needed for using this with Melchiors Bo105 to Erik, Curt, David and Jim. It should be easily included to the actual source files. It is fully compatible to the old yasim. The simulation parameters are not optimized, but the flight behavior should be similar to the real one. In the next days I will try to optimize the settings for the bo105 and to write a file similar to the Jet Ranger (not the 3D, just the flight model), and a file for a chinook like helicopter (both not optimized (missing data), just to demonstrate how to). And I will start to clean the code, and to comment it. The flight model is not finished yet, but works quite nice. All the best Maik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFD: Proposed Changes to Airport Data Files
I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Comments? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On 10/13/03 at 5:12 PM David Megginson wrote: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) Agree whole-heartedly with this. Things like frequency lookup can then have a nice world-map downwards clickable interface. 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Comments? I think we have to be very careful about how much data we store globally. FG has a pretty large memory footprint - I've just fired a non-debug version up and it clocks 360Meg of RAM. Really, only airports and frequencies must be stored in memory ready for use, since that is what we look up by. We could load runways on demand when the airport is known. The disadvantage being that the runways come prepackaged in the current format. I propose adding an xml facilities file for each airport with custom data that isn't needed all the time - an extended version of what Bernie's taxiway editor puts out with logical taxiways, gates, circuit direction, vfr reporting points, noise reduction regs, preferred calm rwy etc - all the stuff that is going to have to rely on users entering it since there's no central database, and a lot of it stuff that can fall back to sensible defaults. I would be very tempted to put tower and windsock in here as well, unless you know of a large database of such values. It's also confused by the fact that you probably want to render them based on that info, and would prefer one file for Terragear input? I'd also be tempted to put runways in the per-airport file, to be automatically tar'd up in FG's standard scenery directory format for the program to find, but suspect that Curt will be sending this to dev/null about now :-) A few other points - how about splitting the world-wide databases into 2 - with the split down the atlantic and down between Alaska and Siberia. Loading the other database into memory at 3 over the ocean probably wouldn't be noticed, and key Greenland etc VORs could be duplicated. Also - the taxiways really don't need to be in runways.dat - they're only used for rendering (Terragear) and slow up the loading of FG. Remember that loading text files is much slower on Windows than Linux. It would be better to split out the taxiways into taxiways.dat.gz and ship it with the base for reference but not load it IMHO. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Am Montag, 13. Oktober 2003 23:12 schrieb David Megginson: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) I agree with that. Especially because such an airport dialoge is an important feature for a flightsim and still missing in flightgear. Maybe we should also think about adding another entry, the continent. If we want to use a search by continent feature in the airport dialog, then of course, it is possible to find the continents by country. But history showed that this is not a reliable value. For example 15 years ago, you could say that the UDSSR is more in Asia instead of Europe, but when you would check for the moscow airport your programm would assume asia because of UDSSR=Asia, but that's wrong because, moscow is still in Europe. So, that's why an additional entry for continents would be probably wise. If we want to save space, we could save a number instead of the continent name and assign the appropriate name when the aiport dialog is started. Here's my proposal for the a number continent table: 1 Europe 2 Asia 3 Africa 4 Middle America 5 North America 6 South America 7 Australia So instead of: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This one: A KSFO 37.618763 -122.37492613 5 US CA CYN San Francisco Intl Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
David Megginson wrote: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl It seems *awfully* redundant given that there is already the Id *and* the geographical location. I have difficulty imagining that a high enough proportion of these will be determined and maintained to make it worthwhile. I do see why you want it though, and agree it would be nice to be able to get a list of airports in my region, by name of region rather than by lat/lon. This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Yep, lovely. Those two look good to me. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On Tue, 14 Oct 2003, David Luff wrote: Agree whole-heartedly with this. Things like frequency lookup can then have a nice world-map downwards clickable interface. Yes, it's a small addition, with obvious benefits. I think we have to be very careful about how much data we store globally. FG has a pretty large memory footprint - I've just fired a non-debug version up and it clocks 360Meg of RAM. Really, only airports and frequencies must be stored in memory ready for use, since that is what we look up by. We could load runways on demand when the airport is known. The disadvantage being that the runways come prepackaged in the current format. Splitting the info only required at scenery generation time out into a seperate file has to be a good thing - as you say, the footprint of flightgear is growing - its pointless holding redundant data in RAM. I propose adding an xml facilities file for each airport with custom data that isn't needed all the time - an extended version of what Bernie's taxiway editor puts out with logical taxiways, gates, circuit direction, vfr reporting points, noise reduction regs, preferred calm rwy etc - all the stuff that is going to have to rely on users entering it since there's no central database, and a lot of it stuff that can fall back to sensible defaults. I would be very tempted to put tower and windsock in here as well, unless you know of a large database of such values. It's also confused by the fact that you probably want to render them based on that info, and would prefer one file for Terragear input? I'd also be tempted to put runways in the per-airport file, to be automatically tar'd up in FG's standard scenery directory format for the program to find, but suspect that Curt will be sending this to dev/null about now :-) A few other points - how about splitting the world-wide databases into 2 - with the split down the atlantic and down between Alaska and Siberia. Loading the other database into memory at 3 over the ocean probably wouldn't be noticed, and key Greenland etc VORs could be duplicated. Does it buy you much if you're going to have to load both if someone searches for an entry anyway? Also - the taxiways really don't need to be in runways.dat - they're only used for rendering (Terragear) and slow up the loading of FG. Remember that loading text files is much slower on Windows than Linux. It would be better to split out the taxiways into taxiways.dat.gz and ship it with the base for reference but not load it IMHO. I was going to suggest moving all the supplementary data to this file too, but then it occurred to me that not all of it is used simply for building scenery - things like windsock info would be fine - as it can be placed when the airport tile is built, but things like circuit and logical taxiway data are required at runtime, so we'd be dragging all the redundant baggage along too. Moving all supplemental airport data to a per airport file would make sense, although it will require changes to terragear for building the airports. If it's done right though it should allow easy expansion of airport facilities. As David said, XML may be the way to go. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
On Tue, 14 Oct 2003, Julian Foad wrote: It seems *awfully* redundant given that there is already the Id *and* the geographical location. I have difficulty imagining that a high enough proportion of these will be determined and maintained to make it worthwhile. I do see why you want it though, and agree it would be nice to be able to get a list of airports in my region, by name of region rather than by lat/lon. It's awfully time consuming to determine the continents on the fly though, rather than simply searching for a particular key. Yep, lovely. Those two look good to me. The problem there is that we don't need to keep a list of windsock locations in RAM all the time. *YES* we need the data - I'm just not convinced that that's the place to put it. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
[EMAIL PROTECTED] writes: Maybe we should also think about adding another entry, the continent. If we want to use a search by continent feature in the airport dialog, then of course, it is possible to find the continents by country. But history showed that this is not a reliable value. For example 15 years ago, you could say that the UDSSR is more in Asia instead of Europe, but when you would check for the moscow airport your programm would assume asia because of UDSSR=Asia, but that's wrong because, moscow is still in Europe. For the very few countries that straddle continents, like the Russian Republic or Turkey (any others?), the region/state code will (hopefully) be adequate to make the distinction. If there are 10 or 20 airports that are still ambiguous because of states/regions that also straddle continents, we could put them into a special-case table if necessary. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Jon Stockill writes: The problem there is that we don't need to keep a list of windsock locations in RAM all the time. *YES* we need the data - I'm just not convinced that that's the place to put it. There's no need to load it into RAM in FlightGear -- TerraGear can use the information, and FlightGear can simply skip over it (as it does with taxiways, I hope). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
David Megginson writes: Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. I hope that this data base is stored in XYZ form and not lat lon else any optimizations you make by spatial partitioning will be nullified by the trig calls required to get distances Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
