Re: [Flightgear-devel] Bug 772 (Yasim on ground)
Hello, I have re-opened today this issue again, after I played with some better developed YASim aircrafts like MD 81 to find out what is the issue behind the bad crosswind behavior of my Dornier 328TP- project, and a lot of other aircraft. (couldn't test all of course) Especially I tested the MD81 by Gary Neely after I read his very good YASim tutorials. Gary Neely MD81, gross weight 157503 lb Location: Edwards base KEDW, RWY 15 Weather: 08025KT 12SM 20/08 Q1013 NOSIG Takeoff behavior: as soon I reach 110-120ktn the aircraft will drift into the wind. Landing behavior: I noticed that even this aircraft will drift away as soon the nose gear will touch down with wind speeds about more than 20ktn and wind from left Crosswind limitation for the real thing is 30ktn on dry runways. (http://www.hilmerby.com/md80/md_basic.html) No problems with wind from right, even with much higher wind speeds- and that's exactly what makes we wonder. now the 777-200ER, gross weight: 574595 lb Location: Edwards base KEDW, RWY 15 Weather: 08025KT 12SM 20/08 Q1013 NOSIG Takeoff behavior: Flaps 15: as soon I reach 110-120ktn the aircraft will drift into the wind as well. (Vr: 130ktn) Flaps 5: as soon I reach 110-120ktn the aircraft will drift into the wind as well. (Vr: 130ktn) Landing behavior: I noticed that even this aircraft will drift away as soon the nose gear will touch down with wind speeds about more than 20ktn and wind from left as well Crosswind limitation for the real thing is about 40ktn on dry runways. (http://www.pprune.org/archive/index.php/t-285471.html) So, I'm sure the problem isn't solved. No idea where the cause of this problem could be- I'm not sure if it is really the aircraft configuration... Kind regards HHS-- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] static friction patch
Hello, since april 15th, there had been some time. I wonder if there is any progress on the code patch? As reminder: The ground slide issue is the biggest issue on YASim- would be great that could be solved as soon as possible. (Though it won't make it the coming release now) Cheers HHS-- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Now, sorry, FG snapshots With ALS and Without Rembrandt https://sites.google.com/site/grtuxhangarctd/other-download/ P-38_demo1.png Who said we don't need a specific version when using ALS ? I have to wonder- because you don't need a specific version for ALS! Use the shader as it is in current FGData and it will work in ALS, Default-renderer and Rembrandt. The only thing is, that lightmaps, as possible in ALS and Default Renderer, doesn't look all to good in Rembrandt in combination (!) with light volumes. But this can be solved. One model, one version- three renderer. FlightGear! -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
If I can't remember what ALS stands for, can I call it Lou Gehrig's Renderer? Is the name Charcot's Renderer to complicated for you? ;-) -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] static friction patch
Hi Diogo, Hi all others, Great to hear- I already thought your work stalled. With some intelligent distributing of ballast you could at least reduce the movements with stopped engines to a minimum. But as soon the rotors started there was no hold Unfortunately I can't test your patch - but when I read that Flughund could already test sucessfully, and you got support by Mathias and Czaba, it sounds more than promising. Love to see it in FlightGear as soon as possible! Cheers HHS -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG - YASim model output data in txt file
Hi, Unfortunately YASim doesn't output all too much values. You can't directly plot like with JSBSim, but FlightGear offers a logging function, so you can log available values and use it. As an example that's how I determine roll rates etc... Menubar -- Developers -- Logging You can change the items in the preferences.xml as well, the output is sent as .txt in the directory where FGFS is installed (at least with win32 xp) Cheers -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Issue 894: Stuck at loading nav datas while launching FGFS 2.11.0 win32
Hello, With GIT from today 03/29/2013 and jenkins build #1021 the issue is back again, and it even seems worse than ever before! Here the output of the console since 30min, FGFS is stuck in Loading Navigation datas: Logging priority is debug initializing cloud layers Using initial window size: 960 x 720 Initializing splash screen Enabling ATI viewport hack Configuration State === == aircraft-dir = C:/Programme/FlightGear/fgdata2/Aircraft/ec135 fghome-dir = C:\Dokumente und Einstellungen\Heiko Schulz\Anwendungsdaten\flight gear.org aircraft-dir = C:/Programme/FlightGear/fgdata2/Aircraft/ec135 aircraft-search-paths = C:\Programme\FlightGear\MD-900 scenery-search-paths = C:/Programme/FlightGear/terrasync C:/Programme/FlightGear/terrasync/Terrain C:/Programme/FlightGear/terrasync/Objects Cannot find splash screen file 'Aircraft/ec135/splash.rgb'. Using default. Splash screen progress init NVIDIA Corporation GeForce GTX 460/PCIe/SSE2 4.2.0 4.20 NVIDIA via Cg compiler Splash screen progress loading-aircraft-list Splash screen progress loading-nav-dat NavCache at:Path C:/Dokumente und Einstellungen/Heiko Schulz/Anwendungsdaten/fl ightgear.org/navdata_2_11.cache NavCache: initial build required for Path C:/Programme/FlightGear/fgdata2/Airpo rts/apt.dat.gz NavCache: main cache rebuild required NavCache at:Path C:/Dokumente und Einstellungen/Heiko Schulz/Anwendungsdaten/fl ightgear.org/navdata_2_11.cache will create tables Data file version = 810 ... NavCache: initial build required for Path C:/Programme/FlightGear/terrasync/Air ports/Z/Y/C/ZYCC.ils.xml re-loaded ILS data for ZYCC nav.dat load took:18513 What I write now is not to make anyone upset but might not be loved by everyone, as I think I have to remind some things: Would it be possible to test sensible things BEFORE they went into GIT? I think in the past we tested cross-plattform sensible things before it went into GIT/ CVS. Yes, I'm aware that GIT is the developement place, and with this a larger group of people can be reached for testing. Yes, I'm also aware that developing for cross-plattform is pretty challenging. But Co-Developers depends on the latest developement steps if they want to make it compatible with the next FlightGear release! It is pretty bad for Co-developers when due such failures their own projects are delayed. Not every developer has plenty of time everyday and week to wait until the problem has been fixed. I hoped that I could get my Project EC135 P2 into FGdata in the next weeks since I spent about guessed 100 hrs into finetuning the fdm, but due this bug I'm not be able to make further developement steps, especially regarding tooltips and the new VSI, and so my little project will be delayed now for a indefinitely time since I will probably very busy with studies again until early summer. Cheers Heiko -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 894: Stuck at loading nav datas whilelaunching FGFS 2.11.0 win32
Problem is NOT seen here - windows 7, MSVC10, git updated 5 minutes ago. I also tried with the ec135 that is in git -- all OK with that as well. Good to hear, maybe just a windows xp issue? I suggest you check your new ec135, then system.fgfsrc and any other initialisation files you may have, and the perhaps delete files from ./AppData/Roaming/flightgear.org. I tested several other aircraft especially from the base package (c172p, b105...). And of course I also deleted the files from $FG_HOME. Then say sorry to the developers if it turns out to be a local fault. ;.) I have manners -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 894: Stuck at loading nav datas while launching FGFS 2.11.0 win32
Hi James, Thanks for the explanation. Did I understand correct that the issue is much more complex than I though? That one platform behaves completely different on different machines as expected? Wow, strange. Because it did work pretty well some weeks ago, I thought the issue was more or less solved. So now I was really surprised to see this issue again, and as I didn't read anything from users using a different platform so I was under a false impression. Sorry about, I didn't want to rant. After deleting the nav cache files, it worked but it needed 15min. Unfortuantely I don't have the time to build FGFS myself, so I can't provide any further help with a debug help as suggested on the bug tracker, but if there is any other help from myself possible let me know. @Alan: Please note the smiley. ;-) ;-) I noticed it, but I unfortunately do know people reading here who are pretty good in missing such smilies and trying to get their benefits from it... Do you have any nvdata.cache or navdata _2_11.cache files in ./AppData/Roaming/flightgear.org ? I have navdata _2_11.cache files here. Also, I do not have $FG_HOME set here, just FG_ROOT and FG_SCENERY. It is set automatically here on win xp -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 82, Issue 20
Hello C-VALL, No ! ESP is just an SDK by M$ And the work of Lockheed Martin is absolutly separate of FS X. FS X and Prepar3D are totaly different. Lockheed Martin also promises no compatibility with various X Addons FS. And ESP is free. Lockheed Martin did not buy anything. http://msdn.microsoft.com/fr-fr/library/ff798293.aspx The french (!) page you linked says, that: The Microsoft® ESP™ SDK is the core component of the ESP product. ESP is a set of tools that enables simulation of real-world objects. ... The primary tool, ESP.exe, is a flight simulator, and this SDK can be used to create add-on components for it So ESP is not a SDK, but contains SDKs. About Prepar3d: Lokheed Martin writes on their homepage http://www.prepar3d.com/ about Prepar3d: Prepar3D furthers the development of Microsoft® ESP™ while maintaining compatibility with Microsoft Flight Simulator X, allowing many thousands of add-ons to be used within Prepar3D. It is different yes, but Prepar3d is based on ESP, and ESP is based on FSX. Lockheed Martin bought ESP and the licences and developed it further for their needs. Not the same, but the same origin and base, and it can be used in the same way for same thing and more. You won't see much difference between a image of FSX and Prepar3d. So I don't see why gene is wrong here. Regards -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Jenkins Build win32 #926 and older quits
Vivian, I reset FG/SG to 23rd Jan - that compiled and ran successfully. Vivian according to James and fred on the bug tracker, the bug has been fixed already. I just wait for Jenkins running again to test. Heiko -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Jenkins Build win32 #926 and older quits
Hi, Today I wanted to test all the new things I missed in the last couple of weeks. So updated FGdata, and downloaded the last win32 build on the Jenkins build server. To my surprise, fgfs.exe quits when pressing the launch button in FGRun. The console only shows following strange error message as I haven't used no aircraft with something like that: Failed to create alias at /controls[0]/refuelling[0]/refuelling-drogues-pos-norm [0]. Source /sim[0]/multiplay[0]/generic[0]/float[2] is already aliasing another property. Failed to set alias to /controls/refuelling/refuelling-drogues-pos-norm Setting log level to debug doesn't give anything, but setting to log-level bulk give me following: general:3:..\..\..\FlightGear\src\Main\main.cxx:311:FlightGear: Version unknown version general:3:..\..\..\FlightGear\src\Main\main.cxx:312:Built with Microsoft Visual C++ version 1600 I used the latest win32 build #926, but also tried build numbers down to #920. None of them worked for me. Any idea? Cheers Heiko -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata Commit c8a69dffd49a298e01c0e0e1320f4a1d49a0bca4
The DR400 Guide (Aircraft/DR400/DR400 Guide.pdf) commited in this has a non-GPL compatible license (All rights reserved). A nice example of some small words can do. I would have never noticed as I would all rights misinterprete as simple copyright at first glance. *blush* It isn't just a simple copyright I'm a bit more concerned about the commit description. First it doesn't make sense to me (there was only two contributor ever who committed changes to the DR400 in FGData - who the hell then broke anything?! E. BARANGER or Thorsten Brehm? *confused*). Then the description doesn't list was had been changed. So it seems to be just a quite meaningless description attacking someone... :-( That's something that I have seen quite often by some contributors, that they aren't able to tell what they have exactly changed. But that's the meaning of the commit log- Keywords and short exact description would help to see quick what had changed and would invite more to test and try. No need to write a book! So bugs and mistakes could be more followed easily. Juts two cents from the users perspective -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Framerate improve with latest Git + effects problem.
Hello, Indeed, I updated my system on the weekend, and I was surprised!! Especially with Lightfield-Shader enabled and Advanced Weather, Framerates are a dream! If we manage to get the Reflection-Lightmap-bmpmap-shader to work with, I would be in heaven! I did some advertisement in a swiss aviatic-forum: http://www.flugsimulation.ch/forum/showpost.php?p=833259postcount=4958 http://www.flugsimulation.ch/forum/showpost.php?p=833260postcount=4959 Compared with those MSFS-screenies above we are looking really good! Cheers HHS -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
Hello, I thought today it would be nice again to have a flight in FGFS, since I found some spare time. Updated FGData, download the latest Jenkins build #726 for win32 and launched it. Since a whole while now, a bit more than 30min, it is stuck at Loading navigation datas. And I'm still waiting, and waiting... I guess it has something to do with the changes announced here, but it is just a guess. No relevant console output (just: Warning: GraphicsWindowWin32::grabFocus() - Failed grabbing the focus) win32 Jenkins Build #726, updated FGData Dualcore 2,6 Ghz, 4GB Ram, Nvidia GeForce GTX460 1GB VRAM Bug Report: https://code.google.com/p/flightgear-bugs/issues/detail?id=894 Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
On 10/03/2012 07:30 PM, Heiko Schulz wrote: But already done: http://www.hoerbird.net/reisen.html Gives me a 404 error. me too ;-) Changed the signature any other comments on my problem? After a while it loaded now the nav datas, but whenever I start FGFS again, it takes the same time again. Not sure if this behavior is intended... -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nav-cache
Hi Fred, I know some people erase the content of the folder having autosave.xml. This folder is now used to host a navigation data cache. The first time, a SQL database is built to speedup future start. If this cache is erased every time, it defeats the purpose of the cache and make the start much longer every time. Just guessing... Regards, -Fred Yes, that might be the case. In the meanwhile I found out myself that it hosts the navigation cache in the autosave-folder. The reason why it had to built it up again was simply, that I didn't quit FGFS on the usual normal way but just hitting the Close-button of the FGFS-window. I wonder how we deal with this with the next release- I'm sure a whole lot more users will complain about the stuck while launching FGFS. Regards Heiko -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Unified Weather GUI
Hello, So far, so good! Thanks! The only issue I found is that the visibility can't be changed in any way. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
Thorsten, you have email. And to all others: sorry for making a big noise here! -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
Thorsten, What I really, really hate in FlightGear's last years developement, is how the ego of some people involved (yes, I think that's include me as well) seems to make things and discussions more and more difficult. And this discussion shows it again. But maybe it is only the translation from german to english and from english to german we both have to do make things here difficult. But well, the whole discussion was more or less my fault- I have been warned off-list that I will open a can of worms with my posting*sigh* Again: I criticed NOT YOU as person, simply the way what happend with the shaders, and especially the atmospheric shader. As you was the main developer behind the atmospheric shader, you was being adressed. So no reason the get polemic or arrogant: I wrote 'scenery and models', I did not write 'trees'. ... Which of these two statements did you find hard to understand? However, I simply I had the feeling that I somewhere read that there has been a more simple way proposed to have your shader working together along with the other shaders. Don't worry - I really, really understand, that you have a different view on it, and my proposal to get a middle thing isn't a good solution. That's why I asked, and that's why I got clear and understandable answers here- unfortunately just not from you. You have to know that beeing involved myself since 2006, (more than as a simple stupid user) I think I'm allowed to say what I think what is mabye not right. That doesn't mean of course I'm right at the end. That doesn't mean that really everyone thinks so. But different to a closed project, in FGFS different views, even from outside, are sometimes wished and accepted. But something like that...: And what's the relevance of this? I want plenty of things... Someone with GLSL knowledge to explain things to me so that I can get rid of trial and error based development for starters. Someone who learned digital image processing to help me with cloud texture extraction. Someone who flies his own plane to take GPL compatible semi-ortho-images to create textures and to take aerial images of some rare cloud types. I want people to pick up some of the space capabilities of Flightgear, create orbiting AI model code and some more spacecraft so that we could fly to ISS. Do I get any of these things? No, I don't, and I'm guessing there is a reason every no. ... could have written in one short sentence: Sorry, some things goes behind my knowledge, that's why it isn't there. If anyone interested to help, you are welcome! or anything like that. or There is currently no technical way in the moment to do so. Accetable by everyone, even by me ;-). But flooding with texts, especially in a manner that others make looks like a dumbhead makes you look like being ignorant and shows some strange attitude to some. And at the end we wonder we have it again, that people come up and say Uh, there is now way to contribute; there are all feeling like elites..; the don't listen to users; ... etc, etc. I hope you understand, then at least that's exactly the feeling I got here with your replies, and I hope that wasn't that what you wanted. Everything should be as realistic as possible, but under no circumstances should it lead to a loss of framerate, ... Sorry, that's the goal of every flight simulator: realistic as possible, perfomance friendly as possible. Only knowledge and hardware is the limit here, and this limit is pushed further every year. In essence, your suggestion is to 'dumb down' flightgear and not to offer any features which are not completely integrated with everything else because the user may not be willing to accept that not everything works with everything else. Sounds like a bad idea to me. We are not a commercial enterprise, and we play by different rules. Trying to adopt commercial development strategies will only make us fail. Again: my whole statements was from users point of view. FlightGear was based on the idea to be an alternative to MSFS for many reasons. Since then, up to this day we are being measured with MSFS and other flight simulations, commercial or free. The good thing is, and there I agree, that we aren't bound on earning money, so we can make things without the risque beeing not that successful with. That makes us indeed strong! But that doesn't mean that we should forget users- Because the users from today are the developers from tomorrow and NO, in this context I don't mean problems with framerates here. Users and heir contributions are our gain, not money. But you also wouldn't have made such a statement if you wouldn't have forget that FGFS is used in some research and even commercial projects, and that's even one goal of our project. I hope you are aware that under Users are not only meant pimpled teenagers with a bag of crisps sitting in front of their computers. While our big
Re: [Flightgear-devel] Shader menu structure
Thorsten, No, it is not so now (at least for me that is, maybe there are problems with other cards/systems/... I'm not aware of). I get to see a seamless and plausible match between sky and terrain from ground level to low Earth orbit, at all times of the day and under any weather condition. Scenery and models are now rendered correctly with the sky at all locations and all times. Really? Look at the trees- Does they blend correct here? http://www.hoerbird.net/Treeblend.jpg Not having a particular extra effect available is not the same as having a graphical artefact in the scene, and I refuse to treat the two on the same level. The first is a missing feature, the second is a bug. There are those of us who do not enable all available shaders even in the default scheme and don't miss features. There are even those who use Flightgear without shaders. If airplane X requires a shader to work at night or under some conditions, then the problem is with airplane X because at least as far as I am aware the development philosophy is that Flightgear should still run under pure CPU rendering conditions. Again, the last time, as it seems to me that even with no kids and grandparents here I don't have much time than you: We have shaders. We decided once ago to haven them. And when a user is also able to have them, as his computer allows them to have, he wants to have them all of course. The user doesn't want to check everytime which of the shaders is compatible with others. That's one BIG secret behind the success of some flightsimulators and even a requirement there. If a shader can be deselected, than just for perfomance reasons, but not due to being not compatible with other shaders. And that's exactly the problem here. We had no consistently way in developing and adding shaders. I've really been sleeping over this. Consider this different story: ...Hey, the XXX is now so difficult to fly! It used to be such a cool plane, you could land on a skyscraper and it wouldn't even take any fuel, this was so fun to use and now I can't even get it off the runway! Can't we keep the old version? So, would you optionally include the YaSim FDM because someone thinks it was cool and misses it? 1.)Zan's shader was known that it gave artifacts on the horizon. But it wasn't plain wrong. I would call the default sky as plain wrong as it never matches the real colors. It worked with other shaders, but had the big issue with horizon. It was included in the hope that this issue can be solved. Now you introduced a shader which doesn't have problems with the horizon, but other shaders doesn't work. It is not really an improvement- unless you just look at the horizon and nothing else. 2.)your example is a stupid comparison: YASim and JSBSim are two different FDMs, with two different philosophies behind. Even a plain wrong, and simple YASim-fdm can be corrected later. And that's why you still see aircraft with two different fdms, Yasim and JSBSim, and users can select which one they prefer, compare it and if possible improve it. None of those FDMs are always 100% correct, they have their own issues and though they have its reasons to be there. 3.)And somehow myself as Aircraft Author feel ignored and mistreated when you say you develope a shader just for looking out the window and not at the aircraft. Why the hell spending a lot of times in trying to create an accurate exterior model? A simple box should be enough. To say it very bluntly: To make a skydome only option available is to re- introduce a bug which I have spent a lot of time and effort to eliminate. That's why I hoped that we could get all three possibilities. But again: your shader has problems as well- compatibility. Originally I started this thread asking for help how to communicate all this best. It seems we've introduced a regression here as well. Good that you said we And to answer it finally: I don't see a way to communicate, as the horse has already been bolted. Gijs did the best to prevent upcoming questions with changing the rendering menu, but I won't be surprised when people will still come up with this issue. The big problem behind is, as I already said above: the non-compatibility between the shaders. As I heard, some people are planning to create an own Viewer, outside but compatible with FG - exactly due to this reason. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
Re: [Flightgear-devel] Shader menu structure
Emilian, There's only the default sky that works together with the normal shaders , or the Atmospheric scattering stuff which supersedes the old skydome shader. The Atmospheric scattering is a whole set of shaders, that interact to give a seamless horizon, and much more... They replace all other shaders when enabled, that's hardcoded in the effects, and it needs to be otherways it wouldn't work. So you'd end up with a dialog full of sliders that do nothing... Let me correct one thing: it doesn't replace all other shaders. As an example the one you used on your IAR80. My hope for the next release is that we get a Atmospheric scattering stuff that replaces ALL shaders, so we don't have a compatibility problem anymore. And of course it should run with Rembrandt as well. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
Hello, I'm lost. Can you explain and give screenshots? I am seeing correctly rendered terrain and reasonably rendered aircraft when using the atmospheric scattering. I'm not seeing detailed aircraft effects because the shader hasn't been converted. In principle, I think here one could think of just allowing to run the default scheme shaders because the atmospheric scattering scheme wouldn't do much extra to your own aircraft - the problem is MP and wrong fogging and lighting for other people's planes. I don't know. ... If there's anything recently broken, please explain with details - I'm not seeing it. First, let my try it, so I can try to answer the other questions: As Today: *2.6.0 In 2.6.0 we had only the choice between default sky or Zan's sky shader. In both variants shaders on aircraft and on terrain worked, but there was the problem with horizon. It gave us pretty cool looking skies, as you can see on the 2.6.0 gallery. *2.8.0 Now in 2.8.0 we have the choice between the default sky, or your Lightfield shader, also named as Atmospheric scattering. I disregard Rembrandt, as most users won't use it yet for different reason. With default sky everything is working, it is just the sky which looks like it has be done since years. http://www.hoerbird.net/DefaultSky1.jpg http://www.hoerbird.net/DefaultSky2.jpg (reflection on aircraft increased to show the effect better here) With Lightfield shader also named as Atmospheric Sky Scattering enabled: we get pretty cool looking skies, a correct horizon but terrain colors which looks somehow pale,but as you can see only an optical illusion, as the colors doesn't seems to match. http://www.hoerbird.net/AtmosphericScatter1.jpg http://www.hoerbird.net/AtmosphericScatter2.jpg All aircraft shaders like reflection, bumpmap, lightmap and the combined versions aren't working anymore. Terrain shaders like Transition, Urban and Crop aren't working anymore. Landmass is working. Water is working as well (even changes color depending on Global position). And only with Advanced weather enabled we get additional cool looking horizon, volumetric looking fog and snow transition (= snow line). Images used with Fair weather. Limitations are there because some cool shaders like reflection, lightmap (important for dusk/dawn/night flights) and transition aren't working. If we want to show cool images or videos we have to decide if we want a cool looking sky, or a cool looking everything else. Both together isn't possible as it was in 2.6.0. The big problem again is, that there isn't a simple developement line visible anymore. It is difficult to explain users why some cool features advertised in 2.6.0 will be broken again in the next stable release 2.8.0. Or with other words: things that wasn't finished yet, had been changed with new things which aren't finished yet again, but behaves now different again. Emilian said: Allowing a decoupling between the Skydome and the ligthfield/haze shaders, would lead only to inconsistent settings, and useless bug reports from users blindingly enabling every switch available to them. I'm not sure about. From users point of view we have a skydome shader, and the lightfield shader which makes use of this skydome shader and adds some further features but with the side effect of a lot non-working shaders. Now to the other question: How to present it to the user? (...) Please give some feedback - how can we communicate better what is happening and why there are limitations? Limitations explained above. I have no idea how to communicate it or present it. That's why I hoped that we maybe can have all three skydome variants selectable. So we would have the default skydome, the skydome shader and the Lightfield/Haze aka Atmospheric shader selectable. That would have made it easily to present different developement stages and performance requirements to the user. I helped myself with having only skydome shader and Lightfield/Haze aka Atmospheric shader selectable, but that's a very personal solution (and prevents me to create to make screenshots for 2.8.0 gallery. But as Emilian said, there are technical reasons, and so myself can live with it. The horse has already been bolted. I hope I made it a bit more clear, as my english reached its limits. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list
Re: [Flightgear-devel] Shader menu structure
Thorsten, FIRST: I'm not criticing your work. Instead I really appreciate your work, as you try to make things right! But I criticise the way we handle new features. Due to this I can pretty well understand Freds concerns about adding a simple switch for enabling Rembrandt, which is a experimental feature as well. Keep it more or less only available to them who does know what they do and understand that there are still problems seems the better way sometimes. SECOND: I'm following FGFS's developement as much as I can, but sometimes I try to see things from users perspective view. And my critiscm is based on that. You're kidding yourself if you claim the skydome ever worked properly in 2.6. ... I don't think it's a good idea to put cool features which work sometimes if you cherry-pick conditions into a release. Doing so in 2.6 with the skydome shader turned out to be a mistake. Going further into the direction of the mistake makes the problem worse, not better. If I remember right, in 2.6.0 the skydome shader was marked as experimental. So of course that means that things doesn't work right, and yes, and under some circumstances the shader didn't work properly. And so it is now. But we changed a skydome shader with problems with another skydome shader with other problems which needs to be fixed. From developers view that's o.k.- that's how development works. But from users view it is difficult to understand, as we already could see (I was not the only one who did not understand the whole thing). That's why I hoped we can get something like a compromise and that's why I came up here with. I can see now that it isn't possible, so I hope we are able to sort out the problems in the next developement semester. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
Hello, I noticed today that we can only decide between Thorstens Athmospheric Light scattering which disables other shaders, or FlightGear's Non-shaded Skydome. For me it is a regression compared with 2.6.0. So for me I have disabled the predicate-section in skydome.eff which enables the Athmospheric Light scatteringr as default without disabling other shaders.(while skdome shader disabled in the rendering menu). Looks good at low flightlevels, known issues at higher levels. When enabling now in the rendering-menu the skydome-shader I get now Thorstens full Athmospheric Light scattering, but other shaders are disabled. Is there a way we can have all three possibilities (default, skydome shader, Thorstens atmospheric light scattering) selectable? Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
Hi, Allowing a decoupling between the Skydome and the ligthfield/haze shaders, would lead only to inconsistent settings, and useless bug reports from users blindingly enabling every switch available to them. ... I hope you can now better understand the reasoning behind this. Thanks, that's now an answer I was looking for. Though I'm sure we will get bug reports as well by users complaining where the shader from 2.6.0 went, or why shaders won't work. Some of this confusion was already visible in the forum. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Enabled random buildings in preferences.xml
Stuart, ...There is a significant memory footprint, but this appears to be only an issue when using building densities 1. At present our default is for random vegetation and random objects to be switched on, both of which also have fps and memory impacts. I'd therefore like to suggest that we enable the random buildings by default as well. Does anyone have any objections, or want to second the proposal? Your work does really look great, especially at areas like San Fran, LA and other big cities. It improves really much the graphics! Framerates are better than expected, and it shows some eyecandy like reflecting windows. So I would agree to enabling it per default if, well if the memory foot print would be lower. Today I made a simple flight from KLAX to KSFO with the 777-200ER with scenery downloaded from TerraSync (TerraSync itself disabled), skydome-shader enabled, random buildings enabled (density =1), trees enabled (density =1), fair weather without (!) 3d-clouds and default materials.xml. After just mid distance I got the first error messages and the buildings went black. Coming again to city area everytime a tile had to be loaded the sim freezed for several seconds. I have 4GB RAM; and my GPU (Nvidea GTX640) has about 1 GB VRAM. I must admit I expected a better behavior. What I noticed, different to the trees, the distance of loading random building increases together with the visibility while the trees has a limited range. Would be something possible as well for random buildings? And if so, would it help in this issue? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Enabled random buildings in preferences.xml
Stuart, I got following error message: Warning: detected OpenGL error 'out of memory' at after RenderBin::draw(..) Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The next FlightGear release (summer 2012)
Hello, Two questions have to be discussed and answered until the release branches get created on July, 17th: 1) What's the version number of the new release? a) 2.8.0 b) 3.0.0 Keep it consistent: 2.8.0 My reasons: -Rembrandt is still experimental and Fred's To-Do-list is still big. I would like to see it included, like now we have in 2.7.0. But as it is experimental, it doesn't work on all systems (and it won't as it is deferred shading and so will naturally need some power) and a lot of things missing it isn't a reason to break our version number system. With that I can still see that some shaders doesn't work yet with and without rembrandt and together with the updated other shaders (skydome/ lightfield as an example)- I'm sure there are people who will complain about. -the random buildings are great, but can't remember that we increased version number with the 3d clouds or the trees. 2) Which aircraft do we ship in the base package? a) just the c172 b) same as before c) [name your preferred aircraft] b) 3) Should we keep last year's commit policy for aircraft during the feature freeze? a) yes b) no Does not make sense to me to stop commit to aircraft during feature freeze, as long they won't break other important things. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal performance
Thorsten, Heiko and Vivian, please try the following version and let me know if this improves anything. If possible, do all tests with the weather tile type 'Test' (that has no randomness in the cloud configuration selection, so it delivers a fairly reproducable situation in terms of cloud count). http://users.jyu.fi/~trenk/files/advanced_weather_v1.47.tgz Yes, that improves it here really much! First, quite subjective impression: -Less stutters, more stable -framerate impact comparable with Default clouds Now it seems to make fun, and makes FGFS does looks great again! Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Hello Thorsten, Somehow I don't like the way this discussion is going. You had a worst of 27 in your list http://dl.dropbox.com/u/57645542/stagger-data.htm running everything and were unhappy. Now a stable worst of 24 makes you happy? The facts are: -it isn't that much important if you have 20fps or 60fps. But it is more important that the framerates are stable !!! In the moment I can see stutters which interrupts the simulation every 1-2 seconds for even about between one, two second. In this time I always loose control about an aircraft and autopilot begins to play crazy. Maybe I'm able to create a diagram showing Latency/Framerates in Advanced Weather. Though my computer is not the newest one, I would expect a much better behavior. -Advanced weather is indeed a high fidelity weather simulation. Together with the shaders, and especially lightfield shader, we get a very good simulation of the atmosphere already, which is needed for a more realistic simulation of flight. So due to this it is clear that it needs a bit more perfomance than other stuff in FGFS. But this doesn't explain those stutters. -Everyone here is impressed by the outcome. Everyone would like to use it. Compared with X-Plane or MSFS we can really be proud to have such thing! And say thank you for this contribution! So your hard work you did is highly appreciated by everyone. Here are people who does have enough experience and knowledge about Project FlightGear and its codes and especially nasal which should be taken seriously. That does not mean, that your opinions are not taken serious. It is quite the opposite. But I do see a wish by many developers and users to have both weathers combined, and even more important working without any stutters. And this means that some parts of your code maybe needs some overhaul. Even we do know that you have worked on the code in the best manner to have it fast as possible. Vivian wrote: Optimising code is bad. You might make it better for your system, but make it worse for everyone else. OSG/OpenGL do a pretty good job all by themselves vs Thorsten wrote: Optimizing code is badly needed. OSG/OpenGL don't do a pretty good job all by themselves for sufficiently complex tasks and that's a fact - been there, seen it - Advanced Weather without any optimization would drive you to single digit framerates no matter what system you run easily. It's all nice that you get enough framerate out of the water shader and can affort to compute cloud coverage in the shader per frame per pixel, but those of us not running high end machines would like to run it as well, and I am glad I figured out a way to make it 50% faster for me. You said it already: Optimizing code is badly needed. And optimizing can be done in many ways. The pure nasal code can just be optimized, or the algorithm can be hardcoded somewhere, or etc No idea if OSG/OpenGL is really the limiting factor. What Vivian wanted to say is, that something that works on your computer does not automatically must on other computers. As much as I know he has now a pretty good and strong computer. And I don't know what you do understand on high end machines. Today we have to seperate between computers with many powerful cores, but weak inboard graphiccards; computers with single or just duo cores with low rates, but strong, higher graphic cards; or such machines where you have the best of all. You can see it yourself: Advanced Weather is running fine on your system, but you have big troubles with rembrandt. On my system it is quite the opposite: advanced weathers gives me unusuable stutters, but rembrandt is really fine doing. Maybe we should handle this more like in our bug tracker: Unusable stutters with Advanced Weather What steps will reproduce the problem? 1. take any aircraft and start from any airport 2. select advanced weather 3. watch Latency and framerates What is the expected output? What do you see instead? Expected is a stable framerate, maybe with lower framerates than without advanced weather. Instead we get stutters which occurs every 1-2 seconds or even less, with pauses about 1-2 seconds. It is undependant of direction of view (cloudy parts vs non cloudy parts) and gets worse the more clouds are beeing generated. ... At least Optimizing code to try to prevent such issues feels for me like healing the symptoms, but not healing the real cause, whatever this might be. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats.
Re: [Flightgear-devel] Head-up: several Rembrandt changes
Hello, @/Kle: I downloaded the latest Git yesterday, and by enabling Rembrandt through the 'Internal Properties' dialog I get this lovely multicolored result: http://img515.imageshack.us/img515/8468/fgfsscreen133.png It never worked for me here. I always had to decide before to use Rembrandt or not. Also, I cannot activate it anymore by using the '--prop:/sim/rendering/ rembrandt=true' string on .fgfsrc, it can only be done by the 'Internal Properties' dialog inside the Program. Anyone else experiencing this? Said by Frederic in a previous posting: now: /sim/rendering/rembrandt/enabled instead of /sim/rendering/rembrandt before Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Thorsten, It is for Vivian. We seem to agree that a stable 20 fps is possible (I get it and Vivian gets it if he throttles down), but he aims at more. Which is okay with me. I understood it wasn't stable. That's why he was happy with stable 24fps. I probably misunderstood here. Well, I'm not seeing anything like that, and neither is Vivian - we were talking about frames delayed to 50-60 ms which are a noticeable stutter when you can run with 40 fps, not about second long delays. I agree that what you have way more serious and needs to be understood and fixed asap if that is possible. I tried the 777-200LR at CustomScenery Alaska with Cold Sector and visibility at default at the first 10min I had the mentioned stutters. But suddenly framerates stabilized and I noticed the less delays. So the scenery tile loading was the cause for stutters, so finally I could see your work in its all glory and got some nice screenshots. Without using the system monitor (which has an big influence on Framerates here) I have: With Cold sector, cloud density of 0.25 I had more or less stable 37fps not throttled. Delay had been about 60-84ms. With the Cub at Terrasync TNCM I get similar framerates and delays after tile loading, no loops disabled and settimer kept. With visibility set to 50km to keep tile loading time smaller, with all settimer set to zero and with disabling the loops I get 29-30fps throttled down and a delay of 34ms. Unthrottled I get 60fps and a delay of 30-40ms at TNCM! Then again Enabling buffer loop delay increase to average 50ms and gets less stable (20-98ms) Enabling now dynamics loop delay gets worse at the first second- then stabilization. (20-41ms) Enabling effect loop delay keeps between 20-41ms The same with timing loop. Again, all this with all settimer set to 0.0. Framerates changes its values according to the number of clouds. With the mentioned scenario I got always about 50-60fps at ground. Tropical weather is unusable for me. But similar weather scenarios with Basic weather aren't better. I did not yet tried other weather scenarios. So if you, or Vivian, or anyone else can come up with code or an idea that actually fixes a problem, you'll see me say 'Thank you'. Sorry, but this sounds even cheaper ;-) If we already had the solution, Vivian or me had already brought it up. But you are adressed here, as you are the developer of this piece of artwork. See it like that: If I have a problem with any product and don't find the solution, you will always try to ask the producer if he might have an idea as he probably does know his product better than any other! Nethertheless, we all don't know what you already had considered. And that's why all those cheap suggestions coming up. Like on the Lightfield shader issue it is better when you suggest a list of ideas which can be the issue. That might be many paths of possible issues, and any of those paths has to be tried to find out which is the right one. Vivian already suggested some paths, if you think this isn't the path to the solution, it would be good to propose some other paths. (As a side remark, I remember specifically asking here what people would like to see in a combined weather - so far no answers. ) Hmm... probably because when they want to have a combined weather probably an Advanced Weather which runs per default (METAR, real life weather fetch and all those nice scenarios we have in both) without explicit enabling and giving similar framerates like basic weather. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hello Thorsten, First again sorry when it sounded like rant. But I must admit I was dissapointed seeing the results on my system here. Having said that: To the best of my ability to determine from the screenshots, the skydome shader doesn't work for you (for some yet to be determined reason). As a result, you can see no haze and no change in the sky when on the ground, because the haze from that position would affect mainly the skydome. Since we're looking at close hills and buildings in your shots, the differences in fog for the terrain are not really apparent. As you go to high altitude (and presumably good visibility), more and more of the haze you see is created by the terrain shader rather than the skydome shader, which is why I'm guessing you see better results at high altitude (but then, there should actually be a visible mismatch between sky and terrain if I am correct). Thanks for that detailed explanation! I didn't see any error messages in the console so I guessed there shoulden't be any shader-problem, but good to know that there should be a change to see from the ground. Actually, no. All that needs to be on is the skydome shader button, no matter altitude or shader settings. When you move water or landmass above 4, the detailed version of the shaders come on. It is possible that the non-detailed version of the shader doesn't run for you either (Emilian told me yesterday of some implementation-specific things which my nVidia unfortunately tolerates without complaint). So my second guess is that you don't have an nVidia card. I actually have a new nVidia Geforce GTX460 with 1GB RAM. So that should be not the problem. I have tried with the skydome shader button on, and the effect was even worse. All colors went dull. So indeed for any reasons the shader seems not to work here. The GUI is actually rather fool-proof - it switches almost everything which is not compatible with the scheme off no matter where the sliders are and parses only the sliders which are implemented. Your problem is not GUI related. After your description it seems indeed so. As I've said a few times on this list already, the scheme runs with basic weather in principle, but the default settings may not be appropriate for the actual weather conditions. It's no technical difficulty to change these, but this requires decisions which I don't want to make without any feedback from the maintainers of Basic Weather. Which should be no problem, as from reading here on the list from time to time I can see that it is even wished to make this work available for Default Weather as well. Not all people can run Advanced Weather without having a bigger unusuable fps impact; on my system here (DualCore 2,6Ghz with 4 GB RA) framerates are now worse than with Default Weather. (That was different to last autumn...) I've done by now about 100 hours of flight in the scheme at pretty much all possible times, weather conditions and altitudes ranging from zero to 150 km. When working correctly, it is probably the most seamless scheme Flightgear ever had (the default scheme doesn't do suborbital flight correctly). I can still remember my first and second flight as pax in a glider 15 years ago. The scattering effect was even visible from 1000-1500ft AGL, visibility wasn't that great as you show in your screenshots. (less than 100km visibility) I actually had the impression from the various sceenshots and my own experience that it only works in higher altitudes. Sorry for misinterpreting. So what I would like you to do is: a) watch the console for any error message from shaders trying to compile but not succeeding b) get me a screenshot from ~20.000 ft with good visibility over land facing the rising sun at dawn with skydome shader on and landmass shader on 3 c) do the same exercise with landmass slider set to 4 Good, I will provide this this evening/ tomorrow, as I'm probably not at the computer until later evening today. Cheers Heiko -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hello Thorsten, a) watch the console for any error message from shaders trying to compile but not succeeding Absolutly nothing- no error messages, just the usual .dds-warnings b) get me a screenshot from ~20.000 ft with good visibility over land facing the rising sun at dawn with skydome shader on and landmass shader on 3 http://www.hoerbird.net/Lightfieldshader1.png c) do the same exercise with landmass slider set to 4 http://www.hoerbird.net/Lightfieldshader2.png Interesting Bug I found: http://www.hoerbird.net/LightfieldshaderBug.png The dull color at ground I mentioned: http://www.hoerbird.net/LightfieldDull.png All with a clear checkout, Hudson Build #447, TerraSync-scenery, default values I hope this is helpfull Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Hello Fred, In case you didn't notice, Thorsten screenshots are from altitude, not from the ground, with more clouds on screen, and at dusk or dawn. Put yourself in the same conditions to do the comparison I did try that- after some more tryings with different settings I found out that I didn't know yet that it only works with advanced weather AND at high altitudes (above 10.000ft!!) And that the shader custom slider has to be set to 4 and aboveand ...and. When I think of our average users about using ithmmm. Sorry when it does sounded like ranting, but I think there are some other things as well to consider: Not all pilots are flying in such high altitudes- what's about the typically VFR-flyers? And I'm sure that not all pilots here are flying at dusk or dawn. For me, at other times and on ground, the colors looks pretty the same like in older FGFS versions before shaders. Not what I expected after read Thorsten's description about his work. Sorry for complaining Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/ rendering/no-16bit-buffer=true in the commandline and a shadow map no larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in low vertex count situations like TNCM or a carrier - is that in the expected range? Let me correct you: not the vertice count is the bottleneck in Rembrandt and FlightGear- but objects number! Test it yourself: - create a simple cube in Blender (8 vertices) - duplicate in Object mode several times ( I did it around 1000x times!) So we have a model containing a large number of objects and 8000 vertices all about. - save it as .ac - used the ufo and replaced the UFO-model with the new object, and start FlightGear in Rembrandt mode Then I used the same model, but joined all 1000 objects together, so got a model with just one object but still 8000 vertices. I started at Kufstein/ LOIK with the CustomScenery provided by Christian Schmidt, detailed scenery but away from LOWI. The One-Object-model gave me full framerate of 60fps, the 1000 Objects model gave me about 20 and less And thats one reason why LOWI or other aircraft are quite difficult for some. They contain a lot of models. But each model is splitted up into several objects. Some are need for animation, but a lot not. Especially aircraft with complex cockpits and detailed instruments, especially digital displays not made using 2d-layers, naturally uses a lot of objects, which will then slow down. Of course such instruments doesn't need to cast shadows. So there will be another speed up when Fred is able to get back the no shadows-tag. And there is something else which can help: Fred made the shadows-cascade configurable at runtime. Not only you can improve the shadow quality with (smaller edges so it looks quite sharp)at close distance, you can also set the overall distance of the shadows with. I'm sure Fred can tell us a bit more about, but I found it already very helpfull! Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain Haze v1.3
Btw - with the recent GIT, I now get Rembrandt working with --prop:/sim/ rendering/no-16bit-buffer=true in the commandline and a shadow map no larger than 4096x4096. I'm getting ~9-10 fps out at KSFO, about 14 in low vertex count situations like TNCM or a carrier - is that in the expected range? Let me correct you: not the vertice count is the bottleneck in Rembrandt and FlightGear- but objects number! Test it yourself: - create a simple cube in Blender (8 vertices) - duplicate in Object mode several times ( I did it around 1000x times!) So we have a model containing a large number of objects and 8000 vertices all about. - save it as .ac - used the ufo and replaced the UFO-model with the new object, and start FlightGear in Rembrandt mode Then I used the same model, but joined all 1000 objects together, so got a model with just one object but still 8000 vertices. I started at Kufstein/ LOIK with the CustomScenery provided by Christian Schmidt, detailed scenery but away from LOWI. The One-Object-model gave me full framerate of 60fps, the 1000 Objects model gave me about 20 and less And thats one reason why LOWI or other aircraft are quite difficult for some. They contain a lot of models. But each model is splitted up into several objects. Some are need for animation, but a lot not. Especially aircraft with complex cockpits and detailed instruments, especially digital displays not made using 2d-layers, naturally uses a lot of objects, which will then slow down. Of course such instruments doesn't need to cast shadows. So there will be another speed up when Fred is able to get back the no shadows-tag. And there is something else which can help: Fred made the shadows-cascade configurable at runtime. Not only you can improve the shadow quality with (smaller edges so it looks quite sharp)at close distance, you can also set the overall distance of the shadows with. I'm sure Fred can tell us a bit more about, but I found it already very helpfull! Cheers Heiko P.S. Sorry, the no subject posting by me was made accidently- to quick hitting the button. still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random Buildings
Hello, Well done! A great enhancement! Now towns and Cities looks like they should! Here on my system Framerates are really good, but yes scenery loading needs some time- until framerates are stable enough to use it needs a much longer time. A very big surprise to me was that all buildings are landable- great for all heli-pilots! O.k., textures could be improved- but I guess we have some graphic talents out there, which can help- at least I hope. This, however, is the lowest possible setting on the slider - and is very tricky to adjust (just try to configure such a low value, you'll see what I mean). With todays GIT it seems to me that the buttons in all dialogs are much smaller than before- optical illusion, or does someone else noticed it? Actually, I have the same issue with the vegetation density slider. Does the range 0-10 really make any sense to anyone? A lower range would make it much easier to configure usable values on the slider. Agree- 10 is unusuable, and would be even unrealistic dense, even for woods. So in the moment RandomBuildings works perfect to me- even at LOWI. (6 years old DualCore 2,6Ghz, 4GB Ram, Nvidea Geforce GTX460, win 32 xp) Thanks and Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More Rembrandt Feedback
Hello, Frederic Bouvier wrote: This is just designers' art. The light poles don't have hard edges. With a carefully designed light volume and well tune attenuation parameters, the hard edges will disappear after some iterations. Thanks for the input here and on youtube. I tried your tips and tricks, and indeed it works. Unfortunately the EC130B4 isn't well for this, as the landinglight is directly behind and under the cockpit so I didn't managed it there. The updated EC130B4 helicopter btw. is now in FGdata. Frederic Bouvier wrote: The cost of shadows is the difference in fps between night and day, as shadow rendering is disabled at night. The scene is rendered in the shadow map with front face culling on, so the terrain is only draw in the shadow map when the sun is near the horizon It seems to me that the sun don't must be quite near the horizon to have selfshadowing terrain. Sometimes I see some shadows caused by the terrain even at noon in the summer. (airport-edges...) Nethertheless- perfomance has much increased now! :-) Depending on the aircraft I can get now 30-60 fps at noon with materials-dds.xml, trees and clouds with my standard settings. That's compared with 2.6.0 only a little less. Only in regions with many objects like LOWI framerates are much, much lower compared with 2.6.0. To my surprise hight-vertice-count aircraft like the VelocityXL-RG by Gary Neely shows pretty good framerates (around 30-34fps) in cockpit mode compared with other similar aircraft with lower vertice count and lower number of instruments. No idea how he managed it... The Cub behaves perfect- here a little video showing beside the cockpit shadowing also the terrain shadowing: http://www.youtube.com/watch?v=Zcj7jpuhLeU Please watch in HD Btw.: Terrain-selfshadowing was a feature only in MS Flight. It seems it was... ;-) Thanks for all the work Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More Rembrandt Feedback
Hello, Does anyone know whether FG is unique amongst desktop simulators in offering this? I have no experience of X-Plane nor FS-X. Yes, X-Plane 10 also makes use of deferred shading. They just named it Global Lighting/HDR. Framerates aren't better there as in FGFS as now. The difference is only that landinglights there looks much smoother (no hard edges), the same for the shadows. But we have a really good start as a non-commercial product. Very promising, especially as an OpenSource-project. Thanks Fred for your great work! Can't tell about FS-X, but I guess it is a similar technic. I've noticed significant slowdown on my computer in the following circumstances: - Forests (e.g. KHAF). Having not looked at the code, my guess is that some NodeVisitor for the rending is delving too deeply into the OSG tree for the random vegetation. - Urban areas. My guess here is that is purely due to the number of models being rendered, each of which is casting a shadow. I know that there are still optimisations to be made, but could I suggest a property switch to limit shadowing to the user's aircraft? IMO the self-shadowing in the aircraft cockpit is the most impressive part of Rembrandt, and the combination of that plus shadowing on the ground might be an acceptable frame-rate compromise for many users. Agree to Stuart. - Forest seems to need much more perfomance than before. Other things I noticed: - Scenery-terrain seems to cast shadows. Visible especially shortly before dawn or shortly after dusk. Great feature if so, but seems also need a lot of perfomance. Maybe it can be made switchable? - Comparing different aircraft-models showed me, that not the general number of vertices or even faces is the limiting factor, but the number of objects. Especially instruments which makes use of many objects, so using non-shadow animation would be very recommended for instruments. -I do like when scenery objects cast shadows. But Do we need that in a far distance? Maybe we can have a distance limitation additional to Stuarts proposal? To my surprise it isn't very difficult to make aircraft rembrandt-compatible. The combined-shader is already converted and especially the IAR80 looks really cool with shadows. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated Cub and c172p for Rembrandt
Hello, Martin Spott wrote: Service manual says: [...] Beginning with 1971 Models, the landing and taxi lights are located in the nose cowl. The D-EEQA (on the picture, sitting in wet grass) is a 1978's Cessna F 172N (serial 1697) and FlightGear's is, as far as I remember, a 1981's C172P. Therefore I'd say the lights belong into the cowling. I didn't had any service manual when I started and announced the c172p-update and it seems I did not informed myself enough about the c172-history for the update. But I used a a bunch of images as reference. Look here: http://cdn-www.airliners.net/aviation-photos/photos/6/4/3/2081346.jpg http://www.airliners.net/photo/Cessna-172P-Skyhawk/2076182/L/sid=40c47e6e201184197341cb50f65a74cd And according to wikipedia (http://en.wikipedia.org/wiki/Cessna_172): The C172P.model was introduced 1981, but 1982 the landing lights moved from the nose to the wing to increase bulb life Maybe that's why I was mistaken. We can change now the light to the cowl to match 1981's version, or easier rename the model to the 1982's version. Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Rembrandt - Some Feedback
Hello, I updated my FGFS yesterday and today, after a whole while. Of course I tried Rembrandt and I'm impressed- finally shadows again! Rembrandt does work here without any error messages. (DualCore 2,6 Ghz, 4GB RAM, Nvidea GeForce GTX460) What I noticed is, that Anti-Aliasing does not work, and the quality of the shadows is not good yet, though using the 4096px-size. See image [1] below. Changing shadow size at runtime gives me following error message: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) Sometimes I see some Z-fighting, but can be explained with the strobes/beacon animation. What I do like is, that even the cockpit has now self-shadowing- can look great! See Image [2] below RAM-Usage looks o.k. to me, not much different as before. Framerate-Perfomance is different: With default sceneries, disabled random vegetation and disabled randon objects I get between 30-60fps, depending on view and complexity of the aircraft. With enabled random-vegetation framerates goes down to less than 30-15fps, so about the half I got before. The density of random vegetation is set 1.0. That's something I did not expected, as the 3d-clouds doesn't show this behavior. To my surprise some aircraft does not have any problems with random vegetation enabled: First I thought that if an aircraft has the more faces the more power we need to achieve a good frame rate, but looking at the RAH66 from the forum, the B1b Bone or a converted MSFS-model with about 5vertices it seems not the case. On the other side the C337G or the C172p has a quite bad framerate compared with. Maybe face-numbers, number of objects objects or xml's as reason- I don't know, I will test it deeper and provide the numbers here. The 3d-clouds shows some z-fighting as well, and the draw order seems to be broken. See image [3] below With Rembrandt disabled, some shaders are broken, I already filed a bug-report, and work is going on there. It looks promising, but also still like a long way to go, especially as many aircraft and shaders has to be adapted. [1]http://www.hoerbird.net/fgfs-screen-588.jpg [2]http://www.hoerbird.net/fgfs-screen-586.jpg [3]http://www.hoerbird.net/fgfs-screen-587.jpg Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looking at a nice project from outside
No, for a user it matters if he has to download a scenery from one place or from many partly incompatible scenerys scattered around the internet. Sorry, but being also a user I can tell you that it doesn't matter to me. And I'm pretty sure, a lot of others users as well! I fact, I have to say many thousand big Thanks to all developers who not only contribute their shapefiles to Martin's database, but also generate their sceneries and provide their work to all other users to test and use! Of course, it would be better to have them into one database aka TerraSync! TerraSync is a great feature, even outstanding compared to other Sims. But currently it only updates objects- no landclasses and other things. And that's the major problem all behind, as already said. If this would be solved, I'm sure more people would feel proud to add their work to TerrySync. Btw. my scenery settings looks like that: --fg-scenery=C:/Programme/FlightGear/LOWI_v850-v2_Scenery/LOWI_v850-v2_Scenery/Scenery;C:/Programme/FlightGear/EDDF-ELLX-ETAR;C:/Programme/FlightGear/flightgear-terrain;C:/Programme/FlightGear/Alaska;C:/Programme/FlightGear/terrasync Downloaded TerrySync files are still there, but only there where such detailed sceneries like Netherlands, Belgium and Statto's sceneries aren't available. The latter one, the MSFS way of doing thing, is a horrible mess for the user. That's why i suggest do promote the one scenery fits all way. It is a not a mess. To my knowledge we are still a FREE and OPEN source project. And so the user should be FREE and OPEN to decide which Scenery, aircraft etc. he wants to use. And I think that GNU GPL is already very powerful, and with that attracting. No need to force users to do anything- that is a bit against the OpenSource spirit of FGFS. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
I have created now a merge Request including the ratings of aircraft I have been involved, I hope it is not too late. It is :-( Of course, it's never too late to be included in the master branch, which means that it will be part of 2.8.0 coming out in 6 months from now. But, submissions for the 2.6.0 release (with the exceptions of bugfixes) were closed one month ago. Cheers, Durk I missed the frozen/red state datum, should take it in my calendar :-( Looking forward to the next stop 2.8.0, I would be happy if someone could merge my changes it into master! :-) Regards Heiko -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 70, Issue 11
I never refused improvements (Long Ez, Velocity XL, Carreidas 160, B25, A26 Invader, I16, UH 1, etc. ) So stop slandering without knowing. Which isn't true. You refused my improvement to the Velocity XL due to personal reasons, and you refused the contribution by another person due to missing respect. And there has been some more examples in the past! Read from here: --http://www.flightgear.org/forums/viewtopic.php?f=4t=8287p=81558hilit=Velocity+XL#p81602 You had to be remebered by several people how OpenSource and GNU GPL is working! Disease, memory loss, madness, desire to hurt or something other I do not know lol And that's exactly the behavior which created the mess! STOP INSULTING PEOPLE FOR JUST HAVING A DIFFERENT OPINION! still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fair practice autorisations
All people need to know that 60% (or more... it's approximate) of aircraft available for flightgear are created by helijah. More than 80% of them are totaly crappy ! They aren't a good point for FlightGear project ! vs. If you want to blame someone, you have to blame the people who made the decision to make all aircraft in the repository available to the end user as well. But that point has been made a while ago, it has led to discussions about a formalized rating scheme for aircraft, that scheme exists and is being implemented, more and more aircraft are rated, so now the end user is getting a fair chance of knowing in advance if the aircraft he is about to try is finished work or not. I stumbled some time ago about a review of FGFS. As this time about 50% of all aircraft downloadble was by Mr. Baranger. The reviewer indeed managed to test only the aircraft by Mr. Baranger, and the review result wasn't very good...(unfortunately I don't find it anymore between the many FlightPro...xxx o Google.) I agree that OpenSource allows to add unfinished aircraft and that it can be a Plus for OpenSource. But that doesn't mean that you automatically have to do this! It can be also a Minus as it seems for me as our system has been abused here, and yes, the fact that all aircraft are downloadable without any sign of their state may FGFS let look bad! But I haven't heard yet, that the Download page will show the rating! Is there something coming now with FGFS 2.6.0?? But exactly this was one reason when I started the discussion about Aircraft status in the forum. *shrugs* I would assume that the average user is capable of some rational thought. The FG base package comes with hand-picked aircraft, so on your first contact with FG you learn how well they can be made. From there, it's a realization that in open source not every work is equally well done, and a quest looking for the aircraft you like. We are cross-platform, and as there are many people out there using Mac or Windows, they aren't in OpenSource as you or others here are. As a new user of FGFS, heard how realistic FGFS is and how better than MSFS, I would feel cheated if I see a very nice aircraft exterior on the Thumbnail, but when I use the aircraft I don't see any instruments, and the flight behavior being completely unrealistic. It will be good if FlightGear community take conscious of this ! Do you honestly believe that you're the only one who has realized that there's unfinished work in the repository? I mean, seriously? Seems to be a language barrier here- he doesn't meant to take conscious of unfinished work, but the effect of currently about 200 (!) unfinished and mostly unusuable aircraft. We can't say that we are realistic but providing more than 60% of unrealistic/unusable aircraft. And again: and of those aircraft about 5-10 are suffering from serious licence issues! Please, seriously change your perspective in this discussion. Things may have their use even if you can't see that - just try go looking for it then. And please, please, read this here: http://sourceforge.net/mailarchive/message.php?msg_id=28840950 The fact that we have now 3 different threads about the same topics: DC3, licence violation and cooperation in an OpenSource project, makes it difficult to see where the real problems are. Or better described by David: It's fabulous how one could make a mess, in an almost untracable way if you don't follow the mess in live time. It's easy to mix up conversations in different posts to cross the comments to make the story in your favour and make it non understandable by creating holes into the discussions for those who didn't followed. A good example is this thread on the devlist which is finally split into different posts! There's one that is seriously skilled and have nice techniques! I take note of them. still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft ratings on the download page (was Re: Fair practice autorisations)
Hello Stuart, I've managed to get this done, and passed the results to Curt, so the 2.6.0 Aircraft Download page will show ratings for aircraft, or a ? if the aircraft has not been rated. Many, many Thanks for the work! I have created now a merge Request including the ratings of aircraft I have been involved, I hope it is not too late. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft ratings on the download page
On a slightly related note, stumbled accross this: a HTML5 JavaScript library to render 3D models in .ac format using WebGL. Might be a nice addition to our download page... Demo: http://inmensia.com/files/hangar/flight-gallery/index.html Source: http://code.google.com/p/hangar/ Hmmm... The latest version of Opera doesn't show me the models. Mozilla Firefox is able to do, but with render artifacts. I would rather see a search system, so people can search for their wanted criterias. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
Hello, My last two cents about [snip] ...Above all, the problems shouldn't be mixed together. If there is a problem, that should be addressed, but not by creating a new problem. If a person has reacted improperly in some context, it doesn't give grounds to calling his work worthless in public. If the Flightgear project offers half-finished aircraft for download to the end user, that is not the fault of people commiting unfinished work to GIT. I don't think it's particularly difficult to see where the real problems are. I just think there are some personal grudges obscuring their identification. [/snip] The whole text was a good summary. But the whole discussion and the issues have been just symptoms of following problems in my eyes. And I'm very sure, if we don't solve that we will have such a discussion in the near future again! 1.) to large FGdata-repo/ not transparent rules for committing 2.) aircraft rating scheme and Download page 3.) apparently inconsequent handling when licences has been violated (intended/unintended) about 1.) We really need a splitting of FGdata! Even if FGdata is the place for developement I don't see the need to download 10GB to have more than 200 aircraft in developement most of us not interested to improve due to different reasons. It has been already discussed here: http://wiki.flightgear.org/FlightGear_Git:_splitting_fgdata and in the moment it sounds good to me when it will really work as described. about 2.)as the Download page will now use the rating system I hope this will solve this problem. We should really not ignore the fact that a lot of users will measure the quality of our simulator with the quality of aircraft we offer. We are a flightsimulator, it is all about flying and not only just showing nice looking aircraft-model. about 3.)already part of the planned splitting Fgdata. Such issues may happen due to different reasons (intended, unintended...), but needs some better handling. In the previous discussion about the current licence issues I had the feeling that the issue is underestimated and not taken seriously, but I might be wrong here. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 70, Issue 9
They seek only to discredit me in the eyes of all. I think I've proven myself many times and I have never refused any improvements for my aircraft hangar. Except, I confess, for JSBSim (and even if the work is good why I refuse, even JSBSim ). Beside the fact that it isn't quite true, you are discrediting yourself with this words, don't you notice it? But this list is primarily a development list. I would like people who want me to do harm, do to other places. Of course Oliver, there is no question of you in this sentence :) So why don't you keep to your own words, and keep that away from this list?! -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fair practice autorisations
For what its worth , I see several of my aircraft in this hangar and I wasn't asked permission for that so sounds like a ridiculous argument from the start . This team should others as they wish to be treated .Good place to end the discussion. Several? I only see one aircraft (Aerostar 700) of yours!! Beside the L39 Breitling, most of all others had been started by Mr. Baranger, who claims ownership and want to be asked as well. But anyway- the one (as David called him) seems to managed what he wanted. Congratulations! I really recommend all participiants here to read along what David van Mosselbeen wrote- it will light up about some things! Here you go, in the case you missed it: http://sourceforge.net/mailarchive/forum.php?thread_name=55540383887f9aa7959911b6affbb8be%40sun.pinguin.localforum_name=flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 70, Issue 8
Sorry, without any offense, I have to disagree in following points. The original author of instruments panel is Alexis Laille Absolutely and totally false! The first version, albeit a very simple, is my work. Alexis Laille has nothing to do with that! When he improves/ replace the panel, when he adds things to it, then he has something to do with it. Then this panel has multiple authors. You and him. my aircrafts: Not because they are mine, but simply because they are available in my hangar. When you put it on your homepage- as long it is under GNU GPL, others can use it and modify it as long they keep to GNU GPL. And when added to FGdata, it is available on a public server under GNU GPL, where it can be used and modified by everyone. It's the world upside down here. These people change and improve a project that I started alone. And it is me that must to ask permission. Many authors aircrafts will die laughing when they read that. To make it clear: They created a fork or your work, which is permitted by the GNU GPL licence, and they can do what they want with this fork. Simply they just aren't happy what you did: let them contribute, insulted them when there was a disagreement, they decided to go on without you by creating a fork, and now they have to see that you take things from them. Legally right, as GNU GPL does not forbid that- but morally? Would it not be better to settle the source dispute, apologize for some hard words, and work together in peace? At least, that would be what real men, not kids, would do in such case! It is sad to see these people try by all means to destroy and damage FG. I can't see that. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fair practice autorisations
Hello, I agree he is the owner of the model, but he is not the owner of the FlightGear project. I would disagree here in one point. From my understanding of the law, he is just the owner = copyright-holder of the parts he made (basic 3d-model, basic .xmls), but not the parts which had been contributed by others (like the systems simulation etc. as listed by Clement de l'Hamaide here). So not the owner of the whole model. There is just a rule in FGFS-project, (and maybe other OpenSource-Projects) that the starter of a sub-project is also the main-maintainer, and has the right to accept/ refuse contributions to it. You can accept this, or not. Anyway, being OpenSource you can create a fork and try to make the original source better. When the PAF-group decided to go on without Mr. BARANGER, they in fact created a fork of the DC3-Project. Which is allowed and a major part of OpenSource. GNU GPL allows that Mr. BARANGER can take use of things developed in the fork and port it over to his own project, and of course the PAF can do the same. But I must admit in this situation it has a bad taste and I can understand the dissapointment of Clement de l'Hamaide. But here it's not the problem of who is the author model. The problem is = the minimum politeness is to ask to the PAF team if we accept to see our contributions committed. I know the GPL give the possibility to commit without asking anything but here we speak about fair practice. vs When you decide to download a package from a website and upload it on your website and GIT the minimum politeness is to ask to the author of the improvement if he's agreed with this isn't it ? Indeed GNU GPL allows comitting without asking. It does not care about politeness. So this action would be legally correct. But I have never seen before that GNU-compatible things which had been developed outside the usually FGFS-developement process - as an example new users creating a GNU-GPL compatible contribution to FGFS- had been committed to FGdata without asking the author before. I have never seen that Gijs, Durk, Curt etc. picked up any work and put I into FGdata without asking the authors before to do so. It would be legally correct what happened here, but I'm not sure if this is really how FGFS works. I would be at least also not happy if someone creates an AW139, use the parts of even the whole model in developement of my own work resting outside FG without asking me, put it into FGdata, but maybe even refuse to let me contribute to it. Though it would be legally correct, I would definitively not be happy! I do know: Release early, release often, but it is difficult as long only a handfull of people has commit rights and you have to create merge requests to commit to your own work. In the whole discussion there had been some further statements which gives me some headaches: When the team of the PAF has decided to prohibit access to their work to me, they also requested the opportunity to put it on ILM. There are two possibilites to understand the meaning of this sentence, not sure which one is really correct: 1.) real prohibited access and that would be a violation of the GNU GPL-licence. A GNU GPL-work (and especially the Source Code) may never be prohibited in access to anyone! 2.) intended improvements was refused by the PAF-group for some reasons At least As I could follow the DC3-developement on the FGFS-forum and in the PAF-forum, I have never seen a prohibited access by the PAF to the DC3. The released downloads was available for all, and the developement process even readable without registration in their forum. No idea about 2.)... If the team of the PAF not appreciate the principle of respect of the original authors of the open source, they go to make aircraft for FS X or X Plane. In addition, it can make money Maybe I did understood this sentences wrong. But the GNU GPL licence does not say anything about respect. As long you do keep to the licence you already respected the original author. And as it is OpenSource other people can take the models and do what you want as long you keep to the licence. Even if you don't like it. Maybe the negative side of OpenSource. And yes, you can also make money with GNU GPL-work- it is allowed. tired of seeing all these kids puerile want to use the work of others, to obtain recognition as authors. Here, in this case it even indeed like that, that those kids made a manifold work with all those scripting, improvements etc., created a fork, and the project starter as not being part of this fork took, better said used their work and put into his own fork. I my eyes this action is nearly exactly what isn't liked in the statement above. And to describe a group of people in an age between 15-40 as kids is not very nice And back on the 5 or 6 files with licensing issues in my airplanes is ridiculous. ... Because most have been fixed. There
Re: [Flightgear-devel] Shader performance
Thorsten, And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. No, you can't say that in general. It quite depends on what you do and what options you use. Whatever you compute, it costs some amount of resource, and how long your frame takes is determined by the slowest element. Gary adressed those creating the 3d-models and aircraft in FGFS. Of course, logically you will always run out of GPU power at a certain vertice count which inludes all vertices (aircraft, terrain, clouds, trees...). But GPU's getting better and better today, but still the shape of the aircraft does not need hundred of vertices to make it look smooth. And yes, terrain itself has a big influence on framerate and perfomance. I can remember very good the time (2006/07 ??) when the first detailed Custom Scenery made by Martin Spott and Ralf Gerlich came out- I noticed a good hit on the frame rate, which was only due the more use of terrain-vertices. But that was with an old one-core processor and a very old GeForce 5200... Today I notice that even increasing the visibility no real framerate hit- even with 120km visibility. But a big increase of RAM-Usage. But again: Gary was talking about 3d-models like aircraft. And that was what I adressed as well. I experimented a bit with the different aircraft, and it always turned out that especially Nasal-scripts, and sometimes some .xml's has an big influence of perfomance. Bigger than an high vertice count. Problem is- this behavior depends a very lot on the hardware. In the forum you will find a very lot of people who seems to have an older computer, or a simple Office-computer with low graphic-perfomance. But for instance, you told in the forum that you are running a lower than 1 value of cloud density because of performance reasons. Which means that you are seeing the impact of the 3dcloud vertex shader as limiting factor, not some Nasal or xml, because what the cloud density slider does is reduce cloudlet (=vertex) count. GW on the the ocean gives me even with density =1 about 50-60fps (Fair weather)- when I'm inside the clouds and the full screen is covered with cloudlets I get much, much less (about 15-30fps). The limiting factor here seems to me the transparent textures. The LW does use less cloudlets even with density =1, and so less vertices than GW. Still I can see a higher use of CPU and lower Framerates. I can see what you wanted to say me- and I do see, that you have make great work with your Nasal-driven weather-system. You showed what is possible by using Nasal-scripts, and used this in a very intelligent way. I guess my bottomline is that any code running on a per-frame basis should be made more efficient when it can be made more efficient, regardless if it is currently the limiting factor for someone or not, simply because it may be the limiting element for someone else. Yes. And as Nasal-scripts has a natural limit of perfomance compared to code integrated into Simgear/ Flightgear your work will have much better perfomance if as much as possible has been hardcoded. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Quote: #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. And that's a point of frustration to me! Because no one, not Tim Moore, not me, not anyone, did say this! The wiki article is btw by Tim Moore. But they said, that the bottleneck of GPU's is not the vertice count, but other things. That never meant that you have to use many vertices as you want. ... As many vertices as needed- not more or less! From http://www.flightgear.org/forums/viewtopic.php?f=4t=6030 No one wants to see edgy aircraft as we still have in the repo. But also not oversized models like the Vostok-1. The other big problem was until now, that we didn't had a proper LOD-System- that made it difficult as well. According to TorstenB that has been improved a lot now. And especially in FGFS not really Vertices is one of the big problems, but .xml's and nasal-scripts. It is interesting to see that other Sims like X-Plane and in the past MSFS uses models with far, far more polygons and vertices than we do, and still seems to have good perfomance. How can it be? And there had been an other problem in the past and now: -Many misleading statements about that issues and no tips and helps for those interested to make it right. -People who had more of less the knowledge but kept them for themselves, instead of helping others to make their work better. Or used this to simply showoff. But that's how FGFS-Project has ever been: a tank full of sharks- survival of the fittest. Cheers Heiko -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear used in a worldwide unique paragliding simulator!
Hi, found by accident today: FlightGear is used in a worldwide unique paragliding simulator! ActiveFly is a simulator just for paragliding. It let's you practice paragliding on the ground. In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated. The brakes are extended and retracted via servos, simulating steering forces as they occur in a particular situation. The pilot will try to keep these forces constant by pulling or releasing the brakes. His actions can be viewed on a monitor and subsequently evaluated, allowing him to check the results and monitor progress as he develops his piloting skills. quote from www.activefly.com/simulator_en.htm. As visualizing system they use FlightGear. Some bigger images which shows the sim in action: http://aufwindfreunde.de/fotoalbum/simulator_training_27022011/simulator_training_27022011.htm Video: http://www.youtube.com/watch?v=YFcHebPaiEsfeature=player_embedded Maybe they should use some of our new generated sceneries. But great to see how FlightGear can be used in many ways! Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft issues: Vostok-1, dc-3, dhc6, CRJ700, pa24-250-CIIB
Hello, * dc-3: Very nice cockpit work - the manual needs an update though, starting the engine seems to require at least one more step than advertized (the selection of a fuel tank). Even then for some reason I got only the left engine on - repeating symmetrically what I did never started the right engine until I used the autostart function. According to the DC3-Thread in the forum (http://www.flightgear.org/forums/viewtopic.php?f=4t=13629start=90#p146252) the developement group decided not to work with helijah anymore for some known reasons. Obviously they will make further work and improvements on the DC3. But it seems not to make it's way into FGdata, at least not by helijah. Difficult situation But I'm more concerned about some licence infringement of helijah according to the same thread in the forum. I hope it is not true, though I was already aware of one infringement. (Original Airwolf-sound). * dhc6: Nice to see more details in the cockpit. Just, how the hell do I switch all the warning signs off? After starting the engines, the whole warning panel lit up (which I know from some other aircraft as a test mode), but the lights never went out. Plane was flying fine though. Look at the Overhead panel- there is a switch called caution lights- just disengage. But I'm not sure if this switch is realistic simulated. Cheers Heiko -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Aircraft issues: Cessna Citation-X
Hello, I updated my FGdata today, and wow- the Citation X has improved! Especially the Primus Display are great- the NAV map was a long missing feature! I also could see that the Autopilot has been improved and works now like it should: a real FLC-Mode! But I have problems with the locking on ILS. Whenever I engage the Aproach-Mode in ILS/NAV-Mode the aircraft make a barrel roll and heads down to ground. As an example: KSFO 28R NAV-Mode, heading-selected to intercept the LOC. Engage Aproach-Mode- when it captures the ILS, it makes the roll down to the ground. Am I doing something wrong, or is it a bug? Beside this issue, it would be a candidate for the Base package for me! Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] deteriorating cull performance kills fps
Hello, Also a different issue: I seem to recall there was a golden era when model loading was nicely done in the background, not causing severe stuttering in the display. Nowadays if I look around the scene, FG freezes for seconds at a time. I noticed the same some while now. I thought that it came from my not so powerful system, so I never brought it up. I can remember that it was much better in earlier times. I tried some various fgfs.exe (the first cmake one, and an older MSVC (August) but I could never seen a difference. I could compare only with 2.0.0. Unfortunately not yet with 2.4.0 And indeed even with full AI-traffic, no stutters there. Aircraft which needs more CPU-power due to heavy use of nasal-scripts like F14b or EC135 increases those stutters while flying around. CPU utilization increases together with those stutters. Switching off the shaders doesn't make any difference. Throttling the framerate down makes the stutter only smoother, but they won't disappear. Don't get me wrong- I still see between 30 and 60fps- but compared with 2.0.0 with a lot of stutters. No real idea, but I can also imagine, that model loading in the background doesn't work anymore as I was used to it and my be one possible cause for this behavior. Any more information needed, before I put this into the bug-tracker? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] cessna c172p cockpit (2) + ambient light level.
Hello, Hi Everybody,thank you for all your replies. I have downloaded and compiled 2.4.0 from the website. I have cloned fgdata on my local machine. Until I compile 2.5.0 from git, I am cheating by using the data from 2.4.0 + symlinks to the c127p and Instruments-3d folders from fgdata from git. I don't know how evil that is, but this is only temporary. Between 2.5.0 and 2.4.0 is already a difference in look, especially in lighting. And comparing 2.4.0 with 1.9.1 is- well- comparing apples and oranges. 1.9.1 was using plib, 2.4.0 is using OSG and has the shader effect system. Skydome has massiv changed and so the lighting. Btw: you have heard that in just two months we will have 2.6.0? I have a question regarding the amount of ambient light. It seems to have changed a lot since 1.9.1. This is particularly obvious when flying towards the sun. On my monitor, with a gamma close to 2.2, the panel and the instruments are getting hard to read. This will not be a problem with glass cockpits. I imagine the sky + skydome illumination model has been modified improve realism on the landscape. Please look at this screengrab, and click on the following one:https://picasaweb.google.com/lh/photo/T1tLqlebp0PPJRdQDXXZ8LtBKth8brfvXTX_6GVpOLg I saw a post by Curtis Olson regarding non-illuminated sides of materials, but the Cessna materials ambient values don't seem wrong.http://sourceforge.net/mailarchive/message.php?msg_id=24093698 The ambient values are slightly off, but nothing to worry about: www.hoerbird.net/C172pambient.jpg With fixed ambient values: www.hoerbird.net/C172pambient_avf.jpg A small hint from me which can save lifes: When developing, especially on the most important default aircraft, make sure that you have the latest Developement version aka latest GIT. FGFS reached critical mass and the developement process is quite stunning for an OpenSource project. Cheers Heiko -author of the 3d-exterior and panel c172p- -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Announcing Project Rembrandt
Hello, Hi All, i am so excited I couldn't resist to share the first milestone of my current project : http://frbouvi.free.fr/flightsim/project_rembrandt_1.png As the name of the project hints, this is only the beginning. Regards, -Fred I thought cristmas times begins next week? Man thanks for the present you are showing to us here. I guess these are shadow maps, right? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Trying to get more performance out of the 3Dclouds!
Hi, I read that X-Plane 10 is using a complete new system for clouds (LOD based): I haven't seen this in action, and don't know how good this really is. I have tried the X-Plane 10 Demo. I have a DualCore 2.6 Ghz, 4 GB Ram, Nvidea GTX460. While graphic looks really good, and the idea behind the new clouds system seems to be a major progress for X-Plane, I must say, I'm rather dissapointed from X-Plane 10. Even with low settings and (!)clear sky I only get barely 30fps. With some clouds, it gets down to 20fps and less. I didn't had the chance to see the clouds at max settings. And this even gets worse using a aircraft with modeled 3d-cockpit. And forget about the fancy HDR-lighting- 7fps was the maximum with. Their recommendation is to have a more modern Multi-core computer for using X-Pane. So I'm not sure if this will really help us. While trying to get the best settings for my Alaska-Screenshots: http://www.flightgear.org/forums/viewtopic.php?f=19t=14482 I noticed again, that the most problem was the transparency right after the amount of cloudlets. Thorstens Local weather seems to behave sometimes better than the Global weather, sometimes worse. Difficult to tell when and why. Transparency kills all- that's the main problem in my eyes. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Jenkins Builds for win32 down?
Hello, I wanted to update FlightGear today. but I noticed that the last win32/64 builds has be created a while ago, though I can see a lot of new things has been added to SimGear and Flightgear since. It looks as currently no win-builds are possible, as OSG, FGRun and TerraGear Builds are missing as well. Anyone knows why? Thanks Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lit the lights!
Hello, It isn't really recommneded to use more than the provided OSG-Lights in FGFS for some reasons. Bur for cockpit lighting we have in 2.4.0 and 2.5.0 ow a lightmap shader, which might be more interesting Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Hello, I just noticed today that the textures folder in scenery growed from 50 MB to ~200 MB. But I don’t see that many new textures ? I read once here that the benefit from getting DDS is also we get smaller file sizes for the textures. But now I see textures like crop (and cropA) DDS files that take ~20 MB. Is this for testing purposes only, or do we use the space we get by splitting aircrafts in near future for the textures ? ;-) No one said, that the benefit of .dds is smaller file size! The benefit of .dds is, that it can be loaded much, much faster into Video-Ram as mipmaps can be saved directly into the texture. With other formats it has be done seperatly and that's slow. So perfomance has even increased with. Quality compared with other compressed texture-formats like .png is btw. much higher. And Mipmaps also allow some interesting effects which you can see when you enable the use of .dds-scenery-texture in FGFS. Btw. the size of the texture-folder is compared with the aircraft-folder really, really small. Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
And btw. there have been only 4 or 5 replacements/additions for covers ... Thanks, I will do so. And where do I find the lossless origins now in the repo ? Do the origins co-exist in the repo, as png, or as GIMP files ? Ouch!! 1.) the whole .dds-texture are currently additional in 2.5.0 to the old .png-textures. When using FGFS you have to decide if you want to use .dds or .png via FGRun or comand line. 2.) there have been much, much more replacements/additions. The whole rwy-textures has been converted to .dds, and many other textures as well. 3.) this whole thing is part of current ongoing shader-effects and texture work, announced by Vivian and Emillian here on the list. This can bring us a improved translation shader, more realistic water-effects with ripples, foam etc. depending on wind and rain, a flutter-effect to flags, reflective rwys depending on rain In many cases the original files are the .png. And when new textures added as only .dds then take Gimp, add the .dds-plugin, open the file and see: this is the origin! ;-) Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Textures sizes, DDS
If your using dxt compression, which is why most people use dds, then it is NOT equal to the original image. Amount of degradation will depend on the image, resolution, type of dxt used, etc..but will never be the same or better quality. This applies to every texture file which use compression. So it belongs to .png, .rgb and .jpg as well. I never heard that anyone asked for the source here There is always a degradation, the question is, is it visible to human eyes? -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
Hello, Ouch ? This was regarding about your statement about the 4-5replacements/additionals and maybe I'm wrong, but I think I can read something between your lines. You are not happy with the conversion to .dds-files, right, though you didn't spoke out yet ? With .dds editing and reediting we will indeed have problems, as the qualitity will decrease each time, like you and Jacob said. That means we would need the original raw-texture-file in FGdata as well, which will increase file-size. I guess, that is what you want to say here, right? still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
Hope so ;-) With the current setup you can for example commit (and accept merge requests) for your EC130:https://gitorious.org/flightgear-aircraft/ec130 But I want to give commit rights to my wife to my repo, without asking you, can I do that ? Why not ? What gives the team the right to decide if my wife could be contributor in my aircraft project or not ?! When you start on a new aircraft and would like to have its repository under the FlightGear Aircraft project, you do have to ask one of the people from the team: https://gitorious.org/+flightgear-aircraft For every single aircraft ? Hm, everyone ? You also have to contact that teammembers when you'd like to get access to an existing repo (or give someone else access to your aircraft's repo). Sorry, Peter is not here since six months, but Paul - ok, he does not know a lot about your project - but he will give access to Alex, to update Sabins repo permissions. Hmmm... yep, that are indeed some good arguments. It would even allows to have duplicate aircraft, maybe even under different licences. The possible disadvantage I see with hangars is, that people might have problems to find their aircraft they want to have. User want to have a specific aircraft would have to dig through several hangars with a big mix of different aircraft- Unless we find a way like a search engine (like AVSim.com or X-Plane.org uses) where people just type in their wishes and get a list of possible matching resultats. Possibly I haven't earned the right and I can understand that. But I would like to learn and understand the procedure for how one earns these rights, and maybe others would too. The procedure is to ask :) Aha, really?- in the 5-6 years I'm contributing to FlightGear-Project I did this twice. I never got an answer. And until now I can only guess what was the reasons for. Maybe I didn't produce 5 cheap aircraft a week? ;-) Or maybe there had been more serious reasons, but without knowing them I had never the chance to change it. At the end I could live with it. Martin Spott was always kind enough to commit my work, and even reviewed it. But like Gary already said, we also do know that they have own real life, own projects and with all that only limited time Actually, that's not quite accurate, but, the procedure is to ask, *having demonstrated yourself to be a sane and reasonable person who's likely to stick around longer than four weeks*. I'm a bit more liberal in this regard, but essentially anyone who's contributed a moderate quality aircraft, or provided 10+ 'good' patches to existing aircraft, I'd be happy to grant them access. That are your rules. And what rules does the other FGFS-Project-maintainer has? And what do you understand under moderate quality? What do others understand under? I'm aware that the bar *appears* to be set higher than this, but personally I'm happy to liberalise it a bit - the problem is keeping the sense of etiquette that other contributors assume and rely upon. So a period of indoctrination is good, of submitting merge requests and getting some feedback, but it can become a habit, when it doesn't need too. Submitting merge requests wasn't bad, in fact that gave the chance to get the work reviewed and checked. But very often no one felt responsible for! And sometimes it needed more than 4 weeks until a merge requests was handled. And then it was already not up to date anymore 'we' (the infamous FlightGear we) should probably write a wiki page of aircraft-contributor-etiquette, so we have grounds to revoke people's access if they break the rules. Though just about the only rules I'm aware of : keep it GPL; don't modify other people's work without asking, or trying to ask; try to avoid copy-and-pasting when you can share files or scripts between aircraft ... and I only stuck the last one in because it's a pet hate of mine :) Excuse me, what do you mean with the last one? Aircraft A has one feature which developer of Aircraft B wants to use in his project as well. He copy and paste it but makes sure that it works on his aircraft as well- that wouldn't be allowed? I guess I misunderstand something here. And who makes sure and decides that those people really keeps to all those rules? Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] fgdata: Important note
Hello, IMHO that adds another not very logical layer of complication for little gain. There's a nice democratic aspect to every aircraft being in a single central repository, and reduced opportunities for those clique type groups that so naturally spring up and are divisive and very offputting to new contributers coming to the project. Sorry, I hate it to say, but we have that situation already. Up until now it's been very straightforward to get a new model included - if it's your own work and under a suitable licence you simply ask someone with commit rights if you know one, or offer it to the dev list and it goes in. There's no embarrasment over which hangar / group / clique to submit it to, and I think that's a very good thing. So far it is working. BUT: Those who have commit rights are already busy with their own stuff. For a new aircraft it is o.k. to ask them- but when I want to update my work? For each small update asking and stealing time of those people? But the last sentence is not true again, sorry. It should be like that, but it isn't any more. The idea of Yves aka HB-GRAL is quite nice and seems to me to reflect the actual situation. But I must admit- in the whole thing I'm quite uncertain how to proceed. I just know that the current FGData make more and more problems with its size! -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
Hello, there was little input on the fgdata split and few people speaking up when things were started. We do see a lot of responses now - many being in favor of the change, but also concerns about remaining issues. Indeed, setting up the new repo isn't as simple as it seemed initially, and there are issues which need to be resolved. We also need common acceptance of the new structure, tools and processes. Unfortunately, the call for split completed was communicated ahead of time - even before fgdata itself was switched. And we still do see a need for a proper testing phase before switching - including a chance for everyone to give input, raise concerns, etc. Thanks for that- it looked to me like the changes have been made to quick without seeing the consequences. Nethertheless, I'm in favor for a split. My Reasons: -Gitorious.org had problems with the size of our repo. This was one cause why Merge-requests didn't worked for a while. They fixed it, but as the number aircraft are increasing I wonder for how long. -There are countries and locations where download speed isn't really fast, but even very slow. And yes, Germany is indeed one of them -for each small update developers without commit rights it wasn't that comfortable to get them up. For those people I think it wasn't easy as well to find time to work on their own projects and review and commit new updates of aircraft. That was the reason why I set up my own repos. It was easier for to organize my work, still open and free for users even if they want to contribute, tar.gz was made automatically (no need of uploading to my Homepage), and still had the possibility to let commit it to FGdata. On the other side clone each of the 300+ aircraft isn't that comfortable as well. I would rather liked to see a FGAircraft or FGAicraftFixedWings,FGAicrafthelicopters,... Heiko -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MyCopter- or another use of Flightgear in Research and Development
Hello, Today I found something interesting. There is a project in Europe called MyCopter. They indeed aimed for a creating a personal air transport system (PATS) with Personal Aerial Vehicles (PAVs). So they are investigating what it needs to have such a system in the future. Several universities and labs are working on this: -Max-Planck-Institut für biologische Kybernetik -The University of Liverpool -École Polytechnique Fédérale de Lausanne -Eidgenössische Technische Hochschule Zürich -Karlsruher Institut für Technologie -Deutsches Zentrum für Luft- und Raumfahrt Today I found another interesting article in the local newspaper about the work of the Max-Planck-Institut für biologische Kybernetik here in Tübingen/Germany. To my surprise they showed a picture of one of their simulators- and it does shows Flightgear! (obviously KSFO 28R) Here to the article (in german): http://www.tagblatt.de/Home/nachrichten/tuebingen_artikel,-Wie-Pendler-zur-Arbeit-fliegen-koennten-_arid,150513.html Click on the image to see a bigger image or use this link (popup: http://www.tagblatt.de/pu_all/popup.php?bi=NjI3ODk1Nw==pageid=3 About the project: http://mycopter.eu/ About the Max-Planck-Simulators: http://www.kyb.tuebingen.mpg.de/research/equipment/virtual-reality-labs.html Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] specular reflections, where did they go?
Hiwhere did that go? nothing alike in gitthanks To get the fuselage reflections enable Specular reflections on objects in View - Rendering options.--- ?? Are you sure you are using the latest FGFS-version? Seems not To get the specular reflections just enable the material-shader in the rendering-view! Btw- we have a bug-tracker since a while... still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Question: FLCH-Mode or How to decouple Throttles from target-speed?
Hello Syd, I did a DESCEND/CLIMB mode for the b1900d autopilot , and a few others that i never did commit , but have to admit I'm not sure what you mean by decoupling the throttle ... is there a controller in the autopilot file that's taking control of the throttle at the same time ?My apologies if this sounds like a dumb question but i cant see your autopilot file ;) You couldn't see my autopilot file, as I did not had any yet. That's why I asked here to get the needed autopilot file! And with help from Torsten I have now the controller I needed. ;-) Many thanks to Torsten for the help and the explnanations! What I wanted to achieve is a FLC-Mode without Autothrottle. How does it works? I translate what Torsten wrote, he had a very good explanation for: It is a simple energy management. The total energy of the aircraft is the sum of kinetic energy (speed) and potential energy (altitude). If we keep the speed constant via Pitch-Hold and add energy by increasing thrust more than needed, then this energy will be transformed into altitude, means the aircraft will climb. So I wrote a controller which has the indicated-speed-kt as input; as reference I used /autopilot/internal/target-speed-kt. I used that way, as the autopilot/settings/target-speed is always influenced by throttle setting. And finally as output target-pitch-deg (can be elevator as well, etc...). About your questions: Yes, throttles are coupled per default with autopilot/settings/target-speed. That's coded in Nasal/control.nas. I wasn't aware of it, but I found a way to deal with as written above. Descend and Climb are some own modes and not really comparable with the FLC-Mode used in the real Citation X as the Citation X does not have any autothrust. From Smartcockpit.com about the FLC-Mode on the Citation X: To climb the airplane from present altitude to a preselected altitude, follow this procedure: (1) use the altitude preset knob on the remote instrument controller to set the alert altitude higher than the current altitude, (2) press the FLC button on the GC-810 flight guidance controller; the airspeed current when FLC is pressed will be the target airspeed, (3) advance the throttles to establish climb power. The system will climb the airplane to the preselected altitude, and will maintain the speed reference. The amount of throttle applied will vary the rate of climb achieved. The capture of any armed pitch mode will override the selected FLC mode. And here is my controller which does this, tested on the 737-300. pi-simple-controller nameSpeed hold (vary pitch trim) Stage #1/name debugfalse/debug enable prop/autopilot/locks/flc/prop valuetrue/value /enable input prop/instrumentation/airspeed-indicator/indicated-speed-kt/prop /input reference prop/autopilot/internal/target-speed-kt/prop /reference output prop/autopilot/settings/target-pitch-deg/prop /output config Kp-1.0/Kp !-- proportional gain -- Ki-0.1/Ki u_min-15.0/u_min!-- minimum output clamp -- u_max15.0/u_max !-- maximum output clamp -- /config /pi-simple-controller pi-simple-controller nameSpeed hold (vary pitch trim) Stage #2/name debugfalse/debug enable prop/autopilot/locks/flc/prop valuetrue/value /enable input prop/orientation/pitch-deg/prop /input reference prop/autopilot/settings/target-pitch-deg/prop /reference output prop/controls/flight/elevator-trim/prop /output config Kp-0.05/Kp !-- proportional gain -- Ki0.0/Ki u_min-1.0/u_min !-- minimum output clamp -- u_max1.0/u_max !-- maximum output clamp -- /config /pi-simple-controller Hope it helps Kind regards Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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] Question: FLCH-Mode or How to decouple Throttles from target-speed?
Hello Syd, Don't worry, don't get yourself into rush. I'm working on the Dornier Do328 TP/JET, which uses a version of the Autopilot System of the Citation X. At least the main functions are the same, that's why I noticed the issues. And digging into teaches me some new things. Thanks for your work Cheers Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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] Question: FLCH-Mode or How to decouple Throttles from target-speed?
Hello, I'm looking for a way to create a correct FLCH-Mode for autopilots like it is used on the real Citation X or Dornier 328. Usually it works this way: Engaging this mode the AP will maintain the pitch to hold the current or selected airspeed. Maintaining throttle by the pilot will maintain the climbrate. We have already in FGFS a Speed-Hold by Pitch-trim, but whenever increasing throttle you also increases target-speed. Is there are way to decouple it? Thanks Kind Regards Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- 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] Please insert disk into drive F:
Finally, I found 3 affected global models in fgdata. Martin, can you fix these please (needs to go to the scenery database): Models/Transport/ICE3middlecar.ac Models/Transport/ICE3middlecar2.ac these had been directly committed to CVS by one of those overly clever committers who are known to be ignorant, by tradition, of every general consistency rule. Life could be so easy, if And before someone shouts at me: I was the author of the 3d-models- but the mentioned paths had been changed after I sent them to Vivian Meazza for including them into CVS. Not my fault, especially as I never had any right to directly commit things to CVS/GIT. Thanks to Thorsten B. for finding the cause of that problem and fixing it. Heiko -- Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
http://www.gbabrasil.net/images/news.html-- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 12
Hello, Thanks for the poke. I completely forgot to write this up. I'll try to do this today, though it needs a proper name. This is done. I've gone ahead and replaced the article completely with the rating system described in December. Now I'm off to rate all the aircraft I maintain! -Stuart Many thanks Stuart! Finally we have a good, easy and more or less objective rating system! Many thanks to you and all others, who have been involved in the discussion and developing ideas about. There is a small proposal from me for the System-section about autopilot - some aircraft doesn't have a autopilot in real life. So maybe we should mention it in any way like ... if real one has one And at least one wish: It would be great if the Aircraft Download page will have something like a search function or sorting function. But no idea if it is possible. Cheers Heiko -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
Ron beat me to it, but I was going to suggest the same thing ... create an alouette2-easy-set.xml ... or aloutte2-beginner-set.xml or something along those lines. Then we can have both FDM's available and the end user can choose which one they want. A git commit war would be no fun. I'm not sure if my sentences could be misunderstood, but exactly this was what I meant with another version beside. I don't want a commit war myself so I see this as well as a good solution. And if helijah will provide something, I would be more as happy. Heiko -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 9
The fact is that Heiko do not like the way I work. He does not understand organization and compliance. He thinks that Maik JUSTUS knows everything about everything. For the rotation of the rotor, I acknowledge that I did not notice. This will be fixed soon. For the rest, Yasim (like others) is a simplified system (this is mandatory). Maik is physicist, author of the yasim-helicopter-fdm-code and interested in simulation of helicopters since his youth. In the past he had worked together with real pilots in simulation of helicopters. And he wrote nearly 90% of all helicopter-fdm's in FGFS. Logically if there is any question about helicopter-fdm he is the first one to ask. In that sense giving the actual values will never make a correct FDM. I saw several Alouette 2 takeoff, I can say that I have never seen Alouette vibrate and crash as did the FDM Maik. it's an helicopters stable. I have no problem, Groucho and others as well. The AlouetteII was stable for me. Even smaller inputs doesn't affect the helicopter in motion changes, and this is how the pilots describes the real thing as well. Don't forget that the AlouetteII was the work horse for the german army and german police, so a lot of pilots in germany learnt on this helicopter, so it is quite easy to get informations. Problem behind the thing you noticed is, that the very most joysticks are rather poor compared to the real control system. On real helicopters the stick has a travel way of 30cm- quite a lot. Joysticks has much less, and our default mouse config even much more less. I have changed my mouse setting, so I have no the same travel way like the real sticks. Still a poor way, but much better then the default. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 10
All this is absolutely false. I never requested a change in the FDM Alouette 2 ! I never wrote this. I said that you wasn't happy- but not that you requested. If I could not fly, and although it does not bother me. JM-26 and many, many others were sad not to do so. But I did never ask a new FDM. Again I never said and wrote this. I am tired by the disparaging remarks, gratuitous and unnecessary of this gentleman who do not want to understand and especially does not want to learn. Me and a lot of other people tired of your misunterpretations. Again, what another user (Groucho aka Oliver Fels) you already told you: Emmanuel, je te prie que tu arrètes d´essayer interpreter l´intention des gens parce que évidemment ca ne marche pas. L´observation ce que je peux faire c´est que l´intention bonne des gens (mettre en place de l´aide) sera traduit immédiatement aux contraire et l´intention originale sera perdu. C´est propablement le résultat de la barrière qui se produit par la traduction. Translation: Emmanuel, please stop to try interprete the intentions of people here. I noticed that good intentions of the people (to help) has been translated into the opposite and the true intention behind is lost. All conflicts are probably result of this language barrier. And, myself, can only agree to this. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 9
I think we'd have to get a little bit more precise here. _I_ understand FlightGear's goal of development for aircraft/heli FDM's to get as close as possible to the flight characteristics of the real aircraft. Think of someone connecting a set of real helicopter controls to FlightGear and putting a skilled pilot into the seat. Is this pilot going to experience flight performance similar to what he'd experience on the real aircraft ? At least some people apparently had been quite happy with the previous state (Maik's) of the Alouette II FDM, thus I assume there might be a point. Not sure if this really belongs into a discussion about the fidelity of a helicopter FDM Cordialement, Martin. I agree in everything Martin said. To make it clear: My issue with the fdm wasn't the fact that an easy-to-fly-but-false one has been developed. It is o.k. and I can understand that a lot of people wishes something like that. My issue was that it wasn't added as another selectable option as proposed by Curt, Ron and me. Instead the fdm has been simply replaced, even without asking their original author, which is in my eyes not very respectful. As it seems that it indeed can be solved that easily as proposed, as helijah wants to change it so we can have both fdms beside, everyone inluding me will be happy now, and the discussion can be ended. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 10
It appears that just come and complain on the devel list (which is intended for developers code FG) is not interpreted as anything other than a personal attack. If you can't understand I can not do anything about it. Even Martin did you notice that your mail has nothing to do on the Devel List. My problem with you is, that everything, really every word I say to you is misunderpreted by you as affront, insult and personal attack. As I said as answer on Martins post your refer here: In general it is my prefered way as well. With any author just but not this one for some reasons. And the reason is what I wrote above. You have no respect for the work of others and I do not have to justify my actions in front of you. With a little intelligence, you might have what you want. Unfortunately it seems that you lack of thought and you were talking too quickly and especially without knowing. You disrespected the work by others (here Maik), not me. And put your bad times and you said, ultimately, defamatory on behalf of my bad English is not a solution. This too is false. You have trouble communicating and, again, I can not help you. Trouble with communication only with you- it needs two for a communication. I will create the smart solution of Ron (but you could start with that) and create multiple FDM. You told me once that you don't accept any contributions from me anymore. And neither Maik nor me was able to find the author at the beginning. Needed some search. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 9
Whether you're able to tweak your system to compensate for worries FDM is good for you. But this does not solve the problem of the majority of users. And I don't work for 1 or 2 people, but for 99% of users. You're not the navel of the world and your skills are not those of everyone. Your are not quite right here. You contribute with your work to a Project with the intention to have it realistic and right as possible. This is one main goal of this project. And a very lot of users who decides to choose FGFS know this. In the future if one of the planes / Helicopters etc. .. of my hangar you dislike, do not drool on the devel list or elsewhere. Or made it with intelligence. But I doubt it. I never insulted and attacked you like you did here on the devel-list and in the forum and per email. If we could act like a grownups as we are, the issue with the fdm had been solved already without any noise. @devel-list members: sorry for the noise I brought in here, but due to the named reasons I didn't know any better way to deal with. I'll stop here right now. -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 11
Emmanuel, and all here involved or not, with your answer to Martin here on the devel-list you began to discredit me. You didn't talk to me - but about me. Isn't that exactly the behaviour you don't like? So why did you do it? The fact that you tried to discredite me let me give no other choice defending me than showing how you are really behaving and how you roll. Don't you notice that you contradict yourself all the time? Whether it is about the realism of YASim, the helicopter fdm, your knowledge in speaking english or your whole behaviour? I didn't have attacked you before, but it seems that you understand any criticism as personal attack. It could been seen here in the past, in the forum and now. And I'm not the only one. That's something it can't be denied. The fact that you try to interprete things which aren't there in a automatic, lousy and mostly wrong Google-Translation doesn't make it better. It makes it more worse. You are demanded things here from me which you even don't follow yourself. As an example from your last Email to me: You're not Maik and you do not have the authority to speak for him. So avoid doing so. So why YOU are doing it? Did you had the permission by him to forbid in which names I speak? No, you didn't. Actually I had the permission by Maik to speak in his name here. But YOU don't have the authority to tell me in which names I speak! The original issue was that the fdm of an helicopter had been replaced fundamental with a fdm unrealistic and wrong, without asking the author of it. As I understand the rules and principles of FlightGear Project this isn't the correct way, so I raised it up. My goal wasn't to discredite E.B. but to make clear that it isn't in the spirit of this project and I wanted to know how to get a good solution for everyone. I made a proposal, but wasn't sure if there is no better way. Due to former experiences I had with E.B. I decided to use a neutral place instead contacting E.B himself, and as the Developers-list is the place for developement for code, scenery, aircraft and other related things I thought it was the best place. Is the goal of FlightGear Project still the same as 6 years before when I stumbled in- realistic as possible and with that as close as possible to the flight characteristics of the real aircraft; sophisticated, cross-platform FlightSimulator ? Heiko -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by JM-26
Hello, I just noticed that the Alouette II fdm has been replaced by a new fdm, which was originally made by Maik Justus. That's sad. As I know Maik Justus always uses a lot of real datas for the fdm's, based on pilot reports and real manuals as long it can be get free in the web. I hate to say it, but the the new fdm is completly wrong and doesn't apply to the real one in any way. It begins with the rotor turn direction- it is now counterclockwise which is wrong as the AlouetteII is a french helicopter with a french rotor system.(clockwise!) Rotor RPM is wrong, it has now even the equal value like the new model of the R44 uses as well. (the R44-model -3d and fdm is another story... :-( ) Other values are completly wrongs as well, like the rellenflaphinge and a lot of others which can easily extracted from drawings. And of course the real Alouette II had never any SAS or similar control systems. The YASim helicopter-fdm is indeed really accurate beside the known issues vortex ring state, sliding and lacking detailed engine support. All other things are accurate, and compared to X-Plane even more exact and easier to configurate. With the right datas you can be sure that the helicopter-fdm is matching quite close to the real one in behaviour and reactions. I always thought FlightGear stands for a realistic simulator, trying to make things right and accurate as possible. It seems to me that isn't longer true when I look at this contributions. Another thing I noticed accidently yesterday: NBC seems to try more and more removing videos taken from their Airwolf-TV-series on youtube.com There are so many I doubt that they are really able to remove them all. But all sounds and the music themes are of course copyrighted by them. The Bell-222X in FlightGear makes use of the typical Airwolf-whining (hurlement.wav) which seems taken from the TV-series. Apart from the fact that the real Bell222 doesn't sounds like that of course, it doesn't really apply to GNU GPL. It may be better to remove this soundfile. Kind Regards Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
In general I'd recommend first to discuss the item with the author of the change. In general it is my prefered way as well. With any author just but not this one for some reasons. If the drawbacks introduced by the new FDM are really that obvious and serious as you've stated here, I'd say you/we should take a revert of the latter change into account. At least the author of the first and in my eyes much more realistic fdm has to decide if he accepts the new made changes or not. Cheers, Martin - being a veritable admirer of the old Alouette II (the real one, I mean). Thanks Heiko -beeing a veritable admirer of the real one as well - I miss the sound- -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
Hello all, Does anyone know, if JM-26, the author of the new fdm, is reading the devel list or has an email address for me to contact him directly? Regards Maik I found the author on another french FlightGear Forum. Here you go: http://equipe-flightgear.forumactif.com/t504-l-alouette-2 Summary of the reasons why the fdm has changed for those not able to understand french: The author JM-26 and helijah wasn't happy with the fdm, as it wasn't able that easy to fly as they want to have. JM-26 proposed a much more easier-to-fly-fdm. Helijah is aware of the fact that Maik usually uses real datas, and that it is quite convincing. But he is just sad beeing not able to fly his own model. Just simply because helijah wants to fly helicopters in FG but he isn't able to, he replaced the fdm with the changed fdm by JM-26. It may be easily to fly- but it is horrorible wrong. The same applies to the R44 in the repository. I don't want to judge about, but I must admit that I'm dissapointed. I must admit I had no problems to fly the AlouetteII before, and I know a lot of others users which didn't have problems as well with this. I wonder why if there is a need for an easy-to-fly-helicopter, why not create a mod for those who need it? But I don't think it is in the spirit of FGFS to replace a plausible and correct fdm with a wrong one and destroy the work of another author without asking him. I would like to have the old fdm back, maybe it is possible to have another version with the easy-to-fly-fdm beside the original one. Any opinions about, something I missed? Heiko -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport Textures
Hi, Yes they do look ugly, because the new textures expose problems that are hidden by the old ones. Here are some more: ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/KSFO-Textures.jpg ftp://abbeytheatre2.org.uk:2121/flightgear/Terrain/KSFO-Textures-1.jpg ftp://abbeytheatre2.org.uk:2121//Terraflightgearin/KSFO-Textures-2.jpg These are not ordering problems - these are errors. And they are not in any old airport which I happened to find - they are at KSFO. Who is going to find and correct all these errors? I think these errors, while minor, give our primary airport an unacceptable appearance, and make the sim look unprofessional. We have enough errors and omissions in our airports without actually introducing more From the pictures it looks indeed not really good. Even this is caused just by ordering problems- until we don't have fixed every airport we have (and I guess we have a very lot of them- even 10% of our 20.000 would be too much) and the new scenery is generated then, we should make FGFS not look more badly as it already does. Heiko -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: fgdata merge request 76:Improvedairport Textures
Anybody got a screenshot with stopways? -- Yep: GIT 04/29/2011 win32 Hudson Build www.hoerbird.net/fgfs-screen-251.jpg -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim turbulence models: revealing an almost hidden gem
Yes, right. I used the turbulence model already before, but now it is used automatically. It was just this bridge missing. Great! Thank you! I really like the turbulence model of JSBSim- feels much more realistic than the one from YASim. All the credit for the model goes to the excellent JSBSim devs. I just built the bridge that linked it into FG. Torsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Night textures: two files vs. textranslate
Hello, Thomas Albrecht wrote: Dear all, I also tried the textranslate method, but when I put the day/night textures, say van.png and van_LIT.png each 256 x 256), into one file (512 x 256) and make up an .xml as described in the wiki, both day and night textures look distorted in FG. I assume the mapping specified in the .ac is no longer correct when I change the size of the texture file? I have no experience with UV mapping though. Any ideas? Tom You would have to remap the respective faces to use just half of the texture. Otherways they use the whole texture and what you see as distorted is in fact both day and night displayed at once. Using separate files induces a slight delay as the night texture is loaded, and it's mipmaps get generated but might help with memory usage, as you're using only half the videoram than with the big two-in-one. HTH Emilian. @Tom: The article in the wiki is outdated. Indeed nighttextures with textranslate are working in GIT since a whole while. If it works without textranslating, like described in the wiki-article, I can't tell. Never tried yet. With textranslate you have to change the UVmap. Means, when you have put night and day textures beside (x-direction) into one texture file, the UVMap has to be reduced in size (in x-direction) exactly the half. You may want to take a look into FGdata/Models/Airport to see how it works. @Emilian: According to Tim Moore, FGFS's graphic specialists it is recommended to have large texture files, instead many smalls. See also here: http://wiki.flightgear.org/Howto:_Improve_Framerates Cheers Heiko -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Night textures: two files vs. textranslate
Hello, Hmm, that depends. If those textures should be displayed all the time (like a livery), then yeah, I agree, one big texture is better than many smaller ones, also depending on your texturing needs. On the other hand, if you're not displaying half the texture most of the time, I think that's wasted VRAM, that could be freed for another texture of the same size. This might seem just a bit of wasted memory, but when you have 10-15 different buildings with such textures things start to add up, and you'd be using as much memory as for 20-30 different buildings, and where you have a detailed village you could have two or more. Just my o.o2RON on the matter :P Emilian Yes, interesting thought, I understand. But I always thought that the process of loading and unloading textures settles down the perfomance and that'y why it is better to have them only loaded once and keep them in VRAM. But maybe this only true when you not use any .dds-textures. I guess with .dds-textures it would make sense to have them then seperated. Cheers Heiko -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud interface from Nasal
One function I had on my TODO list was something to return the cloud position in lat/lon. However, it's a bit tricky due to the current limitations in the command interface. Do you see any need for it? Weather Radar? -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
Hello, So I tested the bo105 now with the HudsonBuild 262 win32-installer (before YASim-patch) vs. the latest HudsonBuild 272 win32-installer. (after YASim-patch) I used the Bo105, KMTN, rwy15 METAR: 012345Z 15000kt 12SM 20/08 Q1013 NOSIG I set Vy= 65, TOW 4531 lbs, Torque at 80% (end of green arch), Heading 150: Before patch: average climbrate 900-1000 fpm After patch: average climbrate 900-1000 fpm Now with TOW 5512 lbs (=MTOW): Before patch: average climbrate 200-300 fpm After patch: average climbrate 200-300 fpm With the patch there is no change to see, and I wonder where my mistake was. So thanks for the patch, currently it seems according to the bugtracker that only the ASK13 needs a change Heiko -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future repository for non-GPL aircraft
Hi, I could imagine more something like a portal, (like avsim.com, x-plane.org) where you have all Downloads available, sorted in licencs, types, ratings. This would allow to search and find easily all aircraft, no need to search through the whole web. This would also allow to have multiple versions of an aircraft, so the user can decide themselves which one they prefer. This is what I understand under free as well. Heiko -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
Hi, Hello Heiko, does your local FDM still uses default approach fuel etc? But even if not, there should be no difference in the flight behavior. The only effect of the approach fuel level is (for a rotorcraft) within the gear solver. Heiko, and anyone else: if you think there is a major change, then directly compare the FDM behaviour with and without the patch - and let us know if there was trouble. I was already aware of that, and used the approach settings to improve the behaviour of the gear on the EC130 B4. I wanted compare before and aft patch-version anyway to see if I'm wrong here and mixed something up, but unfortunately real life came with night shift working and having a damaged car by an arson attack the last night before one. A lot of things to manage, so I'll have to wait for the easter-weekend for some free time. I hope I'm not doing too much noise here, especially when I'm wrong. Kind Regards Heiko -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] terragear-cs segfault
People who have never seen unix before and are diving in expecting to be able to click next a couple times and have something useful pop out the other end 3 seconds later probably will be a little terrorized by what they find. But others who enjoy seeing dozens of machines cranking away in parallel on a task might have have fun with this. Or help Gijs finishing TerraGearGUI 2.0! I have tested it on win32 and wow: I can build now my own sceneries much more easier! -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
