[Flightgear-devel] Fwd: svn LSTZ.threshold.xml seems wrong!
Hi all, Errata: It was an error in my script that showed bad values from 2.10 apt.dat.gz... Sorry! Using the computed center of the single runway it now shows 46.55,7.38, which agrees with the site AND with x-plane 10.00 ;=)) as it should... But it does show zero displacements and stopways, which I think is an error! To help fix LSTZ.threshold.xml I got my script to calculate and generate the xml from x-plane 10.00 apt.dat, which does have displacements... 17 46.5557604156107 7.3803149373204 172.632939426832 30.193488 0 35 46.5489074392642 7.38159918524379 352.633943174119 28.614624 0 And a view of the runway in Google Maps shows there are displacements on that runway... http://maps.google.com/?ll=46.551881,7.383134&spn=0.012528,0.025513&t=h&z=16 Hope this helps to 'fix' the svn scenery data soonest... Regards, Geoff. Forwarded Message > From: Geoff McLane > To: flightgear-devel > Subject: svn LSTZ.threshold.xml seems wrong! > Date: Mon, 08 Apr 2013 20:20:10 +0200 > > Hi all, > > A little bit of amusement... ;=)) > > I just happened to be looking at the mapserver > svn ICAO.threshold.xml files with a perl script, > and found a very, VERY interesting case ;=)) > > Most files range in size from 468 bytes EG42, > to 6,201 bytes KEDW.threshold.xml... that may > be all ok... > > BUT then you have the massive 18 MB LSTZ ;=() > That is 18,367,661 bytes to be exact! > > Researching a little, LSTZ (Zweisimmen) airport > is a local airport (light traffic) with 1 runway, > '35' and '17'... at lat,lon 46.5525022,7.380560. > from one site... > > Then LSTZ in our 2.10 release apt.dat.gz shows a > crazy 32.68,-114.63!!! > > While x-plane 10.00 shows 46.55,7.38, which agrees > with the site... > > data/Scenery/Airports/L/S/T/LSTZ.threshold.xml > contains about 88,760 runways ;=) > > But to be fair only 56 different runways markings... > But ryw '17' and '35' are listed 225 times each... > Rwy '18' and '36' are listed 25,921 times each! > > The bounding box covering ALL runway coordinates > given in the file is approximately lat,lon min > 1.99,-178.31 to max 65.81,145.88 which is MOST of > the world... well at least the Northern half... > > Something is really screwy with this file ;=)) > > Hope someone can find the time to 'fix' it a > little... > > I really wonder what fgfs does with this file > when it reads it... > > HTH. > > Regards, > Geoff. > -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud detail range and faint clouds
On Tue, Apr 9, 2013 at 8:12 AM, Renk Thorsten wrote: > The problem are faint Cirrus-type clouds which use 2-3 sprites, or in extreme > cases just a single one (they have a transparency of more than 90% and are > really just a faint haze modulation). Here, dropping half of the sprites > essentially mutilates the appearance of the cloud. I have just comitted some > very nice undulatus pattern distributions, and dropping half (actually in > practice about 2/3 of the sprites seem to go...) just changes the appearance > of the sky drastically. IIRC the sprites are distributed on the surface of a squashed sphere, which might explain why with small numbers of sprites more than 50% might disappear. Or it might be a bug. > I think ideally a way to drop sprites only for certain types of clouds and > protect the faint ones would be desirable. Do we for instance have an unused > attribute slot where the number of sprites used to generate the cloud can be > passed? I'll add it to my TODO list :) Presumably making cirrus clouds after more sprites doesn't make for very realistic clouds because of the size of the cloud structures? -Stuart -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Cloud detail range and faint clouds
I want to bring a potential issue of the cloud detail range system to everyone's attention. What it does it reducing sprite count by dropping sprites in the back half of the cloud if the cloud is more than a configurable distance away, so faraway clouds have less overall density. This works great for Cu-type clouds which are generated from 20-30 relatively opaque sprites - faraway Cu clouds still look decent with half, and in 50 km distance would work well with a single sprite, as this is still very opaque. The problem are faint Cirrus-type clouds which use 2-3 sprites, or in extreme cases just a single one (they have a transparency of more than 90% and are really just a faint haze modulation). Here, dropping half of the sprites essentially mutilates the appearance of the cloud. I have just comitted some very nice undulatus pattern distributions, and dropping half (actually in practice about 2/3 of the sprites seem to go...) just changes the appearance of the sky drastically. I am unsure of what to do about it. The detail range works as advertized, and is clearly useful for reasonable performance, but currently the user is unaware that he's even in light cloud cover not seeing Cirrus patterns which should be there. So it's mainly an awareness issue, setting the cloud detail range to a large value makes everything re-appear. I think ideally a way to drop sprites only for certain types of clouds and protect the faint ones would be desirable. Do we for instance have an unused attribute slot where the number of sprites used to generate the cloud can be passed? * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of questions
Thanks Fred, this pretty much addresses all my questions. > Light objects are built in simgear/scene/tgdb/pt_lights.cxx > There effect is built in C++ in the getLightEffect function. It is not > configurable as it is now. Ideally, this function should be replaced > by a lookup in the material file to find a configurable effect. > But I didn't thought about the implications of doing so. Okay, then I'm not going crazy and can't really address this from the effect/shader side without touching the core. Could I request implementing a lookup as a non-urgent feature request? This is needed to get true low visibility scenes rendered properly, but I think not among the most pressing problems. > Precipitations use the OSG particle effect. I don't thing it is something > configurable as the shader is coded in OSG C++ code. Maybe this is > something we should try rewriting in order to make the lighting > different. The implementation of the effect is in > simgear/environment/precipitation.cxx Well... maybe let's just leave it as it is - personally I am not much bothered by the precipitation lighting, and this sounds like a non-trivial issue to fix. > Problem : it consumes GPU memory even if the technique requiring > the extra attributes is not selected Hm, I see Can a geometry shader potentially compute the curvature and pass it on? I mean, having a triangle with adjacency info must be good for something like this, right? Stuart: > I don't think there's a sensible way to generate additional trees at > 50-100m. With the changes described above, the overall memory > occupancy of trees should go down, so perhaps it won't matter as much? I was thinking fern, grass, undergrowth,... - these would have a density ~100 times higher than trees, so even just storing the coordinate point if it is created at tile creation time would be a major drain, and the whole thing would only remain manageable if really only the close vicinity is stored - which means it needs to be created on the fly as you approach an area. * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
