Re: [Flightgear-devel] Scenery manager
Hi Adrian, On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote: I am presenting an experimental (WIP) method to reduce memory consumption by scenery with 30%, while increasing the visibility distance 4 times. This method relies on some kind of LOD system, without mesh simplification. People smarter than me can come up with a safe algorithm to do that, but I'm afraid it requires changes to Terragear. Right now mesh simplification was not Could you explain how your system works? Presumably you are making some change to the tiles for the low resolution version? -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 12:35:20 Stuart Buchanan wrote: Hi Adrian, On Sun, Dec 16, 2012 at 4:32 AM, Adrian Musceac wrote: I am presenting an experimental (WIP) method to reduce memory consumption by scenery with 30%, while increasing the visibility distance 4 times. This method relies on some kind of LOD system, without mesh simplification. People smarter than me can come up with a safe algorithm to do that, but I'm afraid it requires changes to Terragear. Right now mesh simplification was not Could you explain how your system works? Presumably you are making some change to the tiles for the low resolution version? -Stuart Hi Stuart, It' basically very simple. Far tiles no longer compute anything other than it's own geometry, and also use a very low resolution texture set, obtained by running a batch resize on the regular texture set. This allows me to have 2.5 times larger view distance in high detail (SRTM) terrain with same memory consumption. There is of course a slight increase in disk IO, but I have only tested this with multithreading enabled on a dual core CPU. Load times for far tiles are actually smaller, since no calculations other than geometry and effects are performed on them. Inner tiles close to the viewer position are normal tiles, nothing changed. That's basically it. I need to refactor the code a bit before I can show it, I wrote it fast and while half asleep. Now, the really big stuff would be load-time mesh simplification, and I have read a couple of papers that seem to suggest that's possibile, but would require some changes to the BTG format. I leave that up to the Terragear guys, I am not very familiar with the way their mesh construction works. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi Adrian, The same idea is behind the osg lod based whole world model. Where do you store the elevation data? Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
There are many issues and tradeoffs with mesh simplification. There are many algorithms and approaches, each with their own unique strengths and weaknesses. Challenges include finding a strategy to hide the cracks between adjacent tiles draw with different levels of details (and possibly more or less details on the edges.) You also have issues of objects floating or being partially (completely) burried if the underlying terrain becomes coarser or more detailed (or you have to move the objects up or down which can also be odd looking.) Of course there is the whole issue of processing/managing the GIS data, and generating the tiles to support whatever LOD scheme is chosen. When the FlightGear scheme was originally devised, there was a leaning in the flight sim world away from LOD schemes and back towards just drawing all the tiles in full detail -- again, this is just another strategy on the continuum of available options with it's own strengths and weaknesses. Keep in mind that some of the popular strategies of the day are popular because they are developed in response to the typical capabilities of current gamer hardware. After we committed to our strategy, continuous level of details algorithms began to really catch steam and become popular -- thinks like ROAM. These algorithms were designed to minimize how many vertices were sent to the graphics hardware every frame. But again, they have their strengths and weakness -- nothing that can't be solved or worked around, but only through a large amount of effort to do what we need for a generic flight simulator trying to model the entire world. But then (maybe a bit like clothing styles), the capabilities of consumer 3d hardware improved and began to be able to store the actual geometry right on the card. Shader language effects became popular, and there was less need to send the geometry to the video card every frame. More and more of the rendering was right on the card. That led to less popularity with ROAM type algorithms because they are always sending the new geometry over to the card each frame and you end up not utilizing the full capability of the graphics hardware. So there is always the universal principle that it's faster to do less work. But styles and algorithm popularity is a moving target as hardware is a moving target. If we were building a game that would go to market in the next 6 months and be removed from the shelves a few months later, we would probably use a different strategy compared to our development process which started in 1996 and does follow the trends to some degree, but a little less aggressively and a little more skeptically because we would like to run on hardware from a few years ago, on hardware 6 months from now, and on hardware 5-10 years from now. Curt. On Sun, Dec 16, 2012 at 10:39 AM, Mathias Fröhlich wrote: Hi Adrian, The same idea is behind the osg lod based whole world model. Where do you store the elevation data? Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 18:39:47 Mathias Fröhlich wrote: Hi Adrian, The same idea is behind the osg lod based whole world model. Where do you store the elevation data? Greetings Mathias Hi Mathias, It's actually nothing really special about it, I'm just modifying a little the tile manager to define inner tiles and outer tiles. The elevation data is inside the same old BTG files, which are actually lists of polygons making a tile mesh, hence why it's hard to simplify on runtime this mesh. The Terragear team might now more about this. This is just a few lines of code modification to decrease memory usage by really detailed scenery and allow a greater terrain loading range. So nothing's changed about the terrain format itself. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance
Hi everybody, I just had the chance to compile a recent git-pull on my old and battered linux-notebook workhorse and with great delight, I noticed that I can run FlightGear again with 26fps at KSFO. I had to strip down most eye candy shaders for the GeForce Go 7400 but 3D clouds render fine without a noticable drop in framerate, even if a cloud spawns the entire screen. That was much worse a few month ago when FlightGear barely ran on that old hardware. Whoever was involved in that magic - well done! Thanks for still supporting older and weaker hardware. Torsten -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi, On Sunday, December 16, 2012 20:24:48 Adrian Musceac wrote: It's actually nothing really special about it, I'm just modifying a little the tile manager to define inner tiles and outer tiles. The elevation data is inside the same old BTG files, which are actually lists of polygons making a tile mesh, hence why it's hard to simplify on runtime this mesh. The Terragear team might now more about this. This is just a few lines of code modification to decrease memory usage by really detailed scenery and allow a greater terrain loading range. So nothing's changed about the terrain format itself. Ok, so it's not really less level of detail. It's just about stripping out the models to have bare btg's. Right? Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote: It' basically very simple. Far tiles no longer compute anything other than it's own geometry, and also use a very low resolution texture set, obtained by running a batch resize on the regular texture set. OK. So you don't load anything other than the BTG file (e.g. no placed objects)? I'm surprised there's any benefit to using a very low resolution texture set. Surely the normal textures are already loaded by OSG and it's cheaper just to refer to those rather than loading some more textures? Or are we not sharing our textures between tiles? -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: I'm surprised there's any benefit to using a very low resolution texture set. Surely the normal textures are already loaded by OSG and it's cheaper just to refer to those rather than loading some more textures? Or are we not sharing our textures between tiles? Right, I had exactly the same thought. Of course, if by some terrible mistake we aren't sharing textures, that would be a very big bug, but hopefully easy to fix! James -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 21:37:37 James Turner wrote: On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: I'm surprised there's any benefit to using a very low resolution texture set. Surely the normal textures are already loaded by OSG and it's cheaper just to refer to those rather than loading some more textures? Or are we not sharing our textures between tiles? Right, I had exactly the same thought. Of course, if by some terrible mistake we aren't sharing textures, that would be a very big bug, but hopefully easy to fix! James I'm replying to multiple messages here: James: I have no clue how and if the textures are shared, or if the osg cache is related to this. All I know is that I can see a difference. I could explain it in my simplistic view: the current position holds the large textures for all material within the inner zones. If there are materials within the outter zone which are not within the inner zone, their effect is using a smaller texture, at least until they pass into the inner zone. So I could explain it like this: I have Road, DeciduousForest, DrypastureCover in the high res zone, and BroadleafForest,NeedleForest, Rock, Marsh Bog etc in the outter zone. No need to have high res Bog for a triangle 100 km away (keep in mind I also use large res textures, some of which were kindly commited by ThorstenR in the regional set). Regarding the osg cache, I am not familiar with the way it works, and how it shares textures, so forgive me if I can't answer this. Mathias, Stuart, yes I'm only loading the bare surface from the BTG, and not performing any tree, building, model calculations from them (they would be invisible at 20-30 km away, but the osg::LOD just hides it from view, does not prevent from loading in RAM all the objects). Besides reduced scenegraph, the loading speeds for an outer tile are faster. The tilecache model is also changed, so it does not look like a long tail behind the flightpath, but mostly as a rectangle around the plane. I reckon the tower view losing terrain should be dealt by disabling tower view when outside a reasonable distance from the tower. The memory gains are those I spoke about before, and allow me to fly a long time in custom SRTM terrain without running out of RAM. I'd estimate a 1.5 - 2 times improvement in memory cost vs. view distance, at a slight cost of increased disk IO (which is not noticeable, at least running in multithreading mode). I am aware there are better systems out there, I'm just doing what I can within the restrictions of the BTG format. I'd be more than happy to have a real terrain LOD, but right now that means lots of changes in Terragear and simgear. I'll publish the modifications tomorrow, If I can get around to clean the code a bit. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 19:37:37 James Turner wrote: On 16 Dec 2012, at 19:18, Stuart Buchanan wrote: I'm surprised there's any benefit to using a very low resolution texture set. Surely the normal textures are already loaded by OSG and it's cheaper just to refer to those rather than loading some more textures? Or are we not sharing our textures between tiles? Right, I had exactly the same thought. Of course, if by some terrible mistake we aren't sharing textures, that would be a very big bug, but hopefully easy to fix! James Running under gdebugger would suggest textures are indeed shared across tiles, as I can't find any texture loaded twice. Emilian, -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 21:18:10 Stuart Buchanan wrote: On Sun, Dec 16, 2012 at 11:44 AM, Adrian Musceac wrote: It' basically very simple. Far tiles no longer compute anything other than it's own geometry, and also use a very low resolution texture set, obtained by running a batch resize on the regular texture set. OK. So you don't load anything other than the BTG file (e.g. no placed objects)? I'm surprised there's any benefit to using a very low resolution texture set. Surely the normal textures are already loaded by OSG and it's cheaper just to refer to those rather than loading some more textures? Or are we not sharing our textures between tiles? -Stuart Stuart, James, I'm actually not 100% sure about textures, but I have provided my explanation for the case of having x,y,z materials within the inner tiles, and a,b,c materials within the outer tiles (intersections between them are irrelevant, since are loaded anyway). I'd prefer having a,b,c which are not supposed to be seen at high res, being small size, until the materials enter the inner tiles and load the large textures (if not already in cache). My explanation may be wrong, I don't stand by it 100%. My main interest with terrain was a) having longer distances available, and b) having separate traversal masks only for surface. All for use in my infamous now radio code. This lead to what I have now, an improvement in memory usage and view distance. All this has gotten me interested again in LOD systems. I'd like to see the day when the whole earth can be rendered like Mathias said. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi, On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote: I am aware there are better systems out there, I'm just doing what I can within the restrictions of the BTG format. I'd be more than happy to have a real terrain LOD, but right now that means lots of changes in Terragear and simgear. Well, I suspect that this effect is easy to get without any additional manager. Not to speak about sophisticated continous lod. Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 22:38:41 Mathias Fröhlich wrote: Hi, On Sunday, December 16, 2012 22:02:15 Adrian Musceac wrote: I am aware there are better systems out there, I'm just doing what I can within the restrictions of the BTG format. I'd be more than happy to have a real terrain LOD, but right now that means lots of changes in Terragear and simgear. Well, I suspect that this effect is easy to get without any additional manager. Not to speak about sophisticated continous lod. Mathias Hi, Suspect you're right, now after reading the required information :) Would need to be a completely separate thing from our Terragear, and I'm not sure how Stuart's trees and buildings would fit in. Not to mention the lights. But I see it possible now. I'll have to do a lot more reading though, this is definetly not my area. Cheers, Adrian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
Hi, On Sunday, December 16, 2012 22:32:48 Adrian Musceac wrote: My main interest with terrain was a) having longer distances available, and b) having separate traversal masks only for surface. All for use in my infamous now radio code. This lead to what I have now, an improvement in memory usage and view distance. Ok, for that, I can see a lot of solutions. Having one that is may be close: Use the BVH tree that is used in fgelev or fgai. The fgelev one is parametrized like you probably need today. There is one hacky switch in the BVH paging that only loads terrain into a bounding volume tree. Have two different bvh trees and making sure that these nodes are not cached for scenery loading - since they are incomplete in the sense of the visible viewer - would provide you what you need. Since you are doing radio stuff I expect that your main workhorse is a line segment intersection which should be done best with this kind of structure. True? May be you need an other line segment visitor which measures the distance that is covered by material. Ok, what might block this approach is the amount of static variables that is spread around. Already in face of reusability almost every global/static variable can be a serious problem ... Look into fgelev and fgai and look for BVHPAger and its getBoundingVolumes(sphere) method. May be flightgear is not really ready for this kind of shared usage, but the basic building blocks are there ... Ok, in the end you might need an other custom approach. But just off my head what I think is probably best algorithmically. Also keep in mind that tuesday is the deadline for new features for the next release. Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery manager
On Sunday, December 16, 2012 23:11:44 Mathias Fröhlich wrote: Hi Mathias, Ok, for that, I can see a lot of solutions. Having one that is may be close: Use the BVH tree that is used in fgelev or fgai. The fgelev one is parametrized like you probably need today. There is one hacky switch in the BVH paging that only loads terrain into a bounding volume tree. I'm just using the get_elevation_m function from the scenery subsystem, inspired by Torsten's terrain sampler, but in a different way. This tests for nodes with SG_NODEMASK_TERRAIN_BIT set, which trees, houses, random buildings also have. Therefore I added a special bit only for surface SG_NODEMASK_TERRAIN_BIT, and accounted for it everywhere SG_NODEMASK_TERRAIN_BIT was referenced. This way subgraph traversal are an order of magnitude faster since they don't use other stuff generated by the BTG loader which have that bit set. If you want me to, I can place a simgear merge request and see what I changed and where wrt. traversal masks. Have two different bvh trees and making sure that these nodes are not cached for scenery loading - since they are incomplete in the sense of the visible viewer - would provide you what you need. Since you are doing radio stuff I expect that your main workhorse is a line segment intersection which should be done best with this kind of structure. True? May be you need an other line segment visitor which measures the distance that is covered by material. The principle is: have a general direction towards the radio station, go in that direction X meters (100-500 depending on setting) and get an elevation profile point. After acquiring a complete elevation profile for a path line, this is fed to the real algorithm which does all the hard calculations. Ok, what might block this approach is the amount of static variables that is spread around. Already in face of reusability almost every global/static variable can be a serious problem ... Look into fgelev and fgai and look for BVHPAger and its getBoundingVolumes(sphere) method. May be flightgear is not really ready for this kind of shared usage, but the basic building blocks are there ... I'll have another look next week, it's a while since I studied that code. I don't think I need something more custom for now. The radio code is working just fine right now, but I'm definetly going to improve it in some areas, once it's merged. Featurewise, I'm not yet done either. I am also planning to get rid of the scenery subsystem dependency if possible. Ok, in the end you might need an other custom approach. But just off my head what I think is probably best algorithmically. Also keep in mind that tuesday is the deadline for new features for the next release. I know, hence the whole discussion about this feature that took most of the mailing list space lately. Sorry about that. Let me know if you are interested in the traversal mask stuff that I have added to separate surface only, models, trees, random buildings etc. I can place a merge request tommmorow, but it has to go simultaneously in fg and simgear, since the traversal masks are used in both. Cheers, Adrian Greetings Mathias -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance
Hi All, While I hesitate to claim performance improvements I've not seen myself, it may be that this was caused by this commit: 266b362238d0cef5a1c4df81bacbe941ee4c59ef which discards transparent fragments. I'd be very interested if you could revert the changes in that commit and let me know if it makes any difference. Thorsten R: I've just committed a similar change to the lightfield 3d cloud fragment shader. I don't notice any difference in rendering quality with the change, but you eye may be better than mine in this case :). On a related note, I've also just pushed some changes to the 3d cloud rendering such that sprites on the back of the cloud are not rendered if they are more than 10km away (configurable in /sim/rendering/cloud3d-detail-range). On my system this gives 20-50% frame-rate increases, particularly under overcast conditions. As always, I'm very interested to hear if this makes things better or worse for others. -Stuart -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
