Re: PLIB on AIX; Was: [Flightgear-devel] FlightGear 'benchmark'
Martin Spott wrote: anyone be so kind to look at the patch and give a suggestion how to deal/proceed with these changes ? Just be very persistent, state clearly this patch is needed for AIX before a new stable release is scheduled. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficGear?
On 2/24/04 at 9:41 PM Durk Talsma wrote: On Tuesday 24 February 2004 20:44, Erik Hofman wrote: It is supported for airports that have ATC (sorry no AI traffic at EHLE). But indeed Eelde has ATC support and therefore can handle ATC traffic at the moment. Cool! Wasn't Lelystad supposed to get ATC real soon about two years ago? I haven't been there since returning home last December, so I don't know what the situation is. I have followed an AI Cessna once but I lost in when it literally flew through a mountain, so I guess it is distance limited. Hmm, I see. So that's a little too much emhasis on the A and a bit too less on the I part in AI, I guess :-). [Ironically, this reminds me that IIRC, one of the original design goals of FlightGear (in 1996-1997 or so) was to develop a realistic ATC subsystem that does take terrain elevation into account and not direct planes into mountains. ;-) Anyways, I'm just kidding. Nothing but compliments here. This is hard stuff to impliment.] Seriously though, so I understand that AI planes take-off and depart to undefined destinations or do they return? I couldn't really figure this out based on the code? Maybe I should follow a chessna taking off from Eelde, was there's not much chance of one of those crashing into a mountain. :-) The code to generate the random AI lives in AIMgr.cxx in the ATC directory. At the moment they get generated between 6 and 25km or so from the airport and then arrive and land, either staight-in or via a downwind entry depending on direction of approach w.r.t. the active runway. They're a bit hard to follow at the moment since at one point in the flight they suddenly change direction without banking to approach the airport, I'll try and fix that ASAP. You should be able to hear them more easily than seeing them if you tune your comm radio to the tower frequency. Having departures that persist if you follow them and have an eventual destination in mind if they don't get deleted due to distance from user is definately on the TODO list. Avoiding mountains would be good - I was wondering when someone was going to notice that :-) I have given this some thought, but haven't started implementing anything yet since it could turn out to be a long slog to get something working. My guess is that the best thing to do is to have a coarse elevation map for each tile stored as a file on disk in the appropriate part of the scenery tree, and to use these to avoid terrain. The maps could include hints as to the best option to take in very mountainous areas where certain paths need to be taken to avoid the need to exceed GA type max altitudes. Getting AI traffic to work at non-towered airports shouldn't be too hard - mainly a case of altering the communication to announcing position on the common traffic frequency, and possibly running a dummy tower that doesn't communicate for the positional stuff. (At the moment stuff like whether to extend downwind for due to preceding traffic is handled by the tower class). There are loads of issues to gradually iron out - only one runway ever gets used, AI traffic on a downwind circuit approach can conflict with AI traffic or the user on a straight-in, AI traffic too close to the preceding in the circuit doesn't slow down, the user can get overtaken on either straight in or circuit approach, no facility for user to request an alternate runway from ATC, loads of stuff. Robin Peel already has air corridors (airways) data for X-Plane which probably could be used by FlightGear as well. I think it is DAFIF(T) based so we can generate them ourselves also. That's interesting. I was always curious whether an airways database for flightgear existed or not. It would be an interesting exersize to plot these in Atlas, as this would be a good start to generate flight plans. In general I've been trying to do GA VFR type ATC and AI first, which leaves a big hole where airline type IFR stuff is basically not there. It would be good if the user could fly a simple flight plan in the 737 with ATC control from tower/departure/center/approach/tower the whole way. It would be good if an AI plane could do the same. It's probably a lot of work though to get working well for high traffic densities, but possibly not too bad for the odd one or two planes to start with. My thoughts were that an FGVectoringATC class derived from FGATC would know how to vector traffic appropriately along paths, and that FGApproach, FGCenter (En-route) and FGDeparture would be derived from that. In addition to Atlas, there is also another open-source flight planner for MSFS, called 'Nav'. It's written in MFC for windows only, but I was wondering how much work it would be to port to wxWindows and convert to reading FlightGear data. Probably a lot and not much respectively. Give me a shout if you're going to seriously hack at the ATC/AI code so we don't end up duplicating... Cheers - Dave PS. Did you ever finish your
Re: [Flightgear-devel] TrafficGear?
On 2/24/04 at 8:44 PM Erik Hofman wrote: I have followed an AI Cessna once but I lost in when it literally flew through a mountain, so I guess it is distance limited. Well that's just great, the first person to notice that AI planes fly though mountains comes from Holland!!! ;-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficGear?
David Luff wrote: On 2/24/04 at 8:44 PM Erik Hofman wrote: I have followed an AI Cessna once but I lost in when it literally flew through a mountain, so I guess it is distance limited. Well that's just great, the first person to notice that AI planes fly though mountains comes from Holland!!! ;-) Ever been to the Dutch Mountains? :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficGear?
Erik Hofman wrote: David Luff wrote: On 2/24/04 at 8:44 PM Erik Hofman wrote: I have followed an AI Cessna once but I lost in when it literally flew through a mountain, so I guess it is distance limited. Well that's just great, the first person to notice that AI planes fly though mountains comes from Holland!!! ;-) Ever been to the Dutch Mountains? :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Hey, when you fly below sea level, you're bound to be the first person to notice the mountain. Altitude is for wimps. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgDumpSnapShot(); producing blank screen and other corruptions
I am currently using the main thread and it is producing these incorrect images. I have not even multithreaded it yet. When I do I will only be threading the writting of the image. Seamus On Wed, 25 Feb 2004, Frederic Bouvier wrote: Seamus Thomas Carroll wrote: Hi, I am trying to save images from flightgear to a file or database without explicitly using the gui. For a test of current capability I am calling fgDumpSnapShot every second but I am finding it produces saved images that are completely white or contain corruption, yet other images are saved as expected. The only change I mode to fgDumpSnapShot is I commented out mkDialog (message.c_str());. I am trying to implement a threaded image saver so that it does not cause pauses in the simulator that continiously saves images over a specified interval. If you are doing snapshot in another thread, you must be sure that the buffer you are dumping is not being cleared, swapped or written at the same time by the main thread. Generally, people think it is not possible to call OpenGL API from multiple thread at the same time because of the state oriented nature of OpenGL. The arguments seem reasonable and I take them for true, so I never experiment myself. In theory, it should be possible to dump the front buffer while the back buffer is updated, but fgDumpSnapShot should be rewriten to avoid calling fgInitVisual, fgReshape or fgRenderFrame in two different threads. This imply also some sort of synchronization to avoid doing a SwapBuffer during the ReadPixels call. I think I understand how fgDumpSnapShot works and was going to use it as an example but it only seems to produce correct results when called through the gui. Yes, in the main thread. Should I be using another funtion as an example? I would look at sg_glDumpWindow and take the code portion that write to the file from fgDumpSnapShot. -Fred ___ 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] TrafficGear?
On Wednesday 25 February 2004 00:28, David Megginson wrote: In other words, while the air carrier thing is neat, it's probably not the first priority -- it would be like concentrating on busses or tractor trailers instead of cars when adding AI traffic to a highway simulator. The air carriers would be beneficial for a few big hubs like KLAX or KORD, which don't handle much GA traffic. That's a very valid point. The idea wouldn't be to just concentrate on airline schedules though. My estimate is that from an implementation point of view, that adding scheduled airline type traffic and general aviation types of traffic (that go from A to B) would be special instances of a similar general mechanism. I.e. A scheduled airline flight has: - A predetermined departure airport - A predetermined arrival airport - A known aircraft type. - A known departure time Whereas an (unscheduled) general aviation flight has - a (semi) random departure airport - a (semi) random port of arrival - a (semi) random aircraft type - a (semi) random departure time So starting with scheduled airlines would probably be the easiest instance to implement, and -also not unimportantly- test. This mechanism could then later be extended to handle the other types of air traffic you mentioned. Also note that I don't intend this as a replacement for David (Luff)'s code, but more of a way of feeding data into David's AI manager. When I was testing some of the project AI stuff last Saturday, I was on a rather long flight from Amsterdam into eastern Europe, and there was a Speedbird 850 (British Airways), behind me, that was coming onto my frequency, just a few minutes behind me and stayed right behind me until over Warsaw, Poland. Curiously, I checked the BA website for the whereabouts of their flight 850, and found that indeed in real life this was a scheduled flight from London (Heathrow, I believe) to Warsaw. It's very subtle, but it was an imcredable experience. Today I flew up to Mont Tremblant (CYFJ), a former military strip near a ski resort in the Laurentians. There are a few scheduled flights every week from Toronto (Dash-7), but today the terminal was shut down. I got out and walked around the deserted apron for a few moments, then as I was taxiing back to the runway, the airport suddenly came to life: a Piper Cub on skis glided across in front of me and landed on the snow next to the pavement (didn't make any radio calls, though). By the time I got to the hold-short line, a Cessna 180 (tail dragger) was doing a slow backtrack to my end of the runway, so I waited for it, and when I realized that it was doing its runup on the threshold, I checked with the pilot if it was OK for me to slip in ahead and take off. That's what most airports -- at least in Canada and the U.S. -- are like, and that's what it would be very nice to simulate. Unfortunately, all the general public sees is flying at its most depressing -- the giant, congested hubs with airliners doing a long conga-line down the ILS while people sit in the terminal waiting hours for delayed flights and having their shoes searched repeatedly by security. Aahh, that really sounds like a lot of fun. I agree, we should definitely have scenarios like these. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficGear?
On Wednesday 25 February 2004 11:17, David Luff wrote: The code to generate the random AI lives in AIMgr.cxx in the ATC directory. At the moment they get generated between 6 and 25km or so from the airport and then arrive and land, either staight-in or via a downwind entry depending on direction of approach w.r.t. the active runway. They're a bit hard to follow at the moment since at one point in the flight they suddenly change direction without banking to approach the airport, I'll try and fix that ASAP. You should be able to hear them more easily than seeing them if you tune your comm radio to the tower frequency. I'll had a quick glance at the code yesterday, but couldn't really figure out how it worked, given the time I had. So do you consider generating AI traffic that starts on the ground (i.e. parked at the terminal/apron/gate)? In addition to Atlas, there is also another open-source flight planner for MSFS, called 'Nav'. It's written in MFC for windows only, but I was wondering how much work it would be to port to wxWindows and convert to reading FlightGear data. Probably a lot and not much respectively. Sounds interesting. The fact that' its written in MSVC is a big showstopper for me though, as I'm only using gcc these days Give me a shout if you're going to seriously hack at the ATC/AI code so we don't end up duplicating... Yep, will do. I'm thinking about approaching the problem from the other end though. First specify the requirements of the database that stores flight plans and then find a way to feed these data into the AI traffic manager, _in addition_ to the randomly generated flights. Cheers - Dave PS. Did you ever finish your round the world FG flight? Hmm, do you mean in FlightGear, or in real life? :-) The answers are no and yes respectively. My FlightGear flights ended ion Hokkaido Island, after running out of fuel over the pacific, hacking a saved flight, restarting (this was already before we had a public interface to the property tree) to refuel, and still making it. This was around the time of defending my dissertation, after which I soon left Amsterdam for a two year stay in Durham, North Carolina. During my time in the USA, I only had one laptop at home, which was slightly under powered for FlightGear, and I also found out that I wasn't able to edit my homepage from a domain other than that of my ISP. In the meantime, my ISP has taken that site off-line, so consequently the project slowly died. I'd like to see if I can find some notes somewhere, so I can pick-up where I left off. But if not, I'll call it a day. In real life, however, after my two years in Durham, I left North Carolina, driving cross-country to Davis, California (with a few huge detours, including Cape Canaveral, Houston, TX, New Mexico, Aspen, Colorado; Yellowstone Park, Salt lake city and southern Utah. In Davis, I took the train to San Fransisco, and from there I flew to Honolulu, to Auckland, New Zealand (via Sydney), to Canberra, Australia, to Alice Springs, to Darwin (all in Australia), and from there to Singapore, to Hong Kong, to Delhi (India) to Cairo (Egypt; via Bahrain, and Abu Dhabi). And finally from Cario to London, and from London to Amsterdam, where I arrived back, November 30th, last year. So, if you're interested in recreating these Flights in FG, you need (hint, hint) :-) - a British Airways 737 (Amsterdam - London Gatwick) - an American Airlines 777 (London Gatwick - Raleigh Durham Intl) - an American Airlines 767 (San Fransisco - Honolulu) - a Qantas Airways 767 (Honolulu - Sydney, Sydney Auckland, Auckland Sydney) - a Qantaslink Dehavilland Dash-8 (Sydney - Canberra, and Canberra Sydney: three weeks later - a Qantas 737: Sydney Alice Springs, and Alice Springs - Darwin) - again a Qantas 767 (Darwin - Singapore) - a Cathay Pacific Airbus A330 (Singapore - Hong Kong and Hong Kong - Delhi) - a Gulf air Airbus A330 (Delhi, Bahrain, Bahrain - Abu Dhabi, and Abu Dhabi - Cairo) - a British Airways 747-400 (Cairo - London Heathrow) - and finally, a British Airways Airbus A319 Anyways, I'm going off topic here. Time to quit, Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgDumpSnapShot();
I tried calling sg_glDumpWindow directly and so far I have not experienced the white out but I am noticing at times what looks like smearing and other corruption but the flightgear display does not show any of these problems. My knowledge of gl is limited but it confuses me that flightgear looks correct but the screen shot saved by sg_glDumpWindow does not. Are they not from the same buffer? You can find an example screen shot with corruption at http://pages.cpsc.ucalgary.ca/~carrolls/ppm/fgfs-screen---00075.jpeg Seamus On Wed, 25 Feb 2004, Martin Spott wrote: Seamus Thomas Carroll wrote: I am trying to save images from flightgear to a file or database without explicitly using the gui. For a test of current capability I am calling fgDumpSnapShot every second but I am finding it produces saved images that are completely white or contain corruption, yet other images are saved as expected. I usually use 'import' from the ImageMagick package to create snapshots and I experienced similar effects. That _might_ let us assume that taking a snapshot simply takes too much time and the respective buffer - the one where the snapshot is taken from - is already eptied before the snapshot is complete, 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. Thanks Josh At 07:57 PM 2/23/2004, you wrote: Joshua W. Keane said: Hello everyone, I'm working on a simulation project using a simulink model. Currently, I'm running an interface using the Aerosim blockset for matlab/simulink, but the program steps/chops, especially when the sun/moon position is updated (and when other info is output to the cmd window). I'm currently running both on a single computer, but this computer is a pretty high-end machine. So the question really is: can I stop those updates from occuring, or should I just try using a network with 2 computers? Another thing i've seen is the fact that after a minute of running my simulation, the simulation suddenly turns to night. Can anyone tell me why this is? and how can I stop it from occuring? One last thing: there is a command to do not advance time of day (--enable-clock-freeze) and if i've read the documentation correctly, this should keep the time of day constant while letting the simulation run, right? But when I go and set that - it pauses the simulation and i can not do anything. Do i have the wrong idea about this? I would guess that the effect you are seeing is actually from loading scenery data. Have you built flightgear configured --with-threads? The turning to night sounds like an old bug that has been fixed in CVS. My guess is that the --enable-clock-freeze issue you describe is a bug. Same thing happens here. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Joshua William Keane George Washington University Graduate Student Vehicle Dynamics Branch NASA Langley Research Center Hampton, VA 23681 Mail Stop 153 Phone: (757) 864-9636 Fax: (757) 864-7722 Email: [EMAIL PROTECTED] Office: Bldg 1192C, Room 159 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: PLIB on AIX; Was: [Flightgear-devel] FlightGear 'benchmark'
Erik wrote: Just be very persistent, state clearly this patch is needed for AIX before a new stable release is scheduled. Steve has committed them already. Erik Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TrafficGear?
On 2/25/04 at 8:34 PM Durk Talsma wrote: On Wednesday 25 February 2004 11:17, David Luff wrote: In addition to Atlas, there is also another open-source flight planner for MSFS, called 'Nav'. It's written in MFC for windows only, but I was wondering how much work it would be to port to wxWindows and convert to reading FlightGear data. Probably a lot and not much respectively. Sounds interesting. The fact that' its written in MSVC is a big showstopper for me though, as I'm only using gcc these days Short of time, so I'll answer the rest of your post tomorrow, but on this one MSVC/mfc shouldn't be a problem - wxWindows is a cross platform mfc 'clone' (OK, not literally a clone, but very similar) that'll compile fine with gcc. On the other hand, I'm sure porting a non-trivial program is still quite time consuming, especially as all the dialogs would have to be recreated from scratch. (wxWindows uses a more flexible mechanism to cope with the differing sized widgets from GTK to Win32 (and others)). I spent a good few hours on it a few months ago, and now it doesn't compile on either!! Still hopefull though :-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 'benchmark'
I would be very interested to know how many polygons per second FGFS is rendering. Do you have a ballpark number? It might be nice to have several sections of the benchmark and in one try to maximize poly count of the scene and minimize all else. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Joshua W. Keane wrote: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. It should also be working with the latest version of FlightGear. And if they patched FlightGear to support their software they *must* send you the source at your request (GPL compatibility). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Stepping and other inquisitions
Joshua W. Keane said: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. That's an old version. One thing that might help if you can't upgrade or compile is increasing the visibility way up (z key), wait a few seconds for Flightgear to load the extra scenery and then decreasing it back down before you take off. This will eliminate the scenery loading for a short period, longer if you don't travel far. Otherwise see about getting an update. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 'benchmark'
Wolfram Kuss wrote: I would be very interested to know how many polygons per second FGFS is rendering. Do you have a ballpark number? Sorry Worfram, I have no idea where I could get that number from. Does FGFS have a debug swicth which activates the display of such a number ? The only thing we know is that high polygon models obviously don't have a noticeable impact on the framerate on the Octane. It might be nice to have several sections of the benchmark and in one try to maximize poly count of the scene and minimize all else. In fact, I did the package primarily to evaluate if it is worth spending the money (I don't have ) for a V8 graphics board for my Octane - now that I've already upgraded CPU, Powersupply, Frontplane and Mainboard. I sort of have an Octane2 now, but the appropriate graphics board is missing. I'm still waiting for someone to show up, calling out that he has a V8 to run that 'benchmark' ;-) If FlightGear has the abilities to display more numbers that just the framerate I'd be happy to extend the package accordingly, 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] Stepping and other inquisitions
Jim Wilson wrote: Joshua W. Keane said: Don't you just hate bugs!? The problem is that i'm using a precompiled or prebuilt version of flightgear, v0.9.2 because it is currently the version supported by the aerosim blockset for matlab/simulink. [...] Otherwise see about getting an update. I got a short reply from them several weeks ago after pointing out that they were using an old version of FGFS. They told me they were not interested in upgrading because they didn't want to track the changes between 0.9.2 and 0.9.3, 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] Stepping and other inquisitions
Martin Spott said: I got a short reply from them several weeks ago after pointing out that they were using an old version of FGFS. They told me they were not interested in upgrading because they didn't want to track the changes between 0.9.2 and 0.9.3, That's understandable but I would think they could have built it with thread support. The lighting bug is just a little annoying. As I type this I just remembered that you can force a lighting update with F4 (not 100% sure that works in 0.92, but it's worth a try). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Another CVS problem
When I do a cvs update -dP on the JSBSim CVS repository I get these errors for the engine/ directory: cvs update: move away engine/propDA-R352_6-123-F_2.xml; it is in the way C engine/propDA-R352_6-123-F_2.xml ... ... If I delete the files, and update again, I get what's in CVS, of course. If I do another cvs update -dp, I get the above errors again. Can anyone tell me what might be the problem with this? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
