Re: [Flightgear-devel] Patch v1 - Rain & Snow
Nicolas schrieb: > Hi, > > I propose my first tries... still much work to get a good > implementation. > > >From the README (into path) : > - > > This first try permits to add a basic snow and rain effects in using > particle from OSG. > > For the moment, the patch uses the METAR informations to enable / > disable rain or snow effects. (intensity of effects is : low, meddium, > high) > > For the next release of patch : > 1) Add the wind direction and velocity effect > 2) it's raining cats and dogs in my plane !!! (fixed this issue) > 3) I want to the density of effects depend on altitude. If I'm higher > than clouds layer, rain (or snow) is stopped... > 4) The particle effects have to depend on the camera position. > 5) If you have propositions... :) > > > Regards, > > Nicolas VIVIEN > > > > > Hi Nicolas, I tried your patch and it is very impressing! Although an early stage of work but I don't want to go back to the "old" rain display. It was very funny, although there was a lot of bad weather here in Germany recently, I could not find an airport with rain (nearby). So I used the "Thunderstorm" scenario (day and night). You are on the right way - another step forward for FlightGear. Thank you very much, looking forward for further improvements :-) Georg EDDW BTW: >> 5) If you have propositions... :) 2) it's raining cats and dogs in my plane !!! (fixed this issue) Not here - I got wet. Another one: sometimes the particles looked like rain, sometimes *a little* like snow (especially at night). This depends on the view (front or side view) and the flight-direction. I know, this is an early development stage but I just want to make this feed-back. Maybe you can make the particles a little smaller for rain? But these observations depend all on the "thunderstorm" scenario. I am still searching for an airport with "rain" METAR. And might be "snow", should this already make a difference in the display??? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery pager Compilation error
On Sunday 10 February 2008 18:10, Tim Moore wrote: > > I think you have an old version of OpenThreads around. > > Tim > Hi Tim, Yes, looks like that's what's happening. Thanks, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Mon, 11 Feb 2008 17:20:24 +0100 Georg Vollnhals <[EMAIL PROTECTED]> wrote: > Hi Syd, > > you know that I am not complaining? I am just feeling like a Beta-Tester > doing some helping work to improve the stuff. > If you agree with me, there are a lot of things to discuss - but I just > want to do it step for step. Oh i didn't consider it complaining :) > > The next one: > Did you see these tree areas, seems to be something like an ongoing > ecological desaster in FlightGear: > > http://home.arcor.de/vollnhals-bremen/EcologicalDesaster/ > > Any ideas? Yeah I get that too. The blank ground area is because when the new , better terrain textures were added , the equivalant winter textures weren't created ... I'm in the process of adding the missing winter textures The dead (leafless) trees are caused by scaling the tree texture down to 64 pixels in height , so the small, bare branches disappear , I'll have to redo those ones ... If you spot anything else let me know . Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Red Bull Air Race for FlightGear
Am Sonntag, 10. Februar 2008 14:57 schrieb Maik Justus: > That was my problem. I placed this file in my $FGROOT/data directory. > (Maybe this would be the better place for that? For no other extension I > had to install any data in the home directory. And the home directory is > not within the cvs-tree.) Good news, that it is working for you now. I am still thinking about making this a part of the base package or an extension to be downloaded separately. There is now a download link for the current development version of the EDGE 540 on my rbar page at http://www.t3r.de/fg/fgfs-rbar.html It is still under heavy construction, but you may already check it out and have some fun with it. But beware, it is nearly unlandable due to the lack of flaps or speedbrakes. The FDM needs some tweaking here and there... Please don't put it into CVS (yet) - there is to much work going on at the moment and I don't want to bother the CVS commiters to often. Enjoy - Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: When I'm not working on FG...
On Mon, 11 Feb 2008 13:48:48 + LeeE <[EMAIL PROTECTED]> wrote: > ...I sometimes work on 3D 'art' pictures. > > http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg > > Is my latest effort. > > There are a few aspects of it that I'd like to improve and I might > come back to it at some point, but it'll do for now. > > This image took ~9 hours to render (including post-processing global > illumination) using a six node (7 cpu) heterogenous > render 'smallholding' (it's not big or powerful enough to be called > a farm;) All Linux - CPU speeds between 350-1700 MHz. > > LeeE > Nice . I like this kind of art ... I usually do planetrise style images ... Hope you don't mind , it's now in my wallpaper folder :) Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch v1 - Rain & Snow
Hi, I propose my first tries... still much work to get a good implementation. >From the README (into path) : - This first try permits to add a basic snow and rain effects in using particle from OSG. For the moment, the patch uses the METAR informations to enable / disable rain or snow effects. (intensity of effects is : low, meddium, high) For the next release of patch : 1) Add the wind direction and velocity effect 2) it's raining cats and dogs in my plane !!! (fixed this issue) 3) I want to the density of effects depend on altitude. If I'm higher than clouds layer, rain (or snow) is stopped... 4) The particle effects have to depend on the camera position. 5) If you have propositions... :) Regards, Nicolas VIVIEN fg-patch.tar.gz Description: application/compressed-tar - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: When I'm not working on FG...
At Monday 11 February 2008 14:48:48 LeeE wrote: > ...I sometimes work on 3D 'art' pictures. > > http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg > > Is my latest effort. > > There are a few aspects of it that I'd like to improve and I might > come back to it at some point, but it'll do for now. > > This image took ~9 hours to render (including post-processing global > illumination) using a six node (7 cpu) heterogenous > render 'smallholding' (it's not big or powerful enough to be called > a farm;) All Linux - CPU speeds between 350-1700 MHz. > > LeeE Very nice, compliments :) Which kind of rendering SW? POVRay? Pietro - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
Syd&Sandy schrieb: > On Mon, 11 Feb 2008 03:47:26 +0100 > Georg Vollnhals <[EMAIL PROTECTED]> wrote: > > >> > > Hi Georg , the tree problem is because I created a set of 8 instead of 4 > trees per texture for the > coniferous trees , and the originally commented out parts of the material.xml > file probably still have > 4 > If you change that to 8 everything should be > fine ... I'm also adding winter textures that were missing from the > Terrain.winter folder but that's a bit more work , so it will take a while ... > Thank you, that helped. I found three entries with ">4>" and changed them. Now the "winter-trees" look fine (only coniferous found), normally. > I'm still getting a few strange things here but still testing ... > Cheers > Hi Syd, you know that I am not complaining? I am just feeling like a Beta-Tester doing some helping work to improve the stuff. If you agree with me, there are a lot of things to discuss - but I just want to do it step for step. The next one: Did you see these tree areas, seems to be something like an ongoing ecological desaster in FlightGear: http://home.arcor.de/vollnhals-bremen/EcologicalDesaster/ Any ideas? Regards Georg - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
--- Csaba Halász wrote: > On Feb 11, 2008 11:05 AM, Stuart Buchanan > wrote: > > > > I'm sure we can think of some more. > > > > If we could define these regions based on lat/lon (in an XML file?), FG > > could > set > > them, and they could be easily used within materials.xml. > > Needs more invasive changes to the code. The simple condition handling > I added just works at startup. Is that startup or initialization? If it is read during (re-)initialization, then I think it would be a good starting point. I would guess that most people's virtual flights start and end in the same continent. -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
On Monday 11 February 2008 13:59, Melchior FRANZ wrote: > * Thomas Förster -- Monday 11 February 2008: > > At least I think conservative is the right term. > > Oh, I didn't think that it was wrongly used. It's just that > the decision was meant to be reasonable for the case > based on logical considerations, and not the least on whether > it would be (seen as) conservative. And I found the fact that > a clear rendering bug is blamed on METAR or a "conservative" > decision there annoying. > > But I like the idea to make an educated guess based on > other METAR values, and I plan to implement that later > today. I'll use a large set of stored METAR messages with > specified (i.e. non- or M*) visibility to see which > elements (other than humidity) have a correlation with the > visibility. BTW: the biggest numbers that I found were > 110 miles (KMWN Mount Washington -- not in our DB -- but > there's a KHIE Mount Washington Rgnl!?). (That's assuming > that the 9000 km from HAAB were a mistake. ;-) > > m. 9000km - lol:) I think I'd suspect the 110 miles figure (if that's a ground level value) as well, not only because that's a lot of atmosphere to see through but also because of curvature. I tried a quick Google to see if I could find any rules/formulae for visibility due to atmospheric conditions but didn't hit anything. It'll be interesting if you can come up with rules or a formulae from your analysis of a large set of METAR data. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
Heiko Schulz wrote: > Another thing is, when I increase the visibility > manually I noticed with the last OSG-version that > there is a white surface in the sky - the blue sky > disapears, no stars. > > I noticed this when trying to get new screenshots in osg, I could no longer get a clear-day picture with the mountains in the background. When the fog factor was reduced so the mountains became visible, the sky turned white. Whereas in plib I could get a "perfect" picture without problem. Stewart - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
> But I like the idea to make an educated guess based on > other METAR values, and I plan to implement that later > today. I'll use a large set of stored METAR messages with > specified (i.e. non- or M*) visibility to see which > elements (other than humidity) have a correlation with the > visibility. BTW: the biggest numbers that I found were > 110 miles (KMWN Mount Washington -- not in our DB -- but > there's a KHIE Mount Washington Rgnl!?). (That's assuming > that the 9000 km from HAAB were a mistake. ;-) You might also take weather phenomena into account. When there is something like FG (fog) it is most likely that the poor visibility is limited to only the lower few hundret feet or so. There might be something like blown sand in some areas of the world that creates a poor visibility in a METAR in a perfect dry atmosphere without any clouds and perfect VMC (except for landing). Greetings, Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
* Thomas Förster -- Monday 11 February 2008: > At least I think conservative is the right term. Oh, I didn't think that it was wrongly used. It's just that the decision was meant to be reasonable for the case based on logical considerations, and not the least on whether it would be (seen as) conservative. And I found the fact that a clear rendering bug is blamed on METAR or a "conservative" decision there annoying. But I like the idea to make an educated guess based on other METAR values, and I plan to implement that later today. I'll use a large set of stored METAR messages with specified (i.e. non- or M*) visibility to see which elements (other than humidity) have a correlation with the visibility. BTW: the biggest numbers that I found were 110 miles (KMWN Mount Washington -- not in our DB -- but there's a KHIE Mount Washington Rgnl!?). (That's assuming that the 9000 km from HAAB were a mistake. ;-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OT: When I'm not working on FG...
...I sometimes work on 3D 'art' pictures. http://www.spatial.plus.com/V5/im_WoodenDream-001-006.jpg Is my latest effort. There are a few aspects of it that I'd like to improve and I might come back to it at some point, but it'll do for now. This image took ~9 hours to render (including post-processing global illumination) using a six node (7 cpu) heterogenous render 'smallholding' (it's not big or powerful enough to be called a farm;) All Linux - CPU speeds between 350-1700 MHz. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Mon, 11 Feb 2008 10:05:20 + (GMT) Stuart Buchanan wrote: > > I have been thinking for a while that it would be good to have some way > to have a finer granularity within materials.xml. > > For example: > - Towns and villages in different countries/continents are quite > different in terms of the buildings, and it would be good to reflect > this. > - Tropical forests are quite different from that of temperate climates > - I did a virtual flight over Denali recently, and due to the > limitations of the current terrain definitions, large parts of it were > "forest". I've wanted this for years. There's more, too. For instance, farmland looks different in different countries -- when we went to the more photorealistic textures a couple of years ago, we dumped a texture that I think Erik Hofman had created for farmland that, on one hand, looked less like a photo and more like art, but on the other hand, looked *much* more like farmland as you would see it in England and parts of northern Europe. And I remember Paul Surgeon creating one that looked *exactly* like farmland in places like Indiana/Illinois/Iowa, but not like in the western U.S. and definitely not outside the U.S. Middle Eastern/central Asian cities look different than western ones. And there ought to be different parts of cities -- the types of buildings you see in the inner city (and their frequency) should be different from the types you see in suburbs, and both sets should be different in different places around the world. The problem is . . . > I think that as well as a property defining the season, it would be > good to have a set of properties based on the geographical region, for > example: > > /sim/geography/continent (africa, europe...) > /sim/geography/climate (tropical, temperate, arctic...) > > I'm sure we can think of some more. > > If we could define these regions based on lat/lon (in an XML file?), FG > could set them, and they could be easily used within materials.xml. . . .I don't think defining by lat/lon is sufficient. I guess some of these issues could be improved that way; but lines of constant latitude or longitude aren't really correct, even for the ones they would improve. The region boundaries won't look realistic. The right way to do it is to use GIS data in TerraGear, and to expand the groundcover types coming out of TerraGear. Once upon a time, it was actually in the works to start creating those groundcover types/material definitions, in advance of actually labelling ground polys with them in TerraGear, so that people could experiment with setting them in fgsd; but I was gone for a while and I don't know what the status of any of that is now. -c -- Chris Metzler [EMAIL PROTECTED] (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear signature.asc Description: PGP signature - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
On Feb 11, 2008 11:05 AM, Stuart Buchanan <[EMAIL PROTECTED]> wrote: > > I'm sure we can think of some more. > > If we could define these regions based on lat/lon (in an XML file?), FG could > set > them, and they could be easily used within materials.xml. Needs more invasive changes to the code. The simple condition handling I added just works at startup. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
Am Montag 11 Februar 2008 schrieb Melchior FRANZ: > ... > > Think someone did a conservative choice here. > > Conservative? http://dict.leo.org/forum/viewWrongentry.php?idThread=427767&idForum=3&lp=ende&lang=de Sorry for the long url. Its in German too... At least I think conservative is the right term. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tree textures
--- Csaba Halász wrote: > On Feb 9, 2008 12:29 PM, Vivian Meazza <[EMAIL PROTECTED]> wrote: > > > > I would be pleasantly surprised if worked in materials.xml > > Here you go :) > > As a side effect, we could get rid of the ugly code that makes > "Terrain." out of "Terrain" at the expense of some more xml. > > I attached a patch against Syd's new materials.xml as well. This is fantastic - thank you very much! I have been thinking for a while that it would be good to have some way to have a finer granularity within materials.xml. For example: - Towns and villages in different countries/continents are quite different in terms of the buildings, and it would be good to reflect this. - Tropical forests are quite different from that of temperate climates - I did a virtual flight over Denali recently, and due to the limitations of the current terrain definitions, large parts of it were "forest". I think that as well as a property defining the season, it would be good to have a set of properties based on the geographical region, for example: /sim/geography/continent (africa, europe...) /sim/geography/climate (tropical, temperate, arctic...) I'm sure we can think of some more. If we could define these regions based on lat/lon (in an XML file?), FG could set them, and they could be easily used within materials.xml. -Stuart ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
--- Melchior FRANZ <[EMAIL PROTECTED]> schrieb: > * Heiko Schulz -- Monday 11 February 2008: > > Even with a visibility more than 30m I can't see > much impact. > > Well, 30m isn't much. No impact here, either. :-} > > > > * Stuart Buchanan -- Monday 11 February 2008: > > I'm sure you alreay know the answer : Make it a > property value in > > preferences.xml, defaulting to 10km :) > > That's a possibility. But I'd rather try to make a > guess based > on relative humidity and maybe other components of a > given METAR > message. Then we have more variability for the > case, and MP > machines still have the same weather (as long as > they are using > METAR weather and don't manually change visibility > via z/Z). This > could, of course, be coupled with a visibility-max-m > property. > > > > > Of course, the 12nm "island" may be due to an > assumption that > > the maximum visibility will be 10km, so it may not > just be case > > of replacing the constant... > > The "islang bug" has nothing to do with METAR. Not > directly, > anyway. We didn't change METAR in the fg/plib -> > fg/osg > transition. > > m. > > - Ha ha- Melchior tries to be funny - you know what I meant- 30 miles! But to compute the visibility from METAR sounds like a realistic way to simulate. HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
* Heiko Schulz -- Monday 11 February 2008: > Even with a visibility more than 30m I can't see much impact. Well, 30m isn't much. No impact here, either. :-} * Stuart Buchanan -- Monday 11 February 2008: > I'm sure you alreay know the answer : Make it a property value in > preferences.xml, defaulting to 10km :) That's a possibility. But I'd rather try to make a guess based on relative humidity and maybe other components of a given METAR message. Then we have more variability for the case, and MP machines still have the same weather (as long as they are using METAR weather and don't manually change visibility via z/Z). This could, of course, be coupled with a visibility-max-m property. > Of course, the 12nm "island" may be due to an assumption that > the maximum visibility will be 10km, so it may not just be case > of replacing the constant... The "islang bug" has nothing to do with METAR. Not directly, anyway. We didn't change METAR in the fg/plib -> fg/osg transition. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
--- Melchior FRANZ wrote: > * Thomas Förster -- Monday 11 February 2008: > > Note that METAR itself only codes visibility up to m. > > Only if it uses the 4-digit visibility code. But it can also be > something like "KEDW 110755Z 24006KT 45SM SCT250 04/M01 A3014" > where the visibility is 45SM ... 45 (statute) miles. > > > Everything above comes out of the report as too. [...] > > Yes, *iff* a four digit code is used, then means "more > than 10 km. > > > Think someone did a conservative choice here. > > Conservative? If we have to make something up because there is > no information, should we then take something that makes fgfs > crawl and look ugly, or rather something faster and prettier? > We chose the latter. What would you have done? I'm sure you alreay know the answer : Make it a property value in preferences.xml, defaulting to 10km :) Of course, the 12nm "island" may be due to an assumption that the maximum visibility will be 10km, so it may not just be case of replacing the constant... -Stuart ___ Support the World Aids Awareness campaign this month with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
--- Melchior FRANZ <[EMAIL PROTECTED]> schrieb: > * Thomas Förster -- Monday 11 February 2008: > > Note that METAR itself only codes visibility up to > m. > > Only if it uses the 4-digit visibility code. But it > can also be > something like "KEDW 110755Z 24006KT 45SM SCT250 > 04/M01 A3014" > where the visibility is 45SM ... 45 (statute) miles. > > > > > Everything above comes out of the report as > too. [...] > > Yes, *iff* a four digit code is used, then > means "more > than 10 km. > > > > > Think someone did a conservative choice here. > > Conservative? If we have to make something up > because there is > no information, should we then take something that > makes fgfs > crawl and look ugly, or rather something faster and > prettier? > We chose the latter. What would you have done? > > m. > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio > 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ Hi, after using my old pc, because my old one is crashed(can't boot)I noticed that the perfoamnce wit data paging is much better! Even with a visibility more than 30m I can't see much impact. Before data paging I never could use this range! I think we could change this - FGFS would looking a little bit more realistic and the perfomance issue is small now. With OSG Perfomance get better and better - why should we stay back from our possibilities? Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html Lesen Sie Ihre E-Mails jetzt einfach von unterwegs. www.yahoo.de/go - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
* Thomas Förster -- Monday 11 February 2008: > Note that METAR itself only codes visibility up to m. Only if it uses the 4-digit visibility code. But it can also be something like "KEDW 110755Z 24006KT 45SM SCT250 04/M01 A3014" where the visibility is 45SM ... 45 (statute) miles. > Everything above comes out of the report as too. [...] Yes, *iff* a four digit code is used, then means "more than 10 km. > Think someone did a conservative choice here. Conservative? If we have to make something up because there is no information, should we then take something that makes fgfs crawl and look ugly, or rather something faster and prettier? We chose the latter. What would you have done? m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying over an island
Am Sonntag 10 Februar 2008 schrieb Heiko Schulz: > ... > It seems to mee, that METAR is not used correctly. > METAR ssems alright to me, if in RL the visibility is > under 11nm, ti is in FGFS too. But above 11nm - FGFS > can't show this Note that METAR itself only codes visibility up to m. Everything above comes out of the report as too. In reality it is sometimes much higher (witnessed 50-60NM myself on a cold springday), sometimes not. Think someone did a conservative choice here. Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
