Re: [Flightgear-devel] OSG point lights
Hi Tim, I did not find the time to look into that this weekend. These evenings are my friend. On Thursday 30 November 2006 10:03, Tim Moore wrote: I'm not sure about faster but, as far as I can tell, equivalent. By the way, it would be very nice to have some more timing information available than just the frame rate. I don't know if the easiest way to get there is to move to Producer so we can get its nice rendering stage statistics, wait for Robert to duplicate that in his new osgViewer stuff, do it ourselves, or what. Yep, that must happen at some time that we have that cull and draw times on the screen ... I do not want to remove the old implementation that was happening completely on the GPU in favour to an CPU based one if we end up slower. Anyway, can we keep the old implementation instead of just a plain OpenGL point based one. That means the old one that used triangles that are backface culled and draw points for the front side where two of them are transparent? I don't mind adding the old implementation back in as an option, except for the VASI lights, where it really would have no advantage over the OSG lights. One would lose some features, such as point size scaled by intensity, fading alpha with distance, and blink sequence animations for the approach lights. No, I do not think that we loose such features completely, we just need to implement exactly what we need ourselves. The VASI in the osgSim implementation has some problems. The size of the lights are something that I do not comment on here. The just need to be adjusted somehow. But I have objections in the basic way it is done. We had a smooth transition phase where the lights went smooth from red to white. The osgSim one just switches hard. I do also not see how the osgSim api will allow to change the color of a point in a smooth way. We can just render both in a transition area and hope that blending does our trick - but that is a really bad idea IMO. So especially for the vasi I do definitely want to use an own implementation that has nothing to do with osgSim. Also the current osgSim implemntation does directional lights with a hard switch off when the eye point moves beyond 90 deg to the normal. The previous implementation faded away nicely. That could be done with osgSim's sector but I still wonder if it is then slower... The only place where I can see osgSim as a *real* benefit is for the rabbit time sequences. Given that I would like to have a common appearance for all lights I would favor doing all of them ourselves. Like I stated before in some private mails I would like to have the osg version only as an alternative to the old implementation if it is faster than the GPU/triangle based one. May be not exactly the old implementation but an implementation that does nothing on the CPU but does all lightging decisions on the GPU. I would like to see some comparisons between the two approaches on a low-end machine. You may be overestimating the cost of the CPU based approach and underestimating the costs of triangle approach. As I said in private email, the old approach uses a fairly exotic rendering path -- polygons rendered in point mode with a texture environment -- which very well may be done on the CPU on a low-end machine. I don't think that I overestimate that - we just have plenty of those lights. What we definitely gain if we put such computations onto the GPU is additional CPU time where we can do something we cannot do on the GPU - not yet, but definitely then when we have cull and draw on an other cpu. ... hold on, I see, this also holds if the draw cpu will compute the light intensities instead of waiting for the gpu to do that. In the single threaded case we gain nothing with this argument ... Hmm ... Yes, I think that is a great project, but more work than I have time for right at the moment. It would be good for people to learn about OSG's support for shading programs *hint*hint* :) I will send you my hackery on that today evening. For that we still need some factory methods that will provide now the old implementation or the osg::LightPoint based one and later when I have the time to merge my tests into simgear the shader based one. So we need to he able to decide between implementations based on capabilities of the GPU and settings from the user anyway. Can we set up together such an infrastructure and put the old triangle based approach as other alternative below? We? :) Seriously, I would be happy to look at getting the OpenGL extensions available from OSG and making that available to fg in an elegant way, but goes way beyond to scope of light points, so for now exposing the choice to the user is probably the best way. Automatically benchmarking the user's machine and putting it into slow /fast categories would be an interesting project too. Hmm. I believe that what osg does for us in this area is silently switch of
Re: [Flightgear-devel] OSG point lights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mathias Fröhlich wrote: On Thursday 30 November 2006 01:36, Tim Moore wrote: Try http://www.bricoworks.com/moore/lightpt3.diff instead. A last-minute typo disabled point sprites. This is still faster with point sprites reenabled? I'm not sure about faster but, as far as I can tell, equivalent. By the way, it would be very nice to have some more timing information available than just the frame rate. I don't know if the easiest way to get there is to move to Producer so we can get its nice rendering stage statistics, wait for Robert to duplicate that in his new osgViewer stuff, do it ourselves, or what. I do not want to remove the old implementation that was happening completely on the GPU in favour to an CPU based one if we end up slower. Anyway, can we keep the old implementation instead of just a plain OpenGL point based one. That means the old one that used triangles that are backface culled and draw points for the front side where two of them are transparent? I don't mind adding the old implementation back in as an option, except for the VASI lights, where it really would have no advantage over the OSG lights. One would lose some features, such as point size scaled by intensity, fading alpha with distance, and blink sequence animations for the approach lights. Like I stated before in some private mails I would like to have the osg version only as an alternative to the old implementation if it is faster than the GPU/triangle based one. May be not exactly the old implementation but an implementation that does nothing on the CPU but does all lightging decisions on the GPU. I would like to see some comparisons between the two approaches on a low-end machine. You may be overestimating the cost of the CPU based approach and underestimating the costs of triangle approach. As I said in private email, the old approach uses a fairly exotic rendering path - -- polygons rendered in point mode with a texture environment -- which very well may be done on the CPU on a low-end machine. And as also told before I would like to have an other alternative for the main usage where we still do that light intensity decision - together with more advanced light texturing dependent on fog density, distance and other neat parameters - on the *GPU*. Just use a vertex shader for the view direction dependence of the light and fragment shaders for more advanced halos. That will require a newer OpenGL implementation and for that I believe we need to keep a lighting version for older boards. Also this all happens in the *GPU*. That has the advantage that it is probably way faster and even if it is about at fast as on the CPU, it does not block CPU cycles that can equally well be spent for more advanced physical models or better AI traffic or whatever we need to do on the CPU. So on the longer term I will favour that shader based approach as default as long as the GPU supports it. Yes, I think that is a great project, but more work than I have time for right at the moment. It would be good for people to learn about OSG's support for shading programs *hint*hint* :) For that we still need some factory methods that will provide now the old implementation or the osg::LightPoint based one and later when I have the time to merge my tests into simgear the shader based one. So we need to he able to decide between implementations based on capabilities of the GPU and settings from the user anyway. Can we set up together such an infrastructure and put the old triangle based approach as other alternative below? We? :) Seriously, I would be happy to look at getting the OpenGL extensions available from OSG and making that available to fg in an elegant way, but goes way beyond to scope of light points, so for now exposing the choice to the user is probably the best way. Automatically benchmarking the user's machine and putting it into slow /fast categories would be an interesting project too. In the long term I believe that we will reduce that back to two alternatives again. The shader based and one of the low end card capable ones - whichever of the low end card implementation is faster. For that decision we need *both* up again and optimized well ... I'll add back the old one and do the obvious optimizations. I will look at the current patch that weekend. Cool. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbp5ReDhWHdXrDRURAl5xAKCqJsKXQ0IL84SwMINO+k822eAnyQCdHjQ0 sDNDGgKV0U9b1rEltT7Pixo= =bmNW -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash
Re: [Flightgear-devel] OSG point lights
On 11/28/06, Tim Moore [EMAIL PROTECTED] wrote: Well, not so great. At SFO at night in the UFO I see a decrease from about 60fps with the existing lights to 43 with the OSG version. I suspect the slowdown is very dependent on processor speed; I hadn't noticed it on another computer using the debug builds. Although the distance attenuation does look nicer, you might want to hold off integrating my patch until I investigate further :) Ok, I can hold off ... I do agree they generally look really nice. I was confused about what the array of view options (sprites, enhanced lights, etc.) did with respect to this new patch ... I tried a few different combinations and could really figure it out. It would be nice to get this all sorted out and make it clear what the different options do or don't do and how they play together. It would also be nice to somehow maintain some sort of form of the original sprite based lighting as a fall back for people that don't have the HP to run the new OSG lights. Another thing that would be nice is to be able to keep the sprite based mechanism so that lights have fuzzy (rather than hard) edges as they are rendered. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: On 11/28/06, Tim Moore [EMAIL PROTECTED] wrote: Well, not so great. At SFO at night in the UFO I see a decrease from about 60fps with the existing lights to 43 with the OSG version. I suspect the slowdown is very dependent on processor speed; I hadn't noticed it on another computer using the debug builds. Although the distance attenuation does look nicer, you might want to hold off integrating my patch until I investigate further :) Ok, I can hold off ... I do agree they generally look really nice. I have a new patch at http://www.bricoworks.com/moore/lightpt2.diff (to save everyone a 50k mail message). This fixes the performance problem; I now get the same frame rate, if not a little better, with the OSG lights. There was a problem in my support for switching between point sprites and points. I was confused about what the array of view options (sprites, enhanced lights, etc.) did with respect to this new patch ... I tried a few different combinations and could really figure it out. It would be nice to get this all sorted out and make it clear what the different options do or don't do and how they play together. It would also be nice to somehow maintain some sort of form of the original sprite based lighting as a fall back for people that don't have the HP to run the new OSG lights. The Use Point Sprites for Runway Lights and Enhanced Runway Lighting should work as expected. Runway light distance attenuation doesn't do anything because that is always active. As far as the original lights go, they don't have the blink sequence support of the new lights. Perhaps people with old hardware could give this new patch a try and see if it is adequate? Another thing that would be nice is to be able to keep the sprite based mechanism so that lights have fuzzy (rather than hard) edges as they are rendered. That should work. If it doesn't, can you send me the details of your hardware? Thanks, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbhiveDhWHdXrDRURAuP5AKCGMA5f0Ju4oDHhd6r5ke8FCDBWUACfXAoB 7Voa8DKysEHCnjjYgJbPUmU= =B6vF -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Moore wrote: I have a new patch at http://www.bricoworks.com/moore/lightpt2.diff Try http://www.bricoworks.com/moore/lightpt3.diff instead. A last-minute typo disabled point sprites. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbieQeDhWHdXrDRURAh5+AJ92XWhS4ZrLNJL7n1+crmJE23ROnQCfVm9Z 1OGTOqkSKRfputw4tYVUFSg= =HmxZ -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
On Thursday 30 November 2006 01:36, Tim Moore wrote: Try http://www.bricoworks.com/moore/lightpt3.diff instead. A last-minute typo disabled point sprites. This is still faster with point sprites reenabled? I do not want to remove the old implementation that was happening completely on the GPU in favour to an CPU based one if we end up slower. Anyway, can we keep the old implementation instead of just a plain OpenGL point based one. That means the old one that used triangles that are backface culled and draw points for the front side where two of them are transparent? Like I stated before in some private mails I would like to have the osg version only as an alternative to the old implementation if it is faster than the GPU/triangle based one. May be not exactly the old implementation but an implementation that does nothing on the CPU but does all lightging decisions on the GPU. And as also told before I would like to have an other alternative for the main usage where we still do that light intensity decision - together with more advanced light texturing dependent on fog density, distance and other neat parameters - on the *GPU*. Just use a vertex shader for the view direction dependence of the light and fragment shaders for more advanced halos. That will require a newer OpenGL implementation and for that I believe we need to keep a lighting version for older boards. Also this all happens in the *GPU*. That has the advantage that it is probably way faster and even if it is about at fast as on the CPU, it does not block CPU cycles that can equally well be spent for more advanced physical models or better AI traffic or whatever we need to do on the CPU. So on the longer term I will favour that shader based approach as default as long as the GPU supports it. For that we still need some factory methods that will provide now the old implementation or the osg::LightPoint based one and later when I have the time to merge my tests into simgear the shader based one. So we need to he able to decide between implementations based on capabilities of the GPU and settings from the user anyway. Can we set up together such an infrastructure and put the old triangle based approach as other alternative below? In the long term I believe that we will reduce that back to two alternatives again. The shader based and one of the low end card capable ones - whichever of the low end card implementation is faster. For that decision we need *both* up again and optimized well ... I will look at the current patch that weekend. Greetings Mathias - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: What kind of performance change (better? worse?) did you observer? Thanks, Curt. Well, not so great. At SFO at night in the UFO I see a decrease from about 60fps with the existing lights to 43 with the OSG version. I suspect the slowdown is very dependent on processor speed; I hadn't noticed it on another computer using the debug builds. Although the distance attenuation does look nicer, you might want to hold off integrating my patch until I investigate further :) Tim On 11/27/06, Tim Moore [EMAIL PROTECTED] wrote: Curtis Olson wrote: Hi Tim, Are these osg point lights a replacement for the existing mechanism or an additional mechanism that leaves the existing approaches intact? Thanks, Curt. They are a replacement. The good blink sequence support and attractive appearance of the OSG light points, coupled with performance problems I've seen in the past with rendering polys in point mode, led me to go with the OSG light points all the way. For the point sprites I am using the existing simgear sprite texture. Tim On 11/26/06, Tim Moore [EMAIL PROTECTED] wrote: Here's an implementation of airport runway lighting, including VASI / PAPI lights, using OSG light points. You can choose to use point sprites or OpenGL points at runtime, and the enhanced runway lighting function is supported. The relative intensities of the lights will probably have to be tweaked. Tim - - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFbNAReDhWHdXrDRURAk8BAKDXysuG4roUv0Em3rH/RDa7GpxEegCgwTDz H9X6O63KsJ37YnIUo3OzfjY= =KSRM -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
Hi Tim, Are these osg point lights a replacement for the existing mechanism or an additional mechanism that leaves the existing approaches intact? Thanks, Curt. On 11/26/06, Tim Moore [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's an implementation of airport runway lighting, including VASI / PAPI lights, using OSG light points. You can choose to use point sprites or OpenGL points at runtime, and the enhanced runway lighting function is supported. The relative intensities of the lights will probably have to be tweaked. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFaiYyeDhWHdXrDRURAn+CAJ0Tf6nMRkoO9ZIVHCbPtW5TJN0h1gCgs+vr C6tAnsaa7P2Flr2Ug9bcx+c= =j9Tv -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: Hi Tim, Are these osg point lights a replacement for the existing mechanism or an additional mechanism that leaves the existing approaches intact? Thanks, Curt. They are a replacement. The good blink sequence support and attractive appearance of the OSG light points, coupled with performance problems I've seen in the past with rendering polys in point mode, led me to go with the OSG light points all the way. For the point sprites I am using the existing simgear sprite texture. Tim On 11/26/06, Tim Moore [EMAIL PROTECTED] wrote: Here's an implementation of airport runway lighting, including VASI / PAPI lights, using OSG light points. You can choose to use point sprites or OpenGL points at runtime, and the enhanced runway lighting function is supported. The relative intensities of the lights will probably have to be tweaked. Tim - - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFa3GHeDhWHdXrDRURAqo8AJ9o7Tjzrl1r/S+J8ZBRca40cVJ9FACfUtGL xUUOwUW26GX2lkxpPxvpuJM= =RqXo -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
What kind of performance change (better? worse?) did you observer? Thanks, Curt. On 11/27/06, Tim Moore [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis Olson wrote: Hi Tim, Are these osg point lights a replacement for the existing mechanism or an additional mechanism that leaves the existing approaches intact? Thanks, Curt. They are a replacement. The good blink sequence support and attractive appearance of the OSG light points, coupled with performance problems I've seen in the past with rendering polys in point mode, led me to go with the OSG light points all the way. For the point sprites I am using the existing simgear sprite texture. Tim On 11/26/06, Tim Moore [EMAIL PROTECTED] wrote: Here's an implementation of airport runway lighting, including VASI / PAPI lights, using OSG light points. You can choose to use point sprites or OpenGL points at runtime, and the enhanced runway lighting function is supported. The relative intensities of the lights will probably have to be tweaked. Tim - - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFa3GHeDhWHdXrDRURAqo8AJ9o7Tjzrl1r/S+J8ZBRca40cVJ9FACfUtGL xUUOwUW26GX2lkxpPxvpuJM= =RqXo -END PGP SIGNATURE- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
