Re: [Flightgear-devel] Replacement fpr mpserver01.flightgear.org
Hi Matt, According to pigeon mpserver02 uses about 10-15 GByte per day. Regards, Oliver On Wednesday 07 April 2010 12:52:16 Mattt wrote: Oliver, To assist with my ambition for laziness, can you give me a round figure for monthly bandwidth? I may be able to assist - note, however, that my host is in AU. It is on several redundant 100mb ethernet connections, though ;-) kyle keevill wrote: I may be able to do this. Gotta rumage through my stuff here. The floors still open for all. On Apr 7, 2010, at 5:40 AM, Oliver Schroeder wrote: Bandwidth is not easy to measure. I did some testing this morning and came to these results: ~ 50 kbit/sec per directly connected client ~ 3 kbit/sec per idle relay server (same as direct connected clients for active servers) With about 20 active users about ~ 650 kbit/sec over all with all known public servers as relays. Maximum users I have seen was about 70 users. So I think a 10 MBit line will provide sufficient bandwith for current usage. (DSL is not a good choice as the line will easily be filled). CPU and memory usage is not significant at all. I can not tell what bandwidth is needed for the mapserver, but it should be quit moderate as well. regards, Oliver On Tuesday 06 April 2010 19:22:08 Pete Morgan wrote: Whats the bandwidth involved? This is a pretty loaded server ? pete Oliver Schroeder wrote: Hello list. Unfortunatly my sponsor for mpserver01 will quit his contract for the hardware. Thus I am in search for a replacement. If you are interrested in offering a unix host for hosting fgms (the server software, which does not need root access), please drop me an email. I'm also willing to continue to administer this server if you don't want to administer it yourself. The same applies to mpmap01.flightgear.org which is currently hosted on the same hardware. Any comments and especially offers are welcome Regards, Oliver -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Kyle Keevill kyle...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Cheers, Mattt. SpotSafe - WiFi Hotspot solution - http://spotsafe.net There are only 10 kinds of people. Those who understand binary, and those that don't... -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev
Re: [Flightgear-devel] Normal map shader example - c172p
Hi Stuart, - Stuart Buchanan a écrit : Hi All, I've just updated the c172p to make use of the bumpspec Effect for a bump-map. I've still to get the rivet separation right, but the effect so far is rather pleasing: http://www.nanjika.co.uk/flightgear/fgfs-screen-004.png Glad to see the effect is used. I noticed the bump is reverted on one axis. In a previous thread, I wrote : I use the GIMP normal map plug-in to create my normal maps. Here are two example. A bump : http://frbouvi.free.fr/flightsim/gimp-normalmap-bump.png A hole : http://frbouvi.free.fr/flightsim/gimp-normalmap-hole.png They are created from the same height field image. Reds should point to the bottom right and greens should points to the top left. More precisely: #FF7F7F points to the right #7FFF7F points to the top #007F7F points to the left #7F007F points to the bottom These are the only two realistic combinations. Remember that for OpenGL the origin of the image is the bottom left when the origin of an image is the top left, so that's why an axis should be reverted. Looking closely at the wing map : http://frbouvi.free.fr/flightsim/gimp-normalmap-c172.png It appears that reds are pointing to the top right and greens to the bottom left. You may need to check the 'Invert Y' box in order to get them right. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Replacement fpr mpserver01.flightgear.org
Oliver, Ouch... But I thought so... The requisite bandwidth would cost a substantial amount for me :-( Oliver Schroeder wrote: Hi Matt, According to pigeon mpserver02 uses about 10-15 GByte per day. Regards, Oliver On Wednesday 07 April 2010 12:52:16 Mattt wrote: Oliver, To assist with my ambition for laziness, can you give me a round figure for monthly bandwidth? I may be able to assist - note, however, that my host is in AU. It is on several redundant 100mb ethernet connections, though ;-) kyle keevill wrote: I may be able to do this. Gotta rumage through my stuff here. The floors still open for all. On Apr 7, 2010, at 5:40 AM, Oliver Schroeder wrote: Bandwidth is not easy to measure. I did some testing this morning and came to these results: ~ 50 kbit/sec per directly connected client ~ 3 kbit/sec per idle relay server (same as direct connected clients for active servers) With about 20 active users about ~ 650 kbit/sec over all with all known public servers as relays. Maximum users I have seen was about 70 users. So I think a 10 MBit line will provide sufficient bandwith for current usage. (DSL is not a good choice as the line will easily be filled). CPU and memory usage is not significant at all. I can not tell what bandwidth is needed for the mapserver, but it should be quit moderate as well. regards, Oliver On Tuesday 06 April 2010 19:22:08 Pete Morgan wrote: Whats the bandwidth involved? This is a pretty loaded server ? pete Oliver Schroeder wrote: Hello list. Unfortunatly my sponsor for mpserver01 will quit his contract for the hardware. Thus I am in search for a replacement. If you are interrested in offering a unix host for hosting fgms (the server software, which does not need root access), please drop me an email. I'm also willing to continue to administer this server if you don't want to administer it yourself. The same applies to mpmap01.flightgear.org which is currently hosted on the same hardware. Any comments and especially offers are welcome Regards, Oliver -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Kyle Keevill kyle...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Cheers, Mattt. SpotSafe - WiFi Hotspot solution - http://spotsafe.net There are only 10 kinds of people. Those who understand binary, and those that don't... -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling,
Re: [Flightgear-devel] Normal map shader example - c172p
Hi All, I've just updated the c172p to make use of the bumpspec Effect for a bump-map. I've still to get the rivet separation right, but the effect so far is rather pleasing: http://www.nanjika.co.uk/flightgear/fgfs-screen-004.png Like most of the other shader effects, this looks better in-sim than in a screenshot. In particular the rivets on the cowling when viewed from the cockpit are rather nice when turning. I've also written a wiki article to help others interested in using this shader: http://wiki.flightgear.org/index.php/Howto:_Use_The_Normal_Map_Effect_in_A ircraft I'm interested in other people's performance experience with this shader. The normal maps are rather large, though they compress down very well. Nice work, thanks for the wiki. It cleared some things for me. Development is currently so fast, it's hard to keep up! Torsten -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Replacement fpr mpserver01.flightgear.org
Hi Oliver, If mpserver02 is using 10-15 Gigabytes a day, do we know what data the other servers are using? I'm just wondering what percentage of the 10-15 gig is due to people being too lazy to connect to the most appropriate mpserver. If the above theory is correct, it would be a good reason not to have a server as called mpserver02 to force those users to a more appropriate server. Regards George On Thu, Apr 8, 2010 at 4:15 PM, Oliver Schroeder f...@o-schroeder.de wrote: Hi Matt, According to pigeon mpserver02 uses about 10-15 GByte per day. Regards, Oliver On Wednesday 07 April 2010 12:52:16 Mattt wrote: Oliver, To assist with my ambition for laziness, can you give me a round figure for monthly bandwidth? I may be able to assist - note, however, that my host is in AU. It is on several redundant 100mb ethernet connections, though ;-) kyle keevill wrote: I may be able to do this. Gotta rumage through my stuff here. The floors still open for all. On Apr 7, 2010, at 5:40 AM, Oliver Schroeder wrote: Bandwidth is not easy to measure. I did some testing this morning and came to these results: ~ 50 kbit/sec per directly connected client ~ 3 kbit/sec per idle relay server (same as direct connected clients for active servers) With about 20 active users about ~ 650 kbit/sec over all with all known public servers as relays. Maximum users I have seen was about 70 users. So I think a 10 MBit line will provide sufficient bandwith for current usage. (DSL is not a good choice as the line will easily be filled). CPU and memory usage is not significant at all. I can not tell what bandwidth is needed for the mapserver, but it should be quit moderate as well. regards, Oliver On Tuesday 06 April 2010 19:22:08 Pete Morgan wrote: Whats the bandwidth involved? This is a pretty loaded server ? pete Oliver Schroeder wrote: Hello list. Unfortunatly my sponsor for mpserver01 will quit his contract for the hardware. Thus I am in search for a replacement. If you are interrested in offering a unix host for hosting fgms (the server software, which does not need root access), please drop me an email. I'm also willing to continue to administer this server if you don't want to administer it yourself. The same applies to mpmap01.flightgear.org which is currently hosted on the same hardware. Any comments and especially offers are welcome Regards, Oliver -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Kyle Keevill kyle...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Cheers, Mattt. SpotSafe - WiFi Hotspot solution - http://spotsafe.net There are only 10 kinds of people. Those who understand binary, and those that don't...
Re: [Flightgear-devel] Normal map shader example - c172p
Am Donnerstag, den 08.04.2010, 00:13 +0100 schrieb Stuart Buchanan: Hi All, I've just updated the c172p to make use of the bumpspec Effect for a bump-map. I've still to get the rivet separation right, but the effect so far is rather pleasing: http://www.nanjika.co.uk/flightgear/fgfs-screen-004.png Like most of the other shader effects, this looks better in-sim than in a screenshot. In particular the rivets on the cowling when viewed from the cockpit are rather nice when turning. I've also written a wiki article to help others interested in using this shader: http://wiki.flightgear.org/index.php/Howto:_Use_The_Normal_Map_Effect_in_Aircraft I'm interested in other people's performance experience with this shader. The normal maps are rather large, though they compress down very well. I've tested a bit and noticed that regarding size, the resolution of the normalmap doesn't matter. An image of 4096x4096 has nearly the same size than a 2048x2048 scaled version of the same image (which looks rather ugly in-sim btw,). However this is the case when the image is scaled before applying the normalmap filter. If the resulting normalmap gets scaled, the smaller resolution image is even larger in filesize than the original. The striking thing with using the shader is that it is now possible to have smaller image files for liveries as now only the colour is needed. Details can now be done in the shader. This reduces the lag while selecting different liveries. Greetings -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Detlef Faber http://www.sol2500.net/flightgear -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On 8 Apr 2010, at 03:06, Peter Brown wrote: Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. KJFK, runway 31L - mpmap ILS course; 301 degrees Flightaware ILS approach plate; 315 degrees. I have not looked at the 850 airport format, but is there a way in any of the apt.dat or nav data to specify ILS approach data accurately? Or is this a question for Pigeon, to see about using a different data list? Currently the heading data is misleading - it would be better to not have it shown than have it incorrect in my opinion. I didn't even know MPMap had this feature, but the problem is *not* the data in apt.dat or nav.dat - the localizers (excluding installations with an offset localizer, like the old Kai-Tek approach) are aligned with the true runway centreline, and don't know anything about the published or magnetic runway heading. I guess (having just written similar code for the Map dialog ILS display) that the issue is with a numerical heading value displayed for the ILS, on the MPMap - which as you should probably should account for magnetic variation - but I'm pretty sure this has to be fixed in the mpmap code. All of the above is with the caveat that I didn't know this feature existed in MPMap - it's also not what I would recommend to shoot an ILS - I mean, you'd *never* fly an ILS approach without the correct plate to hand, right? Right? :) Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Normal map shader example - c172p
Detlef Faber wrote: The striking thing with using the shader is that it is now possible to have smaller image files for liveries as now only the colour is needed. Details can now be done in the shader. This reduces the lag while selecting different liveries. Good to know, I might want to apply it to the F-16 then. Thanks for the hint. Erik -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Replacement fpr mpserver01.flightgear.org
On Wednesday 07 April 2010 12:52:16 Mattt wrote: Oliver, To assist with my ambition for laziness, can you give me a round figure for monthly bandwidth? According to pigeon mpserver02 uses about 10-15 GByte per day. Regards, Oliver I may be able to assist - note, however, that my host is in AU. It is on several redundant 100mb ethernet connections, though ;-) kyle keevill wrote: I may be able to do this. Gotta rumage through my stuff here. The floors still open for all. On Apr 7, 2010, at 5:40 AM, Oliver Schroeder wrote: Bandwidth is not easy to measure. I did some testing this morning and came to these results: ~ 50 kbit/sec per directly connected client ~ 3 kbit/sec per idle relay server (same as direct connected clients for active servers) With about 20 active users about ~ 650 kbit/sec over all with all known public servers as relays. Maximum users I have seen was about 70 users. So I think a 10 MBit line will provide sufficient bandwith for current usage. (DSL is not a good choice as the line will easily be filled). CPU and memory usage is not significant at all. I can not tell what bandwidth is needed for the mapserver, but it should be quit moderate as well. regards, Oliver On Tuesday 06 April 2010 19:22:08 Pete Morgan wrote: Whats the bandwidth involved? This is a pretty loaded server ? pete Oliver Schroeder wrote: Hello list. Unfortunatly my sponsor for mpserver01 will quit his contract for the hardware. Thus I am in search for a replacement. If you are interrested in offering a unix host for hosting fgms (the server software, which does not need root access), please drop me an email. I'm also willing to continue to administer this server if you don't want to administer it yourself. The same applies to mpmap01.flightgear.org which is currently hosted on the same hardware. Any comments and especially offers are welcome Regards, Oliver -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Kyle Keevill kyle...@gmail.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Cheers, Mattt. SpotSafe - WiFi Hotspot solution - http://spotsafe.net There are only 10 kinds of people. Those who understand binary, and those that don't... -- i.A. Oliver Schröder Systemadministrator/-programmierer Network/Engineering IP-Services Versatel West GmbH Unterste-Wilms-Straße 29 D-44143 Dortmund Fon: 0231-399-4479 Fax: 0231-399-4491 oliver.schroe...@versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Geschäftsführer: Dr. Hai Cheng, Dr. Max Padberg, Joachim Bellinghoven
Re: [Flightgear-devel] mpmap ILS data
On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown smoothwater...@adelphia.net wrote: Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. I'm not familiar with mpmap, but that's not a problem for FlightGear itself - the localizer directions are all specified in Navaids/nav.dat.gz in degrees true, independently of any runways they might be associated with (not all localizers are attached to a runway, and even when they are, the direction might be 10 degrees off from the runway). Here's the example for BTV (where I've flown the localizer in real life as well as in FlightGear): 12 44.4652 -073.14009400342 11030 18 0.000 IVOE KBTV 33 DME-ILS But then, the vast majority of runways don't have localizers. Perhaps the map is just trying to show an extended runway centreline, and the person who designed the app mixed up magentic and true heading. The Airports/apt.dat.gz file does give runway headings in degrees true, not degrees magentic, so there's no need to mess around with magnetic deviation. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Reflection Shader- Very Nice but....
Hi Vivian, -objects with this shader are emissive when ambient- correction set higher than zero. That is indeed a bug. I have a fix, but I'm having difficulty in balancing out the blue in the ambient light. Hopefully I can upload it soon. Bugfix in cvs. The colour and light balance isn't exactly the same as before, so you might need to fix up your offsets. Thanks, works so far as I can see! -fresneliness seems not to work- when setting less/equal than 1 I can see the fresnelookup.png on the object Er - yes - that's what the fresnel effect is meant to do, but fresneliness = 0 should turn it off. Seem to do what it says on the tin here. Oh- o.k. Maybe you should name it a bit different. Under fresneliness I did understand the fresnel effect. I thought the FresnelLookupMap was to help to set the fresnel-effect. So I was mistaken ;-) -the same with rainbowiness, but I guess here it is whished (Nice for cockpit windows on airliners! ) Yes - should have a little for aluminium, some more for glass. Rainbowiness = 0 turns it off Yep, would look great on our airliners! It is right, that refl_correction set to 1 makes the whole object totally reflective (without using the reflectionmap), while setting to -1 nonreflective? And all values less than 1 seems to use the map again? Yes - refl_correction simply adds or subtracts from the overall reflectiveness. You can saturate the map. Solution - don't do it :-) I played a bit with it yesterday- I understand the use of it now much better. Very nice that we have different ways to controll the effect. Would it be hard, if the alpha channel of the map will be included in the base color map instead an extra file, to make use of it instead? (Would make Livery-select much more interesting) Possible to do, but then you couldn't use transparency in the texture is you wanted to. At least that is my understanding. I think the correct solution is to use a property to set the map path - on my todo list. Wow- that would sound great! Pretty impressive screenshots, btw. Pretty impressive shader, I would say! I have updated the upcoming Newsletter, feel free to add or delete things I've written about. Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 8:08 AM, David Megginson wrote: On Wed, Apr 7, 2010 at 10:06 PM, Peter Brown smoothwater...@adelphia.net wrote: Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Makes it tough to line up with the ILS, unless you pull info from an outside source (airnav, flightaware, etc) for each arrival airport. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. I'm not familiar with mpmap, but that's not a problem for FlightGear itself - the localizer directions are all specified in Navaids/nav.dat.gz in degrees true, independently of any runways they might be associated with (not all localizers are attached to a runway, and even when they are, the direction might be 10 degrees off from the runway). Here's the example for BTV (where I've flown the localizer in real life as well as in FlightGear): 12 44.4652 -073.14009400342 11030 18 0.000 IVOE KBTV 33 DME-ILS But then, the vast majority of runways don't have localizers. Perhaps the map is just trying to show an extended runway centreline, and the person who designed the app mixed up magentic and true heading. The Airports/apt.dat.gz file does give runway headings in degrees true, not degrees magentic, so there's no need to mess around with magnetic deviation. All the best, David David, yes, as I have as well. The localizer for 33 as you listed above is on a 326 heading per the approach plate, but the mpmap shows ILS data as the runway heading in degrees - as if for users to use as the ILS data. I'm not sure what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) I believe James is correct in that it's probably a question for Pigeon, whom I believe created and maintains the mpmap data. James, You are correct as well, in real life you don't shoot an approach without the plate. (Okay..., you shouldn't...) :) ButFG does have to walk that thin line between sim and reality, and until users get to the point of full reality immersion, they will use the data presented to them for ease of use (if nothing else). While I enjoy FG immensely due to all of the developers work, I doubt I'll be strapping on an approach plate until I'm sitting in a full blown simulator cockpit with the door shut. :) So, I guess I'll see if Pigeon responds about perhaps re-formatting the mpmap code to use actual approach headings instead of runway headings. For anyone that isn't aware of the data presented, I recommend you take a look. It has more info than you may realize, and it helps the user find airports, navaids, and more. Airport data includes the degree of GS (for those rare abnormally high approaches), localizer frequency, and if a CAT 1,2, or 3 approach. For most of the users this is a wealth of information. A side benefit is from an ATC point of view for FG events, you can visually see how well the pilots are flying the localizer. Peter :) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown smoothwater...@adelphia.net wrote: David, yes, as I have as well. The localizer for 33 as you listed above is on a 326 heading per the approach plate, but the mpmap shows ILS data as the runway heading in degrees - as if for users to use as the ILS data. I'm not sure what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) The plates give the heading in degrees magnetic; the data file gives it in degrees true. That's still a degree off (BTV is 15W, IIRC), but it's pretty close, and nav.data.gz may be based on old data. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 1:29 PM, David Megginson wrote: On Thu, Apr 8, 2010 at 11:32 AM, Peter Brown smoothwater...@adelphia.net wrote: David, yes, as I have as well. The localizer for 33 as you listed above is on a 326 heading per the approach plate, but the mpmap shows ILS data as the runway heading in degrees - as if for users to use as the ILS data. I'm not sure what the 342 in the navaid file is referring to unless it's elevation?... elev. is 335, course is 326. (ref: http://flightaware.com/resources/airport/BTV/IAP/ILS_DME+RWY+33/pdf) The plates give the heading in degrees magnetic; the data file gives it in degrees true. That's still a degree off (BTV is 15W, IIRC), but it's pretty close, and nav.data.gz may be based on old data. All the best, David I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Thanks, Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
Peter Brown wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. or from the navaids. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. They are certainly going to keep the true heading in the navaid file, because the magnetic heading is changing permanently and therefore is a moving target. The navaids collection is meant to place the navaids at their proper location in an unambiguous way - which obviously is the true heading. BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter still processing. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
Martin Spott wrote: BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter BTW, the figures for magnetic declination are based on: http://www.ngdc.noaa.gov/geomag/WMM/DoDWMM.shtml Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 4:09 PM, Martin Spott wrote: Peter Brown wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. or from the navaids. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. They are certainly going to keep the true heading in the navaid file, because the magnetic heading is changing permanently and therefore is a moving target. The navaids collection is meant to place the navaids at their proper location in an unambiguous way - which obviously is the true heading. BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter still processing. Cheers, Martin. -- I have no reason to take it out, but I see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from either, if you don't want to add it to the navaids file. Is there any reason not to? Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Again, I haven't used mpmap, but are you certain it is trying to display an ILS localizer, and not just an extended runway centreline? You're right, of course, that it might have messed up true vs. magnetic (especially if the developer was working somewhere with very little magvar, and wouldn't have noticed during testing). Our files list actual runway headings in degrees true as well, so the only thing I can think is that the developer just took the runway *number* and converted it to a heading. All the best, David -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 4:58 PM, David Megginson wrote: On Thu, Apr 8, 2010 at 2:00 PM, Peter Brown smoothwater...@adelphia.net wrote: I see. So that brings us back to magnetic vs true, as I was originally referring to. But, that's somewhat irrevelant as it _appears_ the mpmap is sourcing the data from the actual runway placement. My opinion is there should be an data file with the correct info to be displayed, and it seems logical for it to be the navaid file, but we'd need to add a line if they want to keep the true heading. Again, I haven't used mpmap, but are you certain it is trying to display an ILS localizer, and not just an extended runway centreline? You're right, of course, that it might have messed up true vs. magnetic (especially if the developer was working somewhere with very little magvar, and wouldn't have noticed during testing). Our files list actual runway headings in degrees true as well, so the only thing I can think is that the developer just took the runway *number* and converted it to a heading. All the best, David No, I'm not sure of any of it. I was thinking I had posed it as a question whose answer was readily available - I wasn't trying to debate it if that's how it came across. I like functionality that the majority of users find useful, since I classify myself as one of those. :) My guess is that as Martin said, he/she probably is grabbing data from the navaids file. To show you what mpmap provides, here's a few links. Note the two heading info boxes when you have the ILS beam on - as if to display Runway heading and Approach heading, since the first info box also lists the runway number, ILS CAT #, and GS degrees. http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50447PM.png http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50447PM.png http://s512.photobucket.com/albums/t325/barefootr/?action=viewcurrent=Screenshot2010-04-08at50518PM.png Thanks, Peter-- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
Peter Brown wrote: On Apr 8, 2010, at 4:09 PM, Martin Spott wrote: BTW, feel free to use this service if your're looking for slightly more complete airfield data: http://mapserver.flightgear.org/ms?Service=WFSVersion=1.0.0request=GetFeatureTypename=apt_airfieldMaxFeatures=1Filter=FilterPropertyIsEqualToPropertyNameicao/PropertyNameLiteralKBTV/Literal/PropertyIsEqualTo/Filter I have no reason to take it out, but I see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from either, if you don't want to add it to the navaids file. Is there any reason not to? Yup, as already said, the navaid file is meant to carry unambiguous data (by design), while magnetic heading depends on the date and is therefore unsuitable for the given purpose. This is not about personal preferences, this is about the design of a file format, a written spec is available here: http://data.x-plane.com/file_specs/XP%20NAV810%20Spec.pdf If you see no reason to not compile a list of approach plate data that the mpmap can retrieve usable data from, feel free to go ahead ;-) In fact, my primary target is to maintain this database of airfield-, navaid- and a lot of other datasets in a 'generic' representation which is suitable for automated processing, but my domain is not to provide neat user interfaces (others are, apparently, more skilled to do that). People, including those who are running MPMap servers, are invited to use it, if it fits their needs, various formats are available (GML, GeoJSON and the like). If you're in need of a human-readable one-shot database table dump, please let me know. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On Apr 8, 2010, at 5:23 PM, Martin Spott wrote: If you're in need of a human-readable one-shot database table dump, please let me know. Cheers, Martin. -- That'd be great, send it my way. Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Normal map shader example - c172p
Frederic Bouvier wrote: Glad to see the effect is used. I noticed the bump is reverted on one axis. In a previous thread, I wrote : I use the GIMP normal map plug-in to create my normal maps. Here are two example. A bump : http://frbouvi.free.fr/flightsim/gimp-normalmap-bump.png A hole : http://frbouvi.free.fr/flightsim/gimp-normalmap-hole.png They are created from the same height field image. Reds should point to the bottom right and greens should points to the top left. More precisely: #FF7F7F points to the right #7FFF7F points to the top #007F7F points to the left #7F007F points to the bottom These are the only two realistic combinations. Remember that for OpenGL the origin of the image is the bottom left when the origin of an image is the top left, so that's why an axis should be reverted. Looking closely at the wing map : http://frbouvi.free.fr/flightsim/gimp-normalmap-c172.png It appears that reds are pointing to the top right and greens to the bottom left. You may need to check the 'Invert Y' box in order to get them right. Thanks for the help. I've updated the normal maps, and included this information in the wiki article. -Stuart -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: mpmap ILS approach data
First email never arrived to the list Might be a question for Pigeon, rather than apt.dat or nav.dat Begin forwarded message: From: Peter Brown pe...@smoothwatersports.com Date: April 4, 2010 10:36:05 AM EDT To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: mpmap ILS approach data Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment in taxidraw. This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. Example at KBTV, runway 15 - mpmap ILS course 130.92 degrees Flightaware ILS approach plate, 146 degrees. KJFK, runway 31L - mpmap ILS course; 301 degrees Flightaware ILS approach plate; 315 degrees. I have not looked at the 850 airport format, but is there a way in any of the apt.dat data to specify ILS approach data accurately? Currently the heading data is misleading - it would be better to not have it shown than have it incorrect in my opinion. Thanks! Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On 04/07/2010 07:06 PM, Peter Brown wrote: Perhaps this has been brought up before, but I see that the ILS beam data for each airport on the mpmap is derived from the runway alignment (as verified in taxidraw). That sounds like a problem. This doesn't allow for magnetic deviation, and therefore all the course headings are incorrect. That is the wrong way to think about the problem. This is basically a geodesy problem. It should be worked using true headings, true lat/lon, et cetera. The question of magnetic variation should never come up in this context. I have not looked at the 850 airport format, but is there a way in any of the apt.dat or nav data to specify ILS approach data accurately? The navaid data is accurate. The 830 and 850 formats are equivalently accurate. Or is this a question for Pigeon, to see about using a different data list? There is no need for that. The existing nav.dat data is plenty good enough. The existing FGFS code handles this correctly, except in the case of reversible ILS installations. Perhaps mpmap could just clone this code. Also, the code to handle reversible ILSs in a reasonable way exists in the sport model. It has been available for many months, as previously discussed. Let me know if you are interested. Or take a look at http://gitorious.org/~jsd/fg/sport-model/commits/sport This is an issue for more than 20% of all ILS installations in the US and UK ... and more than 10% worldwide. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
