Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ [EMAIL PROTECTED] said: Now with a different 'approach'. Starting on ground ... $ fgfs --lon=-122.4998 --lat=37.5845 --heading=275 ... and very slowly taxiing over the border. Right when I pass over I get thrown on my back. Ouch ... :-| That did it. There is definately something at this location, on my display driven by V3-3000 I see a white line (right side of picture): http://www.spiderbark.com/fgfs/SanAndreas.png The AGL glitch you see basically means that there's a hole down there that goes to nowhere, an actual gap between tiles. AGL is determined by intersecting scenery tiles under the aircraft and measuring the distance from the aircraft position. If you cross a gap in the scenery then you'll get those kinds of numbers. On my system the c310 will ride over it (like thumping over a pothole) and the c172 will just drop in there and act crashed. Probably if I hit it at the right angle or speed the c310 would do the same. With a narrow fissure like this (I think) it's possible for the AGL to be momentarily screwed up, the aircraft then drops and a wing tip or nose contact with tile on either side of the gap triggers crash detection. I'm not familiar with the scenery generation, so I can't tell you why the gap is here. When I was working on getting the agl calculation functioning with all the viewer changes, I toyed with the idea doing something that ignored sudden (and/or unreasonable) variations to AGL, at least for a few frames. It was mostly in response to what happens when a very fast aircraft outruns the tile loading, which I decided wasn't a big enough problem to warrant tracking AGL variations. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
When I was working on getting the agl calculation functioning with all the viewer changes, I toyed with the idea doing something that ignored sudden (and/or unreasonable) variations to AGL, at least for a few frames. It was mostly in response to what happens when a very fast aircraft outruns the tile loading, which I decided wasn't a big enough problem to warrant tracking AGL variations. Perhaps that explains the problem I've been seeing. When performing autoland approaches in the 747 (approach speeds around 137-150KIAS) the aircraft would suddenly level off at decision height ( 200 ft) and then dive for the runway as it tried to reacquired the glideslope. At first, I thought it might be a problem in the FMC or some logic error that I created to initiate a TO/GA. Looked and looked and could find nothing, so I dropped it for the moment to work on other things Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
John Wojnaroski [EMAIL PROTECTED] said: Perhaps that explains the problem I've been seeing. When performing autoland approaches in the 747 (approach speeds around 137-150KIAS) the aircraft would suddenly level off at decision height ( 200 ft) and then dive for the runway as it tried to reacquired the glideslope. At first, I thought it might be a problem in the FMC or some logic error that I created to initiate a TO/GA. Looked and looked and could find nothing, so I dropped it for the moment to work on other things That's probably an issue with the autopilot and the 747. It's been difficult finding control factors that work for all the different speeds, compounded by the giant mass of the 747. At those lower speeds the effectiveness of the elevator can change dramatically with relatively small changes in speed. In any case the AGL doesn't affect the autopilot in its normal modes. If you were hearing tire screech at 200ft or it behaved differently depending on the airport, that would be a different story. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Jim Wilson wrote: When I get some time I'll run further tests and maybe come up with a patch to avoid this sort of glitch. It would be helpful if someone happened to know why this gap happens in the scenery data sometimes. I'm sure Curt can talk in more detail, but my guess is that this is going to be very hard to avoid* in the general case. Maybe the best way to do this is to apply some meta-intelligence about the structure of the data. Rather than finding a purely geometic intersection with any polygons that may (or may not!) be there, test each tile individually (with a little guard band around the edge to prevent misses) and select exactly one intersection. [* It's really the same issue as the jitter -- at the scales covered by the terrain tiles, the floats in the vertex coordinates are only accurate to within a few millimeters. Even perfect math will result in cracks. The only way to avoid is would be to find all the duplicated vertices accross tile boundaries and force them to be precicely equal at load-time, which sounds like a pain to me. You can't force them to be precicely equal at generation time because each tile has its own coordinate origin and the equality test needs to happen after they're placed into the same coordinates.] Right now I'm in the middle of moving my own stuff to a new machine with a newer distro, so be a little patient please :-) Heh, join the club; I just bought a new machine too. BTW Anyone have any RH 7.2 suggestions (other than formatting and installing debian)? Any hope for the 2.96 compiler? OT so respond off list. I've been building with the default compiler on 7.2 and 7.3 with no difficulties at all. I think the 2.96 issues were all hammered out during patches to the 7.0 distribution. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Andy Ross writes: Jim Wilson wrote: When I get some time I'll run further tests and maybe come up with a patch to avoid this sort of glitch. It would be helpful if someone happened to know why this gap happens in the scenery data sometimes. I'm sure Curt can talk in more detail, but my guess is that this is going to be very hard to avoid* in the general case. Maybe the best way to do this is to apply some meta-intelligence about the structure of the data. Rather than finding a purely geometic intersection with any polygons that may (or may not!) be there, test each tile individually (with a little guard band around the edge to prevent misses) and select exactly one intersection. [* It's really the same issue as the jitter -- at the scales covered by the terrain tiles, the floats in the vertex coordinates are only accurate to within a few millimeters. Even perfect math will result in cracks. The only way to avoid is would be to find all the duplicated vertices accross tile boundaries and force them to be precicely equal at load-time, which sounds like a pain to me. You can't force them to be precicely equal at generation time because each tile has its own coordinate origin and the equality test needs to happen after they're placed into the same coordinates.] Exactly ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Jim Wilson -- Wednesday 03 July 2002 18:26: Melchior FRANZ [EMAIL PROTECTED] said: A huge value would probably only make the AGL radar flash a wrong value but it wouldn't have further, malign effects. Crash detection is triggered in some cases which will basically shutdown fdm. Any other malign effects? Random plane crashes without obvious reason are certainly not acceptable for a flight simulator. Even more so, if the reason is gaps in the scenery that shouldn't be there in the first place. The gaps aren't really severe and certainly hard to avoid, but I don't see why they should make the plane crash. What would you call malign? If it made your monitor explode? Killed your cat? I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I can't see anything obvious in your system setup that would explain what is happening and why your experience is different from others. When I've been the only one to see weird problems it has often helped to do a complete make clean; make; make install of all the components (plib, simgear, flightgear) with the emphasis on the make clean part first. Sometimes the incremental builds can get slightly hosed for some reason ... you get an executable that links and runs, but does weird things. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
That's probably an issue with the autopilot and the 747. It's been difficult finding control factors that work for all the different speeds, compounded by the giant mass of the 747. At those lower speeds the effectiveness of the elevator can change dramatically with relatively small changes in speed. Errr, I don't think so. Not using the FG autopilot, and I see nothing in my FMC that would send a control command for up elevator. In fact, the FMC continues to issue a reference vertical velocity speed between 720 and 760 fpm descent which is what it was calculating at glideslope capture at the outer marker and during the approach. There is nothing in the way of a control command input, the approach is rock solid both in glideslope and localizer tracking all the down. Plus there's no reason for the aircraft to suddenly pitch up when neither the state or control surface deflections change. In any case the AGL doesn't affect the autopilot in its normal modes. If you were hearing tire screech at 200ft or it behaved differently depending on the airport, that would be a different story. When I have a moment I'll try a few approaches at other airports. Don't have sound enabled. And taker a closer look at a plot of FMC output and control surface movements. I've put this one on the back burner for the moment. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Melchior FRANZ -- Wednesday 03 July 2002 19:41: But I will now eradicate all my object files and make everything clean. Done. Same problem. Unfortunately, I'm neither familiar with the scenery handling, nor with the vector stuff. But I'll try to find out more ... :-/ Can you dump out the ground elevation every frame and see what that does as you fly over a seam and hit the invisible wall? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Curtis L. Olson -- Wednesday 03 July 2002 21:30: Can you dump out the ground elevation every frame and see what that does as you fly over a seam and hit the invisible wall? I did this already and posted the results in this thread. Do you want to see more? A longer period? It would be interesting to also see the actual ground elevation along with the other numbers you posted. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: * Curtis L. Olson -- Wednesday 03 July 2002 21:35: It would be interesting to also see the actual ground elevation along with the other numbers you posted. Ahh, sorry. I mixed up altitude with ground elevation. May take a while, I'm not sure if the jsbsim log outputs that. Give me some minutes. You could also insert a cout/printf in the main loop ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Jim Wilson writes: Did you try rolling out from the position that Melchior included in this mornings message (the one with the agl data)? I couldn't replicate before but I can by rolling on the ground (a couple feet) from that position. Just curious to know if you do. I thought Melchior was having problems while in flight? Could you send me a pointer to his message? I must have missed it. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ [EMAIL PROTECTED] said: * Jim Wilson -- Wednesday 03 July 2002 18:26: Melchior FRANZ [EMAIL PROTECTED] said: A huge value would probably only make the AGL radar flash a wrong value but it wouldn't have further, malign effects. Crash detection is triggered in some cases which will basically shutdown fdm. Any other malign effects? Random plane crashes without obvious reason are certainly not acceptable for a flight simulator. Even more so, if the reason is gaps in the scenery that shouldn't be there in the first place. The gaps aren't really severe and certainly hard to avoid, but I don't see why they should make the plane crash. What would you call malign? If it made your monitor explode? Killed your cat? I'm sorry, must have misunderstood your message. I was only describing the effect from a programmer's perspective, not stating that it was acceptible. My question was just to discover if you noticed anything else, like your monitor exploding, cat getting killed, and so on. ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Curtis L. Olson [EMAIL PROTECTED] said: Jim Wilson writes: Did you try rolling out from the position that Melchior included in this mornings message (the one with the agl data)? I couldn't replicate before but I can by rolling on the ground (a couple feet) from that position. Just curious to know if you do. I thought Melchior was having problems while in flight? Could you send me a pointer to his message? I must have missed it. I just forwarded it to your mailbox. It was recieved here at about 8am EST Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Melchior FRANZ writes: Never mind. I just try to be a serious pilot, and dying in a plane crash is pretty dramatic. And, as a non-Micros~1 user, random crashes are generally undesirable for me. :-] Ignoring my own previous statement about avoiding politics -- I've seen a lot of varient spellings of microsoft and windows. Acknowledging that these are offensive to some, I usually try to avoid using them, but I hadn't seen MICROS~1 yet ... got a chuckle out of it. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. I tried this with a few aircraft, and they all seem to see the same bump. Sticking a printf in YASim's update method (or actually uncommenting one that someone else added, heh) I see the terrain elevation leap by about 2 meters as you cross the tile boundary. Now, 2m doesn't sound like a lot to worry about, but clearly the terrain rendering isn't showing anything near a 2 meter difference, so the problem isn't with the scenery data itself. If there's a bug in the collision detection, it's possible that it has higher magnitudes elsewhere. I have to go back to work now, but maybe this will help someone else track down the issue. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Curtis L. Olson [EMAIL PROTECTED] said: Melchior FRANZ writes: Never mind. I just try to be a serious pilot, and dying in a plane crash is pretty dramatic. And, as a non-Micros~1 user, random crashes are generally undesirable for me. :-] Ignoring my own previous statement about avoiding politics -- I've seen a lot of varient spellings of microsoft and windows. Acknowledging that these are offensive to some, I usually try to avoid using them, but I hadn't seen MICROS~1 yet ... got a chuckle out of it. :-) Hehe... And a quick search on google reveals: http://www.tuxedo.org/~esr/jargon/html/entry/micros1.html http://support.microsoft.com/default.aspx?scid=kb;EN-US;q143395 Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
On Wed, 3 Jul 2002 23:00:45 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: C:\CONGRTLS.W98 I don't get it. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
On Wed, 3 Jul 2002 23:00:45 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: C:\CONGRTLS.W98 I don't get it. It was actually for the release of Windows 95 and it translates to Congradulations Windows 95 g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Jon S Berndt writes: On Wed, 3 Jul 2002 23:00:45 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: C:\CONGRTLS.W98 I don't get it. In unix this would probably translate to something like cw98 (to save typing.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Andy Ross wrote: Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. Yup, I see just the same as you. On crossing the dotty white crack, my little plane topples over on its back like a beetle waving its legs in the air. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
On Tue, 2002-07-02 at 13:39, Melchior FRANZ wrote: * Jim Wilson -- Tuesday 02 July 2002 21:59: I can't make this happen...is this with current scenery from cvs? Yes, and with plib/SimGear/FlightGear CVS-HEAD from today. I almost fall over and hear a bump from the gear touching the ground (which cannot be, of course). No tire squeal, though. And I can recover and don't die. Unfortuenately I couldn't make jsbsim's logging feature work yet. I tried both TERMINAL and TABULAR instead of NONE. No effect. Could be interesting to see which column makes the values jump first. Did you try CSV? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: crashes at tile borders revisited
Unfortuenately I couldn't make jsbsim's logging feature work yet. I tried both TERMINAL and TABULAR instead of NONE. No effect. Could be interesting to see which column makes the values jump first. Did you try CSV? Yes, terminal and tabular are not implemented, yet. smime.p7s Description: application/pkcs7-signature
