[Flightgear-devel] Local Weather - backward compatibility
Please note, the check for features.can_disable_environment == 1 is gone now. It doesn't make any sense there. In a current GIT, none of the checks make any sense, because current GIT always has all the features. On the other hand, the purpose of the compat_layer.nas is to provide compatibility of the weather to the last stable release - so when 2.4 is out, I will remove all compatibility checks, but as time goes on new ones will be added - which again allow you to run later versions on 2.4, but give GIT users all the new shining features. I can't really maintain two separate versions for last stable and current GIT - but I can maintain one version which works for both with the help of the compat layer. I fear that it'd just gets a mess if you start removing feature checks in the compat layer on GIT while I don't do it in my version intended also for distribution through the Forums. May I suggest to remove all the feature checks for the intended release branch (if simply to get rid of the messages) and set all features to 1 there, but to leave the management of feature checks in the development branch to me? I think that's least likely to create chaos. Cheers, * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Default 3d clouds in Local Weather
I've finally (I guess you all know the feeling of too much other stuff to do...) managed to start some tests with Stuart's Nasal interface for 3d cloud generation. Right now there is only a very rough placement structure and no real management (no removal, no distinction of cloud size, all same textures, no evolution,...). Basically, it works as advertized: http://www.phy.duke.edu/~trenk/pics/3dclouds-lw.jpg (it's not abundantly visible in the pic, but the layer shown differs from a normal layer in that it doesn't extend over the ocean, so the cloud position distribution is computed using the Local Weather MC code) In performance tests, I've been unable to see a significant effect (the default 3d clouds were maybe 5% better - but since we're comparing different number of cloudlets and different texture resolution, it's not clear to me what that actually means), I didn't notice any difference in tile building time (that's currently for Cu clouds dominated by terrain probing anyway) - but cloud movement in the wind is for free. I can't easily convert the whole system (texture sheets are not ready), but I'll write a parallel system for managing cloud generated with this technique and convert the system to that over time. Some issues: * naturally the clouds obey the visibility range as specified in the rendering dialog - which isn't far enough for my purposes. Can I simply override that number by a setprop() (will it snap back if someone opens the menu?) or is there a better way? * where's the switch to remove the boundary wrapping of the layer? * what property determines the visible motion? When I created the layer using Local Weather, clouds were moving with corrent heading and possibly also windspeed - so I assumed that it's wind settins as specified in /environment/ . However, I then switched Local Weather off, used the property browser to set windspeed to zero and assume the clouds would then stop - they didn't however. So I don't understand what I need to set to get the correct behaviour. * for layered clouds, I really would need the z-rescaling parameter *after* the rotation matrix has been applied (there's no way to do without, you're losing performance quadratically with area, so cloudlets need to be large without making layers ridiculously thick) - can we extend the parameters to be passed to the shader by that? Otherwise, I think this is very promising, and might be ready in a few months... * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. Sounds good! Another one might be Vostok-1. It eats up 166MB and has only three commits. Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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 Thu, Aug 4, 2011 at 8:15 AM,wrote: I've finally (I guess you all know the feeling of too much other stuff to do...) managed to start some tests with Stuart's Nasal interface for 3d cloud generation. Right now there is only a very rough placement structure and no real management (no removal, no distinction of cloud size, all same textures, no evolution,...). Basically, it works as advertized: http://www.phy.duke.edu/~trenk/pics/3dclouds-lw.jpg Glad you've managed to get the initial placement working In performance tests, I've been unable to see a significant effect (the default 3d clouds were maybe 5% better - but since we're comparing different number of cloudlets and different texture resolution, it's not clear to me what that actually means), I didn't notice any difference in tile building time (that's currently for Cu clouds dominated by terrain probing anyway) - but cloud movement in the wind is for free. Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. Hopefully I can improve the terrain probing to make a real difference in tile building time. I can't easily convert the whole system (texture sheets are not ready), but I'll write a parallel system for managing cloud generated with this technique and convert the system to that over time. That sounds like a very sensible approach. Some issues: * naturally the clouds obey the visibility range as specified in the rendering dialog - which isn't far enough for my purposes. Can I simply override that number by a setprop() (will it snap back if someone opens the menu?) or is there a better way? Yes, you can just use setprop. However, currently the slider maximum is 20km, so if the user opens the Rendering Dialog and then presses OK, it'll be reset to 20km. We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). However, I'm not sure we want to be over-riding the user's explicit preferences here. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? * where's the switch to remove the boundary wrapping of the layer? Not implemented yet. As you've managed to get the general integration done, I'll try to get to it soon. * what property determines the visible motion? When I created the layer using Local Weather, clouds were moving with corrent heading and possibly also windspeed - so I assumed that it's wind settins as specified in /environment/ . However, I then switched Local Weather off, used the property browser to set windspeed to zero and assume the clouds would then stop - they didn't however. So I don't understand what I need to set to get the correct behaviour. From memory, it's from the appropriate /environement/layer[n]/ property. * for layered clouds, I really would need the z-rescaling parameter *after* the rotation matrix has been applied (there's no way to do without, you're losing performance quadratically with area, so cloudlets need to be large without making layers ridiculously thick) - can we extend the parameters to be passed to the shader by that? Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? Otherwise, I think this is very promising, and might be ready in a few months... Great. Let me know what else you need and I'll put it near the top of my FG todo list. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I wouldn't touch the Vostock right now, it might be taken as an afront by the author Alessandro Date: Thu, 4 Aug 2011 09:50:04 +0200 From: tors...@t3r.de To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. Sounds good! Another one might be Vostok-1. It eats up 166MB and has only three commits. Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Tim Moore wrote On Tue, Aug 2, 2011 at 11:39 AM, Francesco Angelo Brisa fbr...@gmail.com wrote: Any news about a possible separation of aircrafts data from the fgdata folder ? I am afraid this topic is sligtly falling into the forget about it folder :-( Cheers Francesco Some of the inertia -- on my part -- comes from the fact that the benefits are not visible until the end: until all the aircraft are removed from fgdata and fgdata is effectively regenerated through various git magic, the repository will still keep all the history, including any deleted files. However, we need to start somewhere. I had been thinking that the aircraft needed to be grouped into repos -- by theme, author, era, whatever -- but perhaps that is totally unnecessary. One thing (perhaps the only thing) that was nice about keeping aircraft in fgdata is that enforced synchronization between the aircraft and other common nasal and instrument files. However, if they are split out, maybe we will be forced to be more mature about backward compatibility, etc. So, let's choose an aircraft, preferably not one being considered for the base distribution, and suck it into its own repo. I'll perform and document the git magic, which uses git-filter-branch, to preserve history for an aircraft in the new repo. If this goes well, we'll do it with all the rest, build a new fgdata without aircraft, and drop the old one. Sound good? Any nominations? I favor the an2, which I like, has lots of textures and sounds, and which hasn't seen any recent activity. We have to start somewhere - the AN2 is as good a place as any - let's go for it. Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
Thorsten wrote -Original Message- From:.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] Sent: 04 August 2011 07:57 To: FlightGear developers discussions Subject: [Flightgear-devel] Local Weather - backward compatibility Please note, the check for features.can_disable_environment == 1 is gone now. It doesn't make any sense there. In a current GIT, none of the checks make any sense, because current GIT always has all the features. On the other hand, the purpose of the compat_layer.nas is to provide compatibility of the weather to the last stable release - so when 2.4 is out, I will remove all compatibility checks, but as time goes on new ones will be added - which again allow you to run later versions on 2.4, but give GIT users all the new shining features. I can't really maintain two separate versions for last stable and current GIT - but I can maintain one version which works for both with the help of the compat layer. I fear that it'd just gets a mess if you start removing feature checks in the compat layer on GIT while I don't do it in my version intended also for distribution through the Forums. May I suggest to remove all the feature checks for the intended release branch (if simply to get rid of the messages) and set all features to 1 there, but to leave the management of feature checks in the development branch to me? I think that's least likely to create chaos. We don't normally maintain 2 versions: we leave the last stable as is, and only work on the Git version. If it's too much work, or too confusing I would suggest you abandon the version intended to be distributed via Forums, since that is not how we usually conduct our business. Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
I wouldn't touch the Vostock right now, it might be taken as an afront by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-family 67 A320-family 72 MiG-15 79 767-300 101 p51d 133 IAR80 166 Vostok-1 Weigh in the number of commits: (from git log --oneline | wc -l) 2 767-300 2 CRJ700-family 3 A340-600 3 Vostok-1 4 Short-Stirling 10 D510 12 IAR80 13 A320-family 15 an2 44 MiG-15 97 F-8E-Crusader 179 p51d 269 f16 Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Regards, -Fred - Mail original - I wouldn't touch the Vostock right now, it might be taken as an afront by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-family 67 A320-family 72 MiG-15 79 767-300 101 p51d 133 IAR80 166 Vostok-1 Weigh in the number of commits: (from git log --oneline | wc -l) 2 767-300 2 CRJ700-family 3 A340-600 3 Vostok-1 4 Short-Stirling 10 D510 12 IAR80 13 A320-family 15 an2 44 MiG-15 97 F-8E-Crusader 179 p51d 269 f16 Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
We don't normally maintain 2 versions: we leave the last stable as is, and only work on the Git version. If it's too much work, or too confusing I would suggest you abandon the version intended to be distributed via Forums, since that is not how we usually conduct our business. That's precisely my point - at the expense of a few lines Nasal, it can be one version working with both last stable and current devel - which is why the code I distribute is as it is. This setup works fine until someone else doesn't commit the code as I prepared it but alters it before committing to GIT to get rid of the 40 or so extra lines which are only needed for compatibility with last stable. Then my code and the committed code are different, and I can't reasonably maintain that. I'm not suggesting how you should conduct your business, I'm telling about what I do and warning that if someone removes the compatibility lines before committing to GIT, he'll have to do it every time I update the code, because for the reasons given above my version will not have the lines removed. If you read the forums, you quite often come across disappointed users who'd like to test a new aircraft/feature/... shown there, but it doesn't run with last stable, although often a fix is often trivial (a single property with different name,...) - I don't see why we can't make things backward compatible as long as that's just such trivial issues, I prefer a happy userbase if it costs me nothing :-) Cheers, * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
Am 04.08.2011 08:57, schrieb thorsten.i.r...@jyu.fi: Please note, the check for features.can_disable_environment == 1 is gone now. It doesn't make any sense there. In a current GIT, none of the checks make any sense, because current GIT always has all the features. On the other hand, the purpose of the compat_layer.nas is to provide compatibility of the weather to the last stable release - so when 2.4 is out, I will remove all compatibility checks, but as time goes on new ones will be added - which again allow you to run later versions on 2.4, but give GIT users all the new shining features. Sorry, I was unclear. The computation of wind-from-down-fps can not be disabled at all, it is independent of the feature can_disable_environment. In the code before September 2010, this property was computed in the C++ core and was updated at frame-rate. From September 2010 up to a few days ago, this property was set only from within the local-weather code and from nowhere else (which was a bug). Today that property gets computed by a property rule (xml-based computation) and gets updated at frame rate. It is the sum of three properties(ridge, AI and local weather lift), the local weather code computes one of those three. It can do so whenever it wants to do and this does not depend on any feature. That's why I removed the condition check. Id did not make any sense in a past version, it did not while there was a bug and it does not today. I suggest to adjust your original version and adapt this change. Torsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
On Thursday 04 August 2011 11:36:48 Torsten Dreyer wrote: I wouldn't touch the Vostock right now, it might be taken as an afront by the author (*Shrugs*) Looking at disk size, this list might help making decision. (from du -ms *|sort -n) 47 an2 47 F-8E-Crusader 48 A340-600 50 f16 51 Short-Stirling 58 D510 65 CRJ700-family 67 A320-family 72 MiG-15 79 767-300 101 p51d 133 IAR80 166 Vostok-1 Weigh in the number of commits: (from git log --oneline | wc -l) 2 767-300 2 CRJ700-family 3 A340-600 3 Vostok-1 4 Short-Stirling 10 D510 12 IAR80 13 A320-family 15 an2 44 MiG-15 97 F-8E-Crusader 179 p51d 269 f16 Torsten The IAR80 has a separate repo, if that helps :). https://gitorious.org/iar80/iar80-repo -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather - backward compatibility
Sorry, I was unclear. The computation of wind-from-down-fps can not be disabled at all, it is independent of the feature can_disable_environment. Thanks for clarifying - that makes sense. Sorry for the confusion then. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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
Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. It's not been a fair comparison as such. Let me try building clouds from the same texture sheet (i.e. same texture resolution, same number of cloudlets) - that's the relevant measure. Also, don't forget the wind drift benefit - that's huge... We should change the maximum to whatever you feel is sensible (40km?), and leave the default as it is (20km). I think my current maximum is 45 km, and for much more one needs a different tile structure anyway, so if we could get 45 km that'd be nice. However, I'm not sure we want to be over-riding the user's explicit preferences here. I can turn it around and use the value specified here for the cloud visible range of the old system - if that's not too confusing. Perhaps we should look at integrating your routine to match a given fps value by adjusting cloud visibility range? Do we all agree that it makes sense to use cloud visibility range here, rather than random objects or such like? Yes, that's something I need to do. I think you've already implemented this in your codes. Can you point me at the best example shader/Effect? It's actually quite simple. You have: // Do the matrix multiplication by [ u r w pos]. Assume no // scaling in the homogeneous component of pos. gl_Position = vec4(0.0, 0.0, 0.0, 1.0); gl_Position.xyz = gl_Vertex.x * u; gl_Position.xyz += gl_Vertex.y * r * wScale; gl_Position.xyz += gl_Vertex.z * w * hScale; gl_Position.xyz += gl_Color.xyz; and I add just after that block gl_Position.z = gl_Position.z * zScale; (look into clouds-layered.vert where a value of 0.4 is hard-coded there). Great. Let me know what else you need and I'll put it near the top of my FG todo list. Wow :-) Thanks a lot! I think wrapping off and z-scaling are what limits my experiments most - otherwise I simply need time to catch up with texturing, parameter tuning, performance tests, but I'll keep you posted. * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
On 11-08-03 08:22 PM, Csaba Halász wrote: On Thu, Aug 4, 2011 at 12:22 AM, marthtermarth...@yahoo.ca wrote: I also have separately installed FlightGear via the package manager, so I tried pointing FG_AIRCRAFT at what appears to be the Aircraft directory, Also when I guessed at what to put for the terrasync exe spot, which I found in ~/flightsim/install/fgfs/bin/terrasync, the Next button is still greyed out. No idea about fgrun, but these two settings are optional. FG knows to look for the default aircraft in FG_ROOT/Aircraft, you only need to set this if you have an additional custom location. Terrasync is not required. Okay thanks for the clarification. okay, well the pre-filled defaults in that run_fgrun Wizard, as (I assume) set up by the download_and_compile script are: 1. Executable: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/bin/fgfs ...which exists and is executable: $ ll /home/mmuc/flight.simulator/install/fgfs/bin/fgfs -rwxr-xr-x 1 mmuc mmuc 135333892 2011-08-03 17:38 /home/mmuc/flight.simulator/install/fgfs/bin/fgfs* 2. FG_ROOT: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata ...which exists but has not much in it: $ ll /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata total 12 drwxr-xr-x 3 mmuc mmuc 4096 2011-07-28 10:43 ./ drwxr-xr-x 5 mmuc mmuc 4096 2011-07-28 10:43 ../ drwxr-xr-x 8 mmuc mmuc 4096 2011-07-28 15:27 .git/ 3. FG_AIRCRAFT: [blank] 4. FG_SCENERY: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata/Scenery ...which doesn't exist as shown in the FG_ROOT directory listing above 5. Terrasync exe: [blank] 6. Airports Cache: /home/mmuc/.fltk/flightgear.org/fgrun//airports.txt ...which does not exist but I'm guessing it will be created after I eventually get to run this successfully. So although I'm a newbie and not knowing what to expect in each folder, I would nonetheless assume that #2 and #4 are the problem causing run_fgrun's Next button to be greyed out. Can anyone comment/agree? I've retried sh download_and_compile.sh DATA... should this fix the above missing folder contents or is there something else I should be doing? Anyway I'm currently getting an error from gitorious.org within the sh download_and_compile.sh DATA output (although I don't think this was a problem when I ran the script yesterday and days before): $ sh download_and_compile.sh DATA ** ** * Warning, the compilation process * * is going to use 9 or more Gbytes * * of space and at least a couple of * * hours to download and build FG.* ** * Please, be patient .. * ** ** Asking your password to perform an apt-get update Ign http://extras.ubuntu.com natty InRelease ... Ign http://ca.archive.ubuntu.com natty-updates/universe Translation-en_CA Ign http://ca.archive.ubuntu.com natty-updates/universe Translation-en Reading package lists... Done Asking your password to perform an apt-get install ... Reading package lists... Done Building dependency tree Reading state information... Done automake is already the newest version. build-essential is already the newest version. ... libqt4-dev is already the newest version. subversion is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. FGFS ** gitorious.org[0: 87.238.52.168]: errno=No route to host gitorious.org[0: 2a02:c0:1014::1]: errno=Network is unreachable fatal: unable to connect a socket (Network is unreachable) $ I also tried this without using run_fgrun, but just using fgrun: $ cd ~/flightsim/install/fgrun/bin $ ./fgrun ./fgrun: error while loading shared libraries: libosgParticle.so.66: cannot open shared object file: No such file or directory $ I also tried without using $ cd ~/flightsim/install/fgfs/bin $ ./fgfs ./fgfs: error while loading shared libraries: libosgFX.so.66: cannot open shared object file: No such file or directory These are normal, the wrapper scripts contain code to set LD_LIBRARY_PATH such that the system can locate the required dependencies. You can of course do that manually too. Note that you'll have to supply fgfs with the path to the data directory using the --fg-root option. Verify that the script downloaded the data for you. Should be easy to notice, it is a3GB download :) Looks similar to what you have found in the installed package (but the two versions are not compatible). okay well the total folder structure that download_and_compile created is almost 9 GB: $ du -ms . 8906. ...but as noted above, there is next to nothing in the ~/flight.simulator/install/fgfs/fgdata directory. Thanks again and I will appreciate a little more feedback if anyone can
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
try running download_and_compile.sh (-an -pn) DATA the -an switch disables the apt-get update, and -pn disables the apt-get upgrade, you won't really need those for the data anyway. Alessandro Date: Thu, 4 Aug 2011 09:59:29 -0400 From: marth...@yahoo.ca To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file On 11-08-03 08:22 PM, Csaba Halász wrote: On Thu, Aug 4, 2011 at 12:22 AM, marthtermarth...@yahoo.ca wrote: I also have separately installed FlightGear via the package manager, so I tried pointing FG_AIRCRAFT at what appears to be the Aircraft directory, Also when I guessed at what to put for the terrasync exe spot, which I found in ~/flightsim/install/fgfs/bin/terrasync, the Next button is still greyed out. No idea about fgrun, but these two settings are optional. FG knows to look for the default aircraft in FG_ROOT/Aircraft, you only need to set this if you have an additional custom location. Terrasync is not required. Okay thanks for the clarification. okay, well the pre-filled defaults in that run_fgrun Wizard, as (I assume) set up by the download_and_compile script are: 1. Executable: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/bin/fgfs ...which exists and is executable: $ ll /home/mmuc/flight.simulator/install/fgfs/bin/fgfs -rwxr-xr-x 1 mmuc mmuc 135333892 2011-08-03 17:38 /home/mmuc/flight.simulator/install/fgfs/bin/fgfs* 2. FG_ROOT: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata ...which exists but has not much in it: $ ll /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata total 12 drwxr-xr-x 3 mmuc mmuc 4096 2011-07-28 10:43 ./ drwxr-xr-x 5 mmuc mmuc 4096 2011-07-28 10:43 ../ drwxr-xr-x 8 mmuc mmuc 4096 2011-07-28 15:27 .git/ 3. FG_AIRCRAFT: [blank] 4. FG_SCENERY: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata/Scenery ...which doesn't exist as shown in the FG_ROOT directory listing above 5. Terrasync exe: [blank] 6. Airports Cache: /home/mmuc/.fltk/flightgear.org/fgrun//airports.txt ...which does not exist but I'm guessing it will be created after I eventually get to run this successfully. So although I'm a newbie and not knowing what to expect in each folder, I would nonetheless assume that #2 and #4 are the problem causing run_fgrun's Next button to be greyed out. Can anyone comment/agree? I've retried sh download_and_compile.sh DATA... should this fix the above missing folder contents or is there something else I should be doing? Anyway I'm currently getting an error from gitorious.org within the sh download_and_compile.sh DATA output (although I don't think this was a problem when I ran the script yesterday and days before): $ sh download_and_compile.sh DATA ** ** * Warning, the compilation process * * is going to use 9 or more Gbytes * * of space and at least a couple of * * hours to download and build FG.* ** * Please, be patient .. * ** ** Asking your password to perform an apt-get update Ign http://extras.ubuntu.com natty InRelease ... Ign http://ca.archive.ubuntu.com natty-updates/universe Translation-en_CA Ign http://ca.archive.ubuntu.com natty-updates/universe Translation-en Reading package lists... Done Asking your password to perform an apt-get install ... Reading package lists... Done Building dependency tree Reading state information... Done automake is already the newest version. build-essential is already the newest version. ... libqt4-dev is already the newest version. subversion is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. FGFS ** gitorious.org[0: 87.238.52.168]: errno=No route to host gitorious.org[0: 2a02:c0:1014::1]: errno=Network is unreachable fatal: unable to connect a socket (Network is unreachable) $ I also tried this without using run_fgrun, but just using fgrun: $ cd ~/flightsim/install/fgrun/bin $ ./fgrun ./fgrun: error while loading shared libraries: libosgParticle.so.66: cannot open shared object file: No such file or directory $ I also tried without using $ cd ~/flightsim/install/fgfs/bin $ ./fgfs ./fgfs: error while loading shared libraries: libosgFX.so.66: cannot open shared object file: No such file or directory These are normal, the wrapper scripts contain code to set LD_LIBRARY_PATH such that the system can locate the required dependencies. You can of course do that manually too. Note that you'll have to
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
On 11-08-04 10:38 AM, TDO_Brandano - wrote: try running download_and_compile.sh (-an -pn) DATA the -an switch disables the apt-get update, and -pn disables the apt-get upgrade, you won't really need those for the data anyway. Alessandro Thanks Alessandro, I more or less tried that, at least the DATA part. I agree I don't need the apt stuff but it's not hurting me I don't think. When I do download_and_compile.sh DATA, I get the git error: You asked me to pull without telling me which branch you want to merge with, and 'branch.master.merge' in your configuration file does not tell me, either. Please specify which branch you want to use on the command line and try again (e.g. 'git pull repository refspec'). And when I do download_and_compile.sh -s DATA (for the stable version of fgdata), I get: You asked to pull from the remote 'origin', but did not specify a branch. Because this is not the default configured remote for your current branch, you must specify a branch on the command line. These two problems are around line 687 of the download_and_compile.sh script. I noticed that there were in fact 7.2 GB in the fgdata/.git folder (and no other folders present within fgdata at all), so it seemed all the downloading had been done, just none of the git magic to actually show any files. After googling the above git messages, it seems I can run git pull origin master (instead of what the script has, git pull origin), so I manually ran this and about 5 GB of Aircract, Models, and other folders are now there, so I think I am over the hurdle for now. However the script does not appear to be working as automatically as it is described so it would be nice if the script and/or the Scripted Compile wiki page would be updated by someone who knows these git details. This is my first day with git (although I've used and administered cvs and svn extensively) so I'm just grasping at straws here. Now when I run sh run_fgrun.sh it doesn't even take me to the Select Paths window with the greyed out Next button, it takes me directly to the Select an aircraft window, so I'm all good now. : - ) Okay, spoke too soon. When I click on an aircraft like Cessna 172R my mouse pointer turns to the please wait icon and nothing else seems to happen (5+ minutes now). Is this normal? Is it building a cached copy of the aircraft geometry or something? I suppose this last question is getting into a -users list type question but I should explain that my desire to build this from source is to expand the nmea protocol output, as I asked about the other week on the -users list. Cheers. Martin Date: Thu, 4 Aug 2011 09:59:29 -0400 From: marth...@yahoo.ca To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file On 11-08-03 08:22 PM, Csaba Halász wrote: On Thu, Aug 4, 2011 at 12:22 AM, marthtermarth...@yahoo.ca wrote: I also have separately installed FlightGear via the package manager, so I tried pointing FG_AIRCRAFT at what appears to be the Aircraft directory, Also when I guessed at what to put for the terrasync exe spot, which I found in ~/flightsim/install/fgfs/bin/terrasync, the Next button is still greyed out. No idea about fgrun, but these two settings are optional. FG knows to look for the default aircraft in FG_ROOT/Aircraft, you only need to set this if you have an additional custom location. Terrasync is not required. Okay thanks for the clarification. okay, well the pre-filled defaults in that run_fgrun Wizard, as (I assume) set up by the download_and_compile script are: 1. Executable: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/bin/fgfs ...which exists and is executable: $ ll /home/mmuc/flight.simulator/install/fgfs/bin/fgfs -rwxr-xr-x 1 mmuc mmuc 135333892 2011-08-03 17:38 /home/mmuc/flight.simulator/install/fgfs/bin/fgfs* 2. FG_ROOT: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata ...which exists but has not much in it: $ ll /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata total 12 drwxr-xr-x 3 mmuc mmuc 4096 2011-07-28 10:43 ./ drwxr-xr-x 5 mmuc mmuc 4096 2011-07-28 10:43 ../ drwxr-xr-x 8 mmuc mmuc 4096 2011-07-28 15:27 .git/ 3. FG_AIRCRAFT: [blank] 4. FG_SCENERY: /home/mmuc/flight.simulator/install/fgrun/bin/../../fgfs/fgdata/Scenery ...which doesn't exist as shown in the FG_ROOT directory listing above 5. Terrasync exe: [blank] 6. Airports Cache: /home/mmuc/.fltk/flightgear.org/fgrun//airports.txt ...which does not exist but I'm guessing it will be created after I eventually get to run this successfully. So although I'm a newbie and not knowing what to expect in each folder, I would nonetheless assume that #2 and #4 are the problem causing run_fgrun's Next button to be greyed out. Can anyone comment/agree? I've
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Even though your previous testing showed no perf difference between the default 3d clouds and the models, I am slightly disappointed there isn't some intrinsic perf benefit to the default 3d versions. It's not been a fair comparison as such. Let me try building clouds from the same texture sheet (i.e. same texture resolution, same number of cloudlets) - that's the relevant measure. Also, don't forget the wind drift benefit - that's huge... And some benchmark tests with my Altocumulus texture sheet: With the same number of cloudlets and precisely the same texture sheet, Stuart's hard-coded clouds get about 20% more framerate out of my box. Even more impressive, the performance doesn't really degrade until I increase the number of cloudlets by a factor 10 (where I built a cloud from 2 textures previously, I can now use 20) - only when I use 100 sprites per cloud do I see a rather significant performance degradation (black magic??) So we get nicer clouds with better performance - I like that :-) (Don't get overexcited about a factor 10 more cloudlets though - since we distribute them into a volume in the end, the linear resolution of structures only grows with the cubic root of the cloudlets, so the actual improvement factor is more like 2.1... ) * Thorsten -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
Hi, the script is made to duild both fgrun and fgfs if you give no arguments, unfortunatelly, it is quite easy that something can go wrong (Compilation,data fetching etc...). when this happens, you can end up with an inconsistent fgdata folder that makes the git problems. Further more if data fetching stops before finishing, the script is set to stop, so you don't get fgfs nor fgrun. You have to try again, best to wipe out fgdata folder under installation/fgfs prior to relaunch the script. The problem with the blanck parameters in fgrun are due to the fist launch of it, I don't know yet how to make it work without user interaction. If you have problems with fgrun, just launch fgfs only first (sh run_fgfs.sh) and see if it works or not. Cheers Francesco -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
On Thu, Aug 4, 2011 at 5:29 PM, marthter marth...@yahoo.ca wrote: I noticed that there were in fact 7.2 GB in the fgdata/.git folder (and no other folders present within fgdata at all), so it seemed all the downloading had been done, just none of the git magic to actually show any files. Ok, then try the git magic: git checkout master If that doesn't work, try: git branch -vr, check if that shows maybe origin/master. If so, do git checkout -b master -t origin/master. -- Csaba/Jester -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future Weather System
2011/8/2 Mathias Fröhlich wrote: snip So I decoupled these two structures somehow. I have put bv-trees of geometry into the userdata field of the scenegraph. So for the high level operations like tile loading, the scenery paging is used to load and get rid of the bv- trees. The whole intersectable scenery should be there in this form. Using this, you could already speed up ground queries by using these bv-tree leafs for intersection test leaf traversal. But for the actual aircraft I wanted to be able to do up to the order of 100-1000 intersection tests per timestep. To get that sufficiently fast, I built that ground cache: snip This means using the ground cache is only valid near the actual aircraft, where near means a few 10 meters. And no, please do not increase this ground cache radius of the aircraft for the weather. What you can do for the weather is to traverse the bv-tree nodes instead of the GPU optimized scenery nodes for ground queries. I guess this is the fastest (implementation wise fastest) approach to get something you need. Thanks very much for the detailed explanation. That makes a lot of things much clearer! From a quick code read, it looks like the scenery.cxx get_elevation_m() function does not use the bv-tree. I think the reason I have seen much higher performance using the ground_cache is that the flight.cxx method uses the BVH tree if it doesn't get a scenery hit. Therefore the solution may be to change the scenery.cxx version to use the BVH tree if possible. That should provide significant performance gains. I will investigate... -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposal: Move airplanes to an SVN repository
Frederic Bouvier wrote: Funny (!) that the last one in the first list will be unmaintain from now if I read this ml correctly. Let's sit down and have a beer/wine/tea/vos...dka ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scripted compile from source... results in run_fgrun buttons greyed out, or fgfs cannot open shared object file
Hello Francesco How are you doing lately? :) Hope all are well with you... With respect to FGRUN in your script, maybe you can consider FGO in your future scripts. I find FGO to be light on system memory and easier to manage. This is just a suggestion and i hope you do not mind... Cheers! :) On Friday 05,August,2011 12:37 AM, Francesco Angelo Brisa wrote: Hi, the script is made to duild both fgrun and fgfs if you give no arguments, unfortunatelly, it is quite easy that something can go wrong (Compilation,data fetching etc...). when this happens, you can end up with an inconsistent fgdata folder that makes the git problems. Further more if data fetching stops before finishing, the script is set to stop, so you don't get fgfs nor fgrun. You have to try again, best to wipe out fgdata folder under installation/fgfs prior to relaunch the script. The problem with the blanck parameters in fgrun are due to the fist launch of it, I don't know yet how to make it work without user interaction. If you have problems with fgrun, just launch fgfs only first (sh run_fgfs.sh) and see if it works or not. Cheers Francesco -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
