Re: [Flightgear-devel] Weather issues for 2.6
I've just placed a patch into the forum fixing the altitudes, providing a new GUI which makes Local Weather Config obsolete and ports Cb towers also to the new rendering system. I haven't tested it excessively yesterday, but most of it was written and tested before my computer died, so it should be fine. > You should be able to set the render bin for the effect if you are using > one. > Alternatively, it may be that we can get more performance from the clouds > such that we won't need to put them in a separate render-bin. Hm, this seems to be more subtle then. I adapted rain-layer.eff from cloud.eff and as a consequence I see that in both files 10 DepthSortedBin occurs. So that is in fact not the problem?! But then what it - why are the rain layers always sorted in front of the clouds? * Thorsten -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!
2011/12/15 Mathias Fröhlich wrote: > On Wednesday, December 14, 2011 15:49:22 Stuart Buchanan wrote: >> 2011/12/14 Mathias Fröhlich wrote: >> > But, the question is how many cloud drawables do we have? The render Bin >> > sorting bottleneck - if we run into this - is O(log(n)*n) with the n= >> > number depth sorted drawables. Which means we need to have a huge amount >> > of cloud drawables that this effect dominates. >> >> As you've seen from the code, at present, we have a cloud drawable per >> sprite, where there are multiple sprites per cloud, and >1000 clouds in a >> typical Cu layer. > > Than I assume 10 to 500 sprites in one cloud? > Which makes about 1 > draws for the clouds. > That could explain the observations. For the global weather 3D clouds it is typically between 5 and 15 sprites per cloud. We perform some sprite-culling to avoid creating sprites that are too close together. For Local weather it's sometimes as low as 1 sprite per cloud. >> > Ok, looking into the Cloud drawable implementation, I believe that your >> > almost first response is probably the easiest. Just without point >> > sprites, just improoving what is currently done: >> > Try to put that multiple draws into a single draw using array objects. >> > Make sure that you still get a 'fast drawable'. YOu can verify this by >> > asking the geometry if osg::Geometry::areFastPathsUsed() returns true. >> > That is mostly: do not use any index arrays. The only indices which may >> > be worthwhile are the indexed primitives sets. >> > Sorting inside the drawable is then done by either redoing the arrays or >> > probably better by using an indexed primitive set and reordering the >> > indices. >> >> I will try this tonight. Thanks again for looking into this and >> helping to point me >> in the right direction. I made the changes you suggested last night so that there is a single geometry per cloud instead of one per sprite. That should have reduced the number of draws by a factor of 10. The code isn't ready to be checked in (I've still got to sort the geometry), but so far it hasn't made a significant difference to the frame-rate on my system. However, I've got a fairly big graphics card and get fairly high frame-rates, so it may help more for other people. It certainly doesn't make things any worse, and the code changes are smaller than I had feared, so I expect to get this change checked in for 2.6.0. >> (BTW - I think I've managed to get Impostors working though I've still to >> see any performance gain) > Ok, if this helps this is fine. > So the granularity is one cloud per imposter? No. At that level my machine ran out of memory. I've got an Impostor for each top level LoD node, which typically contains the clouds in a 10kmx10km area, so we end up with ~18 Impostors. Still no performance gain from this either. I've made it configurable using properties, so once it's checked in people can experiment to see if varying the LoD size, and hence number of impostors, helps. Again, the code changes were remarkably small, so I expect to have this ready in time for 2.6.0 > For this approach, you need to know that setting up a new fbo for draw is not > exactly cheap. It's not catastropic, but again don't do too often. > Also each cloud probably uses one texture of some size which will occupy > memory. Having >1000 of them is probably significant. > Also drawing a cloud is than not only the draw, but also the texture change > state change that needs to happen on every draw. > This could still be a net win. But that's what I think is good to know to > balance the orders of magnitude. > > May be it helps to have less individual clouds where each of them is drawn > with a single draw? > > An idea that I had yesterday. Just a dumb question: > Is it possible that we have some problem so that we have more clouds in the > visible scene than we really expect there? That is is there a bug that makes > some of them being drawn techically but not appear on the screen where they > should be? Which could make draw so expensive by drawing more than we can see? > So, just because experience shows that problems have often very simple reasons > compared to the first ideas what could happen ... Very good point. So we might not be culling the clouds properly? I can easily put in some code to check this. I _think_ I've got the bounding boxes set up correctly and a sensible LoD tree, but this is something I should check. > I hope that I really guide into the right direction. Please keep suggesting ideas. I'm a bit time-limited right now, so it may take me some time to write the code to test them, but I'm "all ears" :) -Stuart -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/s
[Flightgear-devel] New scenery webtool.
Hello, A small announce to let you know a new scenery webtool is out: http://scenemodels.flightgear.org/submission/shared/ The goal of this tool is to ease the insertion of shared models position within the FG scenery database for both the submitters and the scenery maintainer(s). Hope this will make the number of positions increase! The steps are very easy to follow : 1. Place the object within FG. 2. Take the data and copy/paste it within the form (please double check the content of what you're inserting!). Once clicked on submit, the request is done! 3. Add a small kind comment for Martin, telling him what you're doing. 4. Give the captcha what it wants (sorry for this, but it's to avoid unwanted automated robots) 5. Click submit. The request is then automatically sent to Martin, he just has to check your request and do one action to commit it into the DB. More improvements are to come (short term to long term), so check the forum for the to-do list & more: http://www.flightgear.org/forums/viewtopic.php?f=5&t=14671 Hope you like it. Olivier-- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weather issues for 2.6
Thorsten, ... snip ... > > 9) Water shader (very impressive!!!) doesn't react to wind/overcast in > Local Weather. Vivian, Emilian - at some point we discussed an interface > of how to pass the situation to the shader. Technically it's really easy > for me to write in any form you like - just tell me where you want to pick > up that info. We are still looking into this one. At first glance there doesn't seem to be any good reason for the wind not being honoured. The overcast is a problem of interpreting different implementations between Global and Local weather. Now you are back operational we will try to come up with a suggestion in the next couple of days > 10) Skydome scattering shader - is now basically broken in overcast > situations when visibility is low, because the clouds fade rapidly but the > shader doesn't react, so more blue sky is seen when visibility goes down. > In October, I had a near-seamless solution to that involving the ground > haze shader, a modified skydome shader, and modified cloud distance fading > behaviour which did the trick both for local and global weather (which was > also posted in the forum as very experimental feature). Is anyone (Vivian, > Emilian?) still working on that - or should this better go into the next > release? We had some problems with adapting the ground haze shader to the new, universal fog scheme. At the moment, our results are unacceptable for release. We are not clear at this stage if we can do it at all, and we are unlikely to come up with a tested and tuned solution by the 17th. We will continue to work on it in the next few days to come up with a better informed decision on the way ahead. > > All in all, the performance requirements of the current version are weird. > I took my Carrier-Ops flight from Vinson to Nimitz in the F-14b which used > to have good framerate (no terrain) and I ended up with 14 fps. Not really > improved a lot by switching water shader off... I then wanted to know how > far down it'd go in really detailed scenery and used the Lightning to > blast around Hawaii to Maui - with similar cloud coverage I ended up with > twice the framerate and a comfortable 24-30 fps. With the Concorde on the > runway in Seattle, I had a whopping 3 fps (never seen anything this > low...), but the AAr with the F-16 around Las Vegas gave me 34-40 fps > (again in similar clouds). Doesn't agree at all with my previous > experience. > Some "improvements" to the wake of Vinson are likely to have cost some framerate. These can be reverted by selecting a lower quality setting so it should be possible to compare like-with-like. Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New scenery webtool.
Just a quick note from my end: While Olivier mentioned only myself as a reviewer of Scenemodels commits, I consider this new system not only as an aid to reduce the overall workload for reviewers/committers but also as a tool which later allows to un-tie the process of submitting object positions (and more) from just a few individuals. Cheers - and many thanks to Olivier ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Arresting Type Devices
Hi all Is someone modelling/implementing Arresting Devices for runways ? Cheers, Yves -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Re : Arresting Type Devices
Hello Yves, Arresting cables for runways do already exist in FG: see them in action at LFRJ Naval Base for instance. Olivier -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Am 15.12.11 18:26, schrieb Olivier: > Hello Yves, > > Arresting cables for runways do already exist in FG: see them in action at > LFRJ Naval Base for instance. > > > Olivier > Errm, Is this BAK12/14 or MA1A, ES or E28/B ? ;-) Cheers, Yves -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
HB-GRAL > -Original Message- > From: [mailto:flightg...@sablonier.ch] > Sent: 15 December 2011 17:37 > To: Olivier; FlightGear developers discussions > Subject: Re: [Flightgear-devel] Re : Arresting Type Devices > > Am 15.12.11 18:26, schrieb Olivier: > > Hello Yves, > > > > Arresting cables for runways do already exist in FG: see them in action > at LFRJ Naval Base for instance. > > > > > > Olivier > > > > Errm, Is this BAK12/14 or MA1A, ES or E28/B ? ;-) > The ones I did in fgdata are BAK12. You can see them at Miramar (KNKX) Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
"Vivian Meazza" wrote: > The ones I did in fgdata are BAK12. Just for the record, the original BAK-12 was provided by David Culp: http://scenemodels.flightgear.org/modeledit.php?id=918 We're having two models of a BAK-12 in the Base Package because some people here are incapable to comprehend the world beyond their own nose ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Am 15.12.11 20:39, schrieb Martin Spott: > "Vivian Meazza" wrote: > >> The ones I did in fgdata are BAK12. > > Just for the record, the original BAK-12 was provided by David Culp: > >http://scenemodels.flightgear.org/modeledit.php?id=918 > > We're having two models of a BAK-12 in the Base Package because some > people here are incapable to comprehend the world beyond their own > nose ;-) > > Cheers, > Martin. And close to my nose I see here some mystic FAA data output: EDF 06 BAK12 61.248633 -149.844258333 EDF 16 BAK12 61.262069 -149.793475 BIG 19 BAK12 64.0077345 -145.707352861 EIL 14 BAK12 64.684208 -147.117919444 AKN 12 BAK12 58.68394-156.6647265 SYA 10 BAK12 52.716433 174.092125 MGM 10 BAK12 32.3023991944 -86.4099770278 FSM 07 BAK14 35.3336058056 -94.3814535556 LUF 03L BAK12 33.522975 -112.398563889 LUF 03R BAK12 33.526822 -112.38989 . . . Is this something that could/should come to the scenery database somehow ? Cheers, Yves -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Martin > "Vivian Meazza" wrote: > > > The ones I did in fgdata are BAK12. > > Just for the record, the original BAK-12 was provided by David Culp: > > http://scenemodels.flightgear.org/modeledit.php?id=918 > > We're having two models of a BAK-12 in the Base Package because some > people here are incapable to comprehend the world beyond their own > nose ;-) > Look under your own - one is non-op - the other functioning. You can pick whichever you prefer Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
HB-GRAL wrote: > And close to my nose I see here some mystic FAA data output: [...] > Is this something that could/should come to the scenery database somehow ? Generally I'd say: Great ! but I'd feel best if I knew that these positions really match the touchdown areas of 'our' runways. How many items are at disposal ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
> -Original Message- > From: Martin Spott [mailto:martin.sp...@mgras.net] > Sent: 15 December 2011 19:39 > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Re : Arresting Type Devices > > "Vivian Meazza" wrote: > > > The ones I did in fgdata are BAK12. > > Just for the record, the original BAK-12 was provided by David Culp: > > http://scenemodels.flightgear.org/modeledit.php?id=918 > > We're having two models of a BAK-12 in the Base Package because some > people here are incapable to comprehend the world beyond their own > nose ;-) > No, I'm wrong. The one I did which says this: * Add runway arrester gear type BAK-12. Based on Dave Culp's original work. is operational. The other one, which used to be non-op, seems to have gained operational capability along the way. It was the original intention to have 2 - a simpler, non-op one and a more complex functional one. The distinction seems to have become blurred along the way Vivian -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Am 15.12.11 22:37, schrieb Martin Spott: HB-GRAL wrote: And close to my nose I see here some mystic FAA data output: [...] Is this something that could/should come to the scenery database somehow ? Generally I'd say: Great ! but I'd feel best if I knew that these positions really match the touchdown areas of 'our' runways. How many items are at disposal ? Cheers, Martin. Attached you find the list. There are 55 "BAK12" and 23 "BAK14" devices, 156 items total, all in the US and found in recent FAA runway data. The coordinates comes from column base/reciprocal ends of runways, published by FAA, assuming myself this is the point where the device is installed ;-) Cheers, Yves EDF 06 BAK12 61.248633 -149.844258333 EDF 16 BAK12 61.262069 -149.793475 BIG 19 BAK12 64.0077345 -145.707352861 EIL 14 BAK12 64.684208 -147.117919444 AKN 12 BAK12 58.68394-156.6647265 SYA 10 BAK12 52.716433 174.092125 MGM 10 BAK12 32.3023991944 -86.4099770278 FSM 07 BAK14 35.3336058056 -94.3814535556 LUF 03L BAK12 33.522975 -112.398563889 LUF 03R BAK12 33.526822 -112.38989 IWA 12C MA1A33.317611 -111.66592325 IWA 12L MA1A33.3175886389 -111.661311556 IWA 12R MA1A33.3176702778 -111.67286825 DMA 12 BAK12 32.1801661944 -110.898090139 TUS 03 E5 32.1171670556 -110.9590405 TUS 11L BAK14 32.1233695278 -110.947911944 NYL 03L E28 32.636783 -114.629393944 NYL 03R E5 32.64874-114.612527861 NID 03 E28B35.6756416667 -117.708389444 NID 14 E28B35.698758 -117.69319 EDW 04R BAK12 34.8945598056 -117.905011972 NJK 08 E28 32.829133 -115.687102778 NJK 12 E28 32.8297805556 -115.672102778 FAT 11L BAK12 36.7835047778 -119.72921 NTD 27 E28B34.11695-119.106325 RIV 14 BAK12 33.896428 -117.27063 NUC 05 E28 33.017812 -118.602484167 NKX 06L E28 32.864564 -117.164848056 NKX 06R E28 32.8654736111 -117.151668889 NKX 28 E28 32.8656980556 -117.12709 NZY 11 E28 32.7023291667 -117.221266944 NZY 18 E28 32.7100325 -117.211676667 VCV 17 BAK934.621652 -117.386785472 COS 13 MA1A38.8231551944 -104.715352944 AGR 05 BAK12 27.640811 -81.351061 EGI 18 BAK12 30.6613849722 -86.52268775 HST 05 E5 25.4787213889 -80.3964438889 JAX 08 BAK14 30.4962166389 -81.6999653611 NIP 10 E28B30.2316036111 -81.6897738889 NIP 32 E28 30.2310052778 -81.665369 NQX 03 E28 24.565717 -81.6959 NQX 07 E28B24.5724916667 -81.700078 NQX 13 E28 24.578978 -81.692233 HRT 18 MA1A-M 30.442083 -86.689872 NRB 05 E28B30.383319 -81.4331598333 PAM 13L BAK12 30.080043 -85.5844108333 PAM 13R BAK12 30.077445 -85.5882263889 NPA 01 E5 30.3420186111 -87.321569 NPA 07L E5 30.3507736111 -87.329109 NPA 07R E5 30.3489869444 -87.328289 MCF 04 MA1A27.8373916667 -82.532683 VPS 01 BAK12 30.472889 -86.517886 VPS 12 BAK12 30.488786 -86.5522027778 MGE 11 BAK12 33.919118 -84.5321747222 SAV 10 BAK14 32.1287536944 -81.2187920278 VAD 18L BAK12 30.981822 -83.1908027778 VAD 18R E5 30.979297 -83.195219 WRB 33 BAK14 32.626822 -83.580478 UAM 06L BAK12 13.580344 144.91562 UAM 06R BAK12 13.575319 144.916486111 HNL 04R BAK14 21.3139180278 -157.927134889 HNL 26L BAK14 21.3068010556 -157.910598472 NGF 04 E28 21.4438147222 -157.776901 JRF 04L E28B21.306836 -158.07206 BKH 16 BAK12 22.030915 -159.786599167 DSM 05 BAK14 41.5233680278 -93.6771125 DSM 13 BAK14 41.5456056944 -93.6744538611 SUX 13 BAK12 42.4091870278 -96.3977028889 BOI 10R BAK14 43.5700336944 -116.242615333 MUO 12 BAK12B 43.056711 -115.890258333 GUS 05 BAK12B 40.635825 -86.167869 IAB 01L BAK12B 37.607272 -97.2734805556 AEX 14 MA1A-M 31.3378769444 -92.5592268056 BAD 33 BAK12 32.487717 -93.653494 NBG 04 E28B29.823508 -90.037297 NBG 14 E28B29.823352 -90.033094 BAF 02 BAK14 42.1453001944 -72.7188199167 ADW 01R BAK14 38.7977364722 -76.86357625 NHK 06 E28B38.27
Re: [Flightgear-devel] Re : Arresting Type Devices
"Vivian Meazza" wrote: > The other one, which used to be non-op, seems to have gained operational > capability along the way. You see, in order to avoid confusion, having just one operational arrestor would have been the clever solution. We're trying to simulate real-world, don't we ? Sure, we're not perfect but I think we're doing our best within the limits of our ressources. Thus, intentionally leaving an inoperational arrestor in place (instead of fixing it) sounds a bit odd Now, who would like to merge the best of both into one single model - before the feature freeze ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
HB-GRAL wrote: > The coordinates comes from column base/reciprocal ends of runways, is your definition supposed to be identical to "runway centerline at threshold" ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Am 15.12.11 23:21, schrieb Martin Spott: > HB-GRAL wrote: > >> The coordinates comes from column base/reciprocal ends of runways, > > is your definition supposed to be identical to "runway centerline > at threshold" ? > > Cheers, > Martin. It is "Latitude/Longitude of physical runway base/reciprocal end" as defined by FAA. I can also add the source and date of this point in the list, when it is useful. But I better do not add elevation of this point for fg scenery, right ? EDF 06 BAK12 61.248633 -149.844258333 AVN 08.11.03 EDF 16 BAK12 61.262069 -149.793475 AVN 08.11.03 BIG 19 BAK12 64.0077345 -145.707352861 AVN 02/16/2007 EIL 14 BAK12 64.684208 -147.117919444 MILITARY 07/16/2007 AKN 12 BAK12 58.68394-156.6647265NGS 06/17/2005 SYA 10 BAK12 52.716433 174.092125 MILITARY 07/18/2007 MGM 10 BAK12 32.3023991944 -86.4099770278 NGS 01/29/2003 Cheers, Yves -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re : Arresting Type Devices
Am 15.12.11 23:49, schrieb HB-GRAL: > > EDF 06BAK12 61.248633 -149.844258333 AVN 08.11.03 > EDF 16BAK12 61.262069 -149.793475 AVN 08.11.03 > BIG 19BAK12 64.0077345 -145.707352861 AVN 02/16/2007 > EIL 14BAK12 64.684208 -147.117919444 MILITARY 07/16/2007 > AKN 12BAK12 58.68394-156.6647265NGS 06/17/2005 > SYA 10BAK12 52.716433 174.092125 MILITARY 07/18/2007 > MGM 10BAK12 32.3023991944 -86.4099770278 NGS 01/29/2003 > Oh, can we have at least this one in the scenery ? "EGI 18 BAK12 30.6613849722 -86.52268775MILITARY 09/29/2011" My 2 Rappen (swiss cents) this will make fg the leading and most recent arresting device simulator on earth. :-) Cheers, Yves -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
