Re: [Flightgear-devel] git
Thorsten: I had an account and created a ssh key. Now it has a red cross below ready in gitorious. Something wrong with that? Now the fgdata clone should be on my pc alike the fgfs wiki or where? How to push or put a merge request?? 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.Are 850 already in git? Peter, I've also to adjust scenery height. Suisse04 scenery won't be GPL'd mainly because it uses different licences. In fact I didn't bother all authors about such, also because I don't like the idea of some people making money with freeware. Daniel Gauthier for example told me that it must be free of charge! Not GPL compatible then!... http://www.swissfir.org/downloads/Scenery/Gauthier/Gauthier.html Thanks and cheers Michael -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
- Mail original - Thorsten: I had an account and created a ssh key. Now it has a red cross below ready in gitorious. Something wrong with that? Now the fgdata clone should be on my pc alike the fgfs wiki or where? How to push or put a merge request?? If you cloned the official data repository on your own machine, you won't be allowed to push anything. What you have to do is to clone the repository in your own gitorious.org project and then clone that clone on your own machine. As it is your own project, you will be able to push into it and then submit merge requests. Regards, -Fred -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
On Thu, 29 Sep 2011, Frederic Bouvier wrote: If you cloned the official data repository on your own machine, you won't be allowed to push anything. What you have to do is to clone the repository in your own gitorious.org project and then clone that clone on your own machine. As it is your own project, you will be able to push into it and then submit merge requests. Now, before anyone unnecessarily goes through the pain of cloning fgdata again, you just need to add the git URL to your new personal clone at gitorious as a remote in your local fgdata clone to be able to push to gitorious. For example: git remote add g...@gitorious.org:~andersg/fg/anders-fgdata.git my-fgdata Stores the URL to my fgdata clone at gitorious under the name my-fgdata in my local git clone of fgdata. (You want the gitorious SSH URL for your repository) git push my-fgdata my-branch:master Pushes the local branch named my-branch to my-fgdata (i.e. my clone of fgdata at gitorious) where the branch will be named master. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
On 28 Sep 2011, at 21:14, Curtis Olson wrote: I suppose it would make sense to grep through the code, but as far as I know, the primary uses of the visibility value is to properly set the OpenGL fog parameters and determine how many rings of tiles to load centered on the current location. From a software engineering perspective, it would be great to have a centralised, explicit place where visibility is managed, and especially the purpose of visibility - since what's needed for scenery loading vs 'fog' (atmosphere effects) vs weather loading vs AI / multiplayer ranges may not all agree, but most of those things currently look at the global visibility property and make some guesses, or apply some heuristics based on that number. Unfortunately, going through the code to find out what will break, is an ugly job - as you have probably realised. In the short term, I think most systems need a 'how far away do I conceivably need to load / simulate items' metric - not necessarily in meters - but really that should be dependent on the observer position of course. Hopefully ThorstenB will have some comments, since he's the person who most recently touched the tile-loading code, which is by far the most sensitive thing (in terms of system performance) for how we compute visibility. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git
On Thu, 29 Sep 2011, Anders Gidenstam wrote: For example: git remote add g...@gitorious.org:~andersg/fg/anders-fgdata.git my-fgdata Oups, that should be git remote add my-fgdata g...@gitorious.org:~andersg/fg/anders-fgdata.git Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scenery Creation/TerraGear problems
I apologize in advance considering I'm in a very complaining mood at the moment. I've just compiled 4 square degrees of scenery around the Minneapolis/St. Paul area in an attempt to figure out whether or not my Alaska scenery creation process worked on places in the lower 48 states. Fortunately, the answer is yes, the process works and the scenery built successfully. Minneapolis is kind of boring minus the lakes, but the scenery also looks like the upper midwest, and there are a lot of interesting rivers to follow. Unfortunately, I've run into problems with what I'll call the swirlies and the staircases. The first is the swirlies - I'm sure people have seen these before, where someone builds a dense road network and all of a sudden all the textures are stretched into oblivion. I'll call them the swirlies because up close the texture pattern looks like a swirl. The second is the staircases. Basically, the fan constructions don't include any sort of centroids, so for large glaciers the elevation literally goes up in steps as the fans walk up. This staircases effect also causes an issue in mountainous valleys. Sometimes the fan will not pick up part of the canyon floor, instead going from peak to peak. This can have a very pronounced effect when you are flying, and there are instances of this in the Alaska scenery as well (and others, but this is the cause). My question is, what can I do from a data point of view to fix these problems? I'm using v.generalize instead of v.clean in my GRASS workflow this time around, which is much faster and gives better results - but it doesn't clean any vertices. As a result, for both Alaska and Minneapolis sceneries, there are a number of strange constructions with the irregular mesh. I know how the irregular mesh is formed. I've designed a couple golf courses for Links 2003 using a similar method and dropping a centroid or a few really can help the wireframe - unfortunately I don't have access to the actual wireframe scenery structure, nor is this a recommended way to edit the files. I could also use v.clean and remove some of the vertices, which in turn would reduce the number of fans. I know there is a limit on fans or vertices? with .btg files, but this scenery is only of a medium-high quality, and compared to other sceneries I've created I'm not sure there's really a need to do this other than for performance. Plus, I'm loathe to run v.clean because pruning became very, very slow sometime in between GRASS 5 and GRASS 6.4, even though v.generalize doesn't remove any vertices, which is a problem. Oh, and Minneapolis/St. Paul scenery is available for anyone who wants it, but please email me personally because it's buggy. (However there is one very nice grass-runway airport which is placed on the cliff of a river - technically a bug but taking off is a fun challenge!) 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 - I get 1 FPS because I can't change visibility - is there a way to disable this feature from loading on startup from the command line? Cheers John -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
Am 21.09.11 07:59, schrieb Alex Perry: 12. ... who is missing from the list? I just decided to start with russian airspace, because of this one here: http://premier.gov.ru/eng/events/news/9704/ Cheers, Yves -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
On 29.09.2011 10:21, James Turner wrote: Hopefully ThorstenB will have some comments, since he's the person who most recently touched the tile-loading code, which is by far the most sensitive thing (in terms of system performance) for how we compute visibility. Well, I have little to add. I can just confirm your and Curt's descriptions: yes, the tile loader reads the visibility property. When is has increased above a certain threshold (or when the position has moved into another area), it starts loading more scenery. And it always requests all tiles within the range defined by visibility (limited to the max-lod range though). It could be changed easily to watch for some other property - such as a specific ground visibility property, when that's provided. But yes, loading scenery is a major performance/memory factor - so we shouldn't be loading much more scenery than we do now - unless the fundamental concepts are also improved (such as better LOD support for scenery tiles). And it'd be rather complicated to implement any other tile loading method instead of the current concept of loading all tiles within a certain range. The tile loader lives in a simple 2D world. It knows nothing about elevation of certain tiles etc. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric haze modelling
On Thu, Sep 29, 2011 at 1:10 PM, ThorstenB wrote: Well, I have little to add. I can just confirm your and Curt's descriptions: yes, the tile loader reads the visibility property. When is has increased above a certain threshold (or when the position has moved into another area), it starts loading more scenery. And it always requests all tiles within the range defined by visibility (limited to the max-lod range though). It could be changed easily to watch for some other property - such as a specific ground visibility property, when that's provided. But yes, loading scenery is a major performance/memory factor - so we shouldn't be loading much more scenery than we do now - unless the fundamental concepts are also improved (such as better LOD support for scenery tiles). And it'd be rather complicated to implement any other tile loading method instead of the current concept of loading all tiles within a certain range. The tile loader lives in a simple 2D world. It knows nothing about elevation of certain tiles etc. Just to add a couple more bits of information. The tile loader knows (or can compute) the exact dimensions of the tiles. I thinks in terms of square rings if that makes sense. There is the tile which you are over right now. There is a ring of 8 tiles surrounding your current tile. There is a ring of 16 tiles surrounding that and a ring of 24 tiles surrounding that. 3x3 = 9 - the inner tile = 8. 5x5 = 25 - the 3x3 block = 16, etc. So the tile loader loads the 'current tile' which you are over the top of it and proceeds to load as many surrounding 'rings' as needed to cover the current visibility distance. As Thorsten B. points out though ... there is a memory/performance/disk-io price when loading tiles. And if we are pushing scenery complexity at the same time as pushing visibility out, this price will grow exponentially ... so it's worth paying attention to. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Query about groundradar Instrument module
Hi, I am trying to familiarise myself with Flightgear's source code so that I may try and contribute. I am currently looking at the 'groundradar' instrument module and there is something within that is causing me some confusion. Essentially, there is a 'texture' declared as follows: static const char* default_texture_name = Aircraft/Instruments/Textures/od_groundradar.rgb; This is then used by the following method: void GroundRadar::createTexture(const char* texture_name) in the following way: FGTextureManager::addTexture(texture_name, getTexture()); Now all is good at this point until I go and look for this file, which i expected to find in data/Aircraft/Instruments/Textures/, however, this file does not appear there, nor does it appear anywhere else on my filesystem either. I thought, well maybe the code is not actually using this texture, since its a 'default_texture', however, when i change the name to point to something else which also does not exist, then, the once black background becomes white! So I am assuming that this file MUST be somewhere, but I have no idea where it is, can anyone assist me with this? Thanks Robbo -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On Wed, 2011-09-28 at 09:09 +0100, James Turner wrote: On 25 Sep 2011, at 09:10, James Turner wrote: 2. After about 1hour of flying, FG seems to go into a endless loop; the sound continues to play, however the screen is frozen (goes to black if you minimise then re-maximise it), and all network activity drops off (ie: you disappear from multi-player) I ran it with gdb and notice the following stack; We've seen issues like that before, when _geo_inverse_wgs_84 is used over large (eg, half the planet) distances. The workaround / fix has been to switch range checks of this nature to convert coordinates to cartesian space (earth centred) and then use cartesian distance - not appropriate for navigation, but fine for a range check (and quicker too). I just pushed a tweak to make this code work in cartesian space, thanks for the bug report. James Thanks James, that looks like it fixed that up, I re-flew the same route and no problems. cheers S. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ 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
On Thu, Sep 29, 2011 at 10:32 PM, Robbo robbo_b...@hotmail.com wrote: Hi, Essentially, there is a 'texture' declared as follows: static const char* default_texture_name = Aircraft/Instruments/Textures/od_groundradar.rgb; FGTextureManager::addTexture(texture_name, getTexture()); Now all is good at this point until I go and look for this file, which i expected to find in data/Aircraft/Instruments/Textures/, however, this file does not appear there, nor does it appear anywhere else on my filesystem either. I thought, well maybe the code is not actually using this texture, since its a 'default_texture', however, when i change the name to point to something else which also does not exist, then, the once black background becomes white! So I am assuming that this file MUST be somewhere, but I have no idea where it is, can anyone assist me with this? That is the name of the generated dynamic texture, the od_ prefix is supposed to signal this for owner drawn, see od_gauge.cxx/hxx. The call you found actually registers it with the texture manager so that other components (notably models) can refer to it by that name. -- Csaba/Jester -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ 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
Robbo, I just went through the process of adding this texture to the A380 after reading the source code, for when you are taxiing around an airport. The output texture file is in essence a virtual file. So the texture is created in memory and given a path reference (it's never actually persisted to the file system), So when you add the instrument to the aircraft, you must exactly use the virtual path, I never knew this was possible, it's a simple but highly effective idea. S. On Thu, 2011-09-29 at 21:32 +0100, Robbo wrote: Hi, I am trying to familiarise myself with Flightgear's source code so that I may try and contribute. I am currently looking at the 'groundradar' instrument module and there is something within that is causing me some confusion. Essentially, there is a 'texture' declared as follows: static const char* default_texture_name = Aircraft/Instruments/Textures/od_groundradar.rgb; This is then used by the following method: void GroundRadar::createTexture(const char* texture_name) in the following way: FGTextureManager::addTexture(texture_name, getTexture()); Now all is good at this point until I go and look for this file, which i expected to find in data/Aircraft/Instruments/Textures/, however, this file does not appear there, nor does it appear anywhere else on my filesystem either. I thought, well maybe the code is not actually using this texture, since its a 'default_texture', however, when i change the name to point to something else which also does not exist, then, the once black background becomes white! So I am assuming that this file MUST be somewhere, but I have no idea where it is, can anyone assist me with this? Thanks Robbo -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ 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
On Thursday 29 September 2011 14:32:54 Robbo wrote: Hi, I am trying to familiarise myself with Flightgear's source code so that I may try and contribute. I am currently looking at the 'groundradar' instrument module and there is something within that is causing me some confusion. Essentially, there is a 'texture' declared as follows: static const char* default_texture_name = Aircraft/Instruments/Textures/od_groundradar.rgb; This is then used by the following method: void GroundRadar::createTexture(const char* texture_name) in the following way: FGTextureManager::addTexture(texture_name, getTexture()); Now all is good at this point until I go and look for this file, which i expected to find in data/Aircraft/Instruments/Textures/, however, this file does not appear there, nor does it appear anywhere else on my filesystem either. I thought, well maybe the code is not actually using this texture, since its a 'default_texture', however, when i change the name to point to something else which also does not exist, then, the once black background becomes white! So I am assuming that this file MUST be somewhere, but I have no idea where it is, can anyone assist me with this? Thanks Robbo Definitely not my area, but... The hint for me was the call 'createTexture()' opposed to load or get Texture(). I believe we are doing a render-to-texture thing. If you grep for Aircraft/Instruments/Textures/od_groundradar.rgb in fgdata/Aircraft you get many hits like: ATC/radar-screen.xml: pathAircraft/Instruments/Textures/od_groundradar.rgb/path So, if I understand things correctly, the models are asking for a texture by name, which is created by GroundRadar::createTexture() instead of being loaded from disk. Ron -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
