Re: [Flightgear-devel] git
Hi Michael, On 29 Sep 2011, at 08:44, Michael Sgier wrote: Durk: I've only seen some lone hangars with terrasync but no probably not all as they are for 850 format. As HB-GRAL stated some airports are way off in old 810 format, so using a custom start or tower view location from my groundnetworks might put you anywhere. But I've even had a dispute with Robin, so I've to check back 850 airport locations as soon as they're in git. If you have committed apt.dat files, to robin peel than I think that we could consider committing your ground networks to the terrasync repository. We currently have already quite a few (if not most) ground networks in the scenery that are based on future improvement of the scenery (in anticipation of the improved scenery generation process that Martin is putting a lot of effort into). So, if you have contributed new apt.dat info that would be used in this buidl process then it would be okay. But, I suspect that your ground networks contain parking information only? I would rather see fully developed ground networks, that can also be used for AI purposes. So, in the end, I would recommend that instead of committing these data to the fgdata repository, you bundle them with your own scnery distribution instead (i.e. you in addition to the Terrain/ and Objects/ directories, you'd provide an additional Airports/ directory in your package. FlightGear 2.4.0 should be able to read the parking data when you include the new scenery folder in your path. Cheers Durk-- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
Durk Talsma wrote: If you have committed apt.dat files, to robin peel [...] That's quite interesting. As far as I understood from Michael's various rants, he doesn't license his work under the GPL - please correct me if I'm wrong. On the other hand, you automagically license under the GPL by the act of submissing to Robin. Unfortunately Robin's v8.10 file, the format which we're still using, has been unmaintained for three years now, therefore, if I'm correct about the licensing, Michael's effort is pretty pointless, whichever route we take: Either we're not permitted to use it because of his incompatible licensing or we can't because Robin's v8.10 file is unmaintained. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
Martin ur a jerk. I've told to have submitted to 850 airports maintained by Robin. Pls read before rant about things you have no clue of. Durk, sure I can also add AI if you can give me an example groundnetwork.For now, I took lszh as pattern. --- On Fri, 9/30/11, Martin Spott martin.sp...@mgras.net wrote: From: Martin Spott martin.sp...@mgras.net Subject: Re: [Flightgear-devel] git To: flightgear-devel@lists.sourceforge.net Date: Friday, September 30, 2011, 10:05 AM Durk Talsma wrote: If you have committed apt.dat files, to robin peel [...] That's quite interesting. As far as I understood from Michael's various rants, he doesn't license his work under the GPL - please correct me if I'm wrong. On the other hand, you automagically license under the GPL by the act of submissing to Robin. Unfortunately Robin's v8.10 file, the format which we're still using, has been unmaintained for three years now, therefore, if I'm correct about the licensing, Michael's effort is pretty pointless, whichever route we take: Either we're not permitted to use it because of his incompatible licensing or we can't because Robin's v8.10 file is unmaintained. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
Michael Sgier wrote: Martin ur a jerk. I know :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
Durk, I only saw now the lszh ai. How should I create such for other airports? Martin, I've no problem releasing all on GPL but I won't go asking all authors for permission nor be responsibly for any violations.Anyone having all permissions, feel free to integrate my Suisse04 airports in fgfs. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
J. Holden wrote: I apologize in advance considering I'm in a very complaining mood at the moment. From my perspective that's ok. We've been doing experiments with detailed land cover data and (OSM-) roads for about five years now - the first sample was built for LinuxTax 2006 - and I know how frustrating this swirlie effect could be. Yet there's no solution I'd be able to provide. Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
J. Holden wrote: PS - I only get around 3-6 FPS on this brand new laptop(!), and I'm finding with 2.4 simply launching fgfs --airport=KMSP --aircraft=ufo loads up local weather/real-time weather, which is terrible for a simple scenery flyover test on a poorly performing computer Yup, we (Torsten any myself) noticed the same while performing a semi-public demo last weekend. That's quite annoying, indeed. In general, local_weather is supposed to be inactive by default as set in 'preferences.xml': http://mapserver.flightgear.org/git/gitweb.pl?p=fgdata;a=blob;f=preferences.xml#l1249 I have not yet found out why it's still enabled at startup. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Query about groundradar Instrument module
Hi, Thanks for your replies with regards to this subject. It is all starting to make some sense now. If I understand correctly then, the C++ module generates an in-memory texture that the xml files reference for displaying within the OSG tree. This texture is being continually re-generated to provide a 'dynamic texture'! Can I assume that this this is the standard way to generate dynamic graphical information on screen? Essentially what I am looking to do is create some instruments of my own with some detailed generation of graphical entities that are being continually updated. I am therefore assuming that a 'dynamic texture' is the way to go with this. If there is another way, perhaps better, then I am open to suggestions! Regards, Robbo -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On 30 Sep 2011, at 11:56, Martin Spott wrote: Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm A very useful description, yes! James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Mon, Sep 12, 2011 at 3:55 PM, Thorsten Renk wrote: 3) Antishading If you can provide the parameters of a cloud that is exhibiting the problem, that would be most useful. Okay, I've decided over the weekend that I'll make my current code available this week, because there's so much new stuff in which is not related to the transition to the new rendering system (some new textures, the detailed cloud-terrain interaction model, ...) that it may even be interesting for a 2.4 user. (Apologies if I've missed this already) Are you planning put this into git? So the new routines will be off by default, but editing a simple flag in the code will switch them on and then you can study the problems in situ. 4) Fading in poor visibility Making it a function of visibility should be the way forward. I think that's what the gl_Fog.density is supposed to represent, so it may simply be a question of modifying the function further. Perhaps it shouldn't be exp()? Okay, I'll try to come up with a function which works for that. I guess exp(-d/d0) is the correct parametric form, just d0 should be changed to a function d0(visibility-m), but I should be able to find a solution if we agree that this is what we want to modify. 5) Specify top and bottom shade I'm thinking that we need a top, middle and bottom shade, as the current model shades only from the middle of the cloud downwards. I see - then let's do it like this. I've got a merge request for simgear in the merge queue to add parameters for min/max bottom/middle/top/shade flighting factors. Also, I remember I asked this already, but you weren't quite sure then and the answer you guessed turned out not to be correct: What property determines the speed at which a given layer drifts? It gets set correctly when I initialize Local Weather with constant winds, but I'm not sure if it gets updated when I allow interpolated winds. I've been thinking of doing Lenticularis clouds by simply assigning them to a different, unmoving layer - I think that'd be pretty cool. I've had another look. The property is /environment/wind-speed.kt However, the layer only gets updated when the layer height (/environment/clouds/layer[n]/elevation-ft) is subsequently updated. A similar thing happens with the wind direction. -Stuart -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
All that weird stuff is quite easy to explain. The binary .btg scenery format uses 16 bit integers as indices for the vertex, normal, texture coordinate lists. At one point we were using signed 16 bit integers, but I'm pretty sure we sneakily changed the flightgear btg loader to use unsigned 16 bit ints. So this changed the original limitation of a max of 32,768 vertices/texture coords/normals, etc. up to 65,535. However, I don't know if the terragear-cs tools ever got this fix on the scene generation side. So if your scenery exceeds these limits, this is exactly what you will see. The ultimate solution will be to expand the btg format to 3 or 4 byte integers -- but that will again require changes in the terragear-cs tools as well as changes in the flightgear btg loader. Conveniently we have a versioning system in the btg format so we can extend the format and maintain backwards compatibility if we want. The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. There may be other ways to tackle this problem too ... maybe the btg format emitter could detect if the size exceeds the threshold of the current format and output just the tiles that require the extended format in the extend format. (Sorry it's late friday, I hope that makes sense.) :-) Curt. On Fri, Sep 30, 2011 at 8:54 AM, James Turner zakal...@mac.com wrote: On 30 Sep 2011, at 11:56, Martin Spott wrote: Hah, I managed to find the web page I've been searching for weeks, Bruce did a pretty nice writeup of the problem: http://www.cullam.com/flightgear.htm A very useful description, yes! James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. Ten years ago 16 Bit hurt much more than 32 Bit nowadays... And, wouldn't a compressor (tgz, bz2, ...) solve that issue, at least for distribution (trafficwise)? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery Creation/TerraGear problems
On Fri, Sep 30, 2011 at 4:22 PM, joac...@gmx.de wrote: Am Fri, 30 Sep 2011 16:10:39 -0500 schrieb Curtis Olson curtol...@gmail.com: The downside is that this index is used so much in the scenery files that going to a larger int size will have an immediate corresponding proportional impact on the btg sizes of all the files. Ten years ago 16 Bit hurt much more than 32 Bit nowadays... And, wouldn't a compressor (tgz, bz2, ...) solve that issue, at least for distribution (trafficwise)? That could very well be true ... and I don't think it would be a huge coding change ... but it should be done in a way that bumps up the btg version number and picks a new packet id so as to maintain backwards compatibility with all the existing scenery out there. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
