Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 9
Salut Emmanuel, BARANGER Emmanuel wrote: 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). In that sense giving the actual values ??will never make a correct FDM. 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. [...] The remark makes sense but also ridiculous. Companies do not like people who make money with their work. YouTube is for profit. It is normal to prevent them from doing that. FG does not have this feature. It is free and open source. Just consider the authorization of Moulinsart SA for the dissemination of Carreidas 160 for example, to understand that it is in their interest that FG use and disseminate their work (... not all of course :) ) Not sure if this really belongs into a discussion about the fidelity of a helicopter FDM Cordialement, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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
-- Message: 16 Date: Wed, 18 May 2011 21:59:20 -0500 From: Curtis Olson curtol...@gmail.com Subject: Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Message-ID: BANLkTi=urQ7_CDm-_-=jk25nfatnx3l...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 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 f Hey Curt As always the intelligence is best that the critical pure. Here is an idea that already is more pleasant to hear. And I'll work to get it quickly Thanks Curt -- BARANGER Emmanuel http://helijah.free.fr -- 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
-- Message: 14 Date: Thu, 19 May 2011 01:39:50 +0100 (BST) From: Heiko Schulz aeitsch...@yahoo.de Subject: Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Message-ID: 91568.52223...@web29513.mail.ird.yahoo.com Content-Type: text/plain; charset=utf-8 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. All this is absolutely false. I never requested a change in the FDM Alouette 2 ! 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. 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. This is not him who receive returns dissatisfied dozens (even hundreds) of people who can not fly with Alouette2. So when JM-26 FDM proposed a simpler and more stable especially I did not refuse, thinking that it would please the majority. Of course I made the mistake of forgetting Heiko: (Argh Damned -- BARANGER Emmanuel http://helijah.free.fr -- 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
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
[Flightgear-devel] Need help on including osgEarth in FlightGear
Repost. Forum topic theme is http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 Hi. I am doing Vostok-1 project for FlightGear and have a lot of problems due to current terrain engine what can not supply high altitude/speed flights. On normal 25km visibility it not shows anything but blue fog http://wiki.flightgear.org/images/4/42/Vostok-1-News.png because normal altitude for orbital flight is 100km, but it still loads something and produces great lags. If visibility is high enough, say 500km, it makes more or less cool pictures http://i.imgur.com/2TZKX.jpg but does it one time in minutes. I suppose what including some other terrain engine, say osgEarth http://osgearth.org/ and switching on it from some speed/altitude could solve all that problems. osgEarth is GPL and uses same OSG base as FlightGear. It seems to what include it will be comparatively easy. But me myself do not competent enough to implement it alone. I could do something in that case still but need a lot of help. It would be better if someone else would do it because I have a lot of problems to solve in Vostok and have a plans for next projects already. Can You help me? With best regards, Slavutinsky Victor -- 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] Need help on including osgEarth in FlightGear
In addition to previous message I can tell what existed X-15 and SR-71 need that implementation, as some other already existed high speed/altitude crafts too. With best regards, Slavutinsky Victor -- 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] heads up: FlightGear release plan
Hi everybody, during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm and myself developed a strategy and a concept about how to kick out new releases of FlightGear on a regular schedule. Please find our first draft here: http://wiki.flightgear.org/Release_Plan For the impatient reader, this is the abstract: We plan to have two releases per year, one in February, one in August. The first scheduled release following this concept will be 2.4.0 in August this year, 2.6.0 is scheduled for February 2012. If no major objections arise, we will set the version number on the current development stream to 2.3.0 and will call out a feature freeze on June 17th. Any comment and certainly any help for actually preparing the release is welcome. Thanks, Torsten -- 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] Request of help to get started
Marcel Fernandez wrote: If you want to do that, count me in. All you have to do is explain me a bit what I have to do. Hah, I'm not planning to do that myself, instead I'm trying to catch a volunteer who'd be willing to continue the OpenRadar where Ralf left the scene :-) The foundation of OpenRadar is a pretty clever concept and therefore I think it deserves to be continued and, as far as I can tell, it's currently the only truly OpenSource application that works with FlightGear and also resembles the look-and-feel of real life Radar screens. I have been looking at the source code, but I don?t know where the branches to merge are. Branches (heads) are listed at the bottom of this page: http://mapserver.flightgear.org/git/gitweb.pl?p=openradar;a=summary git checkout will provide the branches in question, see: http://www.kernel.org/pub/software/scm/git/docs/git-checkout.html Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Need help on including osgEarth in FlightGear
Hi Victor, On Thu, May 19, 2011 at 1:03 PM, Slavutinsky Victor wrote: Repost. Forum topic theme is http://www.flightgear.org/forums/viewtopic.php?f=6t=12005 Hi. I am doing Vostok-1 project for FlightGear and have a lot of problems due to current terrain engine what can not supply high altitude/speed flights. snip I suppose what including some other terrain engine, say osgEarth http://osgearth.org/ and switching on it from some speed/altitude could solve all that problems. osgEarth is GPL and uses same OSG base as FlightGear. It seems to what include it will be comparatively easy. But me myself do not competent enough to implement it alone. I could do something in that case still but need a lot of help. It would be better if someone else would do it because I have a lot of problems to solve in Vostok and have a plans for next projects already. Unfortunately, programmers with sufficient OSG and FG knowledge are very thin on the ground. Tim Moore is the guru, and best placed to say how difficult this would be, though I've spent some time working on the graphics as well. From my experience adding a new terrain engine such as osgEarth would be a very large job indeed. As you have shown, we have plenty of room for improvement in our existing terrain and graphics engine. Personally, I think my efforts are better spent improving our existing graphics, which will benefit both low altitude and sub-orbital flights, rather than integrating a new terrain engine. Going off-topic: one thing I have been thinking off is generating lower resolution BTG terrain files using terragear and then loading different resolution files depending on distance. So tiles far away would use a lower resolution height map and wouldn't include line and point features. I've still to investigate to see if this would make any real difference both in terms of I/O and graphical performance. Anyone got any ideas? -Stuart -- 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] Need help on including osgEarth in FlightGear
Hi Victor, Hi Stuart. Unfortunately, programmers with sufficient OSG and FG knowledge are very thin on the ground. Tim Moore is the guru, and best placed to say how difficult this would be, though I've spent some time working on the graphics as well. Cool... From my experience adding a new terrain engine such as osgEarth would be a very large job indeed. Ok... As you have shown, we have plenty of room for improvement in our existing terrain and graphics engine. Personally, I think my efforts are better spent improving our existing graphics, which will benefit both low altitude and sub-orbital flights, rather than integrating a new terrain engine. I had propose other engine solution only because do not know is it possible to improve current. Going off-topic: one thing I have been thinking off is generating lower resolution BTG terrain files using terragear and then loading different resolution files depending on distance. So tiles far away would use a lower resolution height map and wouldn't include line and point features. I've still to investigate to see if this would make any real difference both in terms of I/O and graphical performance. Anyone got any ideas? I have some idea what I had wrote about somewhere. Do not know if it new or can it help. Look. Oh high speed/altitude there is no reason to make tiles polygonal at all. It's so distant/fast to feel much difference. Better to do it way osgEarth engine does. It loads one picture for tile and other picture for altitude by normalmap, as urban shader and normalmap shader do. With shader off it could be simply even surface with Earth texture, with shader on it could be relief. In any case it could be much faster then current multipoligonal tiles. -Victor -- 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] Modified download_and_compile.sh script
Hi, I merged the script, applying fixes from Brandano (Who I really thank) and moved version number to 1.4 you can download new script version here as usual: http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh noob question: how to make a git request ? Cheers Francesco -- 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] heads up: FlightGear release plan
Torsten wrote during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm and myself developed a strategy and a concept about how to kick out new releases of FlightGear on a regular schedule. Please find our first draft here: http://wiki.flightgear.org/Release_Plan For the impatient reader, this is the abstract: We plan to have two releases per year, one in February, one in August. The first scheduled release following this concept will be 2.4.0 in August this year, 2.6.0 is scheduled for February 2012. If no major objections arise, we will set the version number on the current development stream to 2.3.0 and will call out a feature freeze on June 17th. Any comment and certainly any help for actually preparing the release is welcome. It's as good a plan as any other. However we missed the last planned release (2.2.0). I'm unaware of the reason(s), but I assume that release is dead. So I think the question we have to ask is not when but how. Until that is solved, the when is pretty meaningless. Nevertheless, having a plan at all is a good start. Vivian -- 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] Need help on including osgEarth in FlightGear
On Thu, May 19, 2011 at 10:56 AM, Stuart Buchanan stuar...@gmail.comwrote: Going off-topic: one thing I have been thinking off is generating lower resolution BTG terrain files using terragear and then loading different resolution files depending on distance. So tiles far away would use a lower resolution height map and wouldn't include line and point features. I've still to investigate to see if this would make any real difference both in terms of I/O and graphical performance. Anyone got any ideas? Ideas on this subject have been batted around since the earliest start of the FlightGear project. I say that only to point out that the existing system didn't get created blindly or without serious thought. There are flaws and short comings though so it certainly is worth revisiting the subject periodically. The issue of level of detail: generally it's a good strategy to consider, but the hardest part when doing this with terrain tiles is dealing with how they match up against their neighbors of differing levels of detail. Any mismatch of points and lines along the boundary will show up as visible cracks which are really ugly. We've discussed several strategies for ensuring the tiles match up, or hiding the seams ... none are ideal or without cost. At the time the current system was developed we strategized that avoiding LOD might be a bigger net win that trying to cruft up some convoluted strategy to hide or avoid cracks. It also made life simpler. We also strategically decided to invest our resources into a TIN based terrain system rather than a ROAM based. So we skin our terrain surface with an irregular mesh of triangles that uses smaller triangles in higher detailed areas (like mountains) and uses much larger triangles in areas that are generally flat. We have a somewhat sophisticated algorithm to adapt an optimal TIN to a regular gridded set of terrain data within some set of constraints (achieving some minimal error tolerance, and/or limiting the total number of vertices per tile.) After we had our TIN based system implemented, ROAM based systems (such as Victor) suggests became very popular. Then a few years later as graphics cards became *much* more powerful and capable of storing arrays of geometry data on board, TIN based system started coming back into popularity. It's my understanding that much of the optimization strategies for ROAM algorithms need to happen on the CPU and are hard to push out to the video card to even take advantage of the newer video card features. So our clothes are once again in style! I'm not hear to suggest one approach is necessarily better than another, just to say that a lot of thought and work has gone into the current system, even though it isn't perfect. Here are a couple other thoughts to consider ... GoogleEarth/osgEarth type systems look incredible from altitudes of a few thousand feet on up. But if you ever put your view point very close to the ground and try to look at roads or airports, you'll see that all the great imagery washes out and all that depth and shadow goes away and you just see an ugly mishmash of unintelligible pixels. We need to look good in some of these situations ... flying a 3 degree glide slope means we are looking at the airport surface nearly edge on. This is a worst case scenario for polygon texturing schemes. We need to be able to populate the world with dynamic objects (other aircraft) and land marks (buildings, bridges, etc.) If we use a LOD scheme, the local terrain height for any given point in the distance will change ... and object could be partially buried when viewed from a distance, then as we fly closer and get a new LOD level it could suddenly be floating, and then when we finally get close it could be at ground level. How do we deal with that? I'm not saying there aren't ways it could be handled, but it needs to be carefully considered. Also, we need to be able to query the terrain elevation at each wheel and contact point of our own vehicle as well as query the terrain elevation of any arbitrary point that is in view. Many of our subsystems depend on the terrain system providing this feature and we have a highly optimized system to do this right now. Any new scheme will need to be able to do fast height lookups of any arbitrary point ... and how will our subsystems behave if the altitude is constantly changing as the LOD changes ... in a ROAM scheme this can be nearly continuous. We have done quite a bit of work to model airport surfaces that follow the lay of the land. Our airports are not perfectly flat (just like in the real world). The elevations at the ends of each runway are usually at least a little bit different -- again trying to match the real world. Again ... not perfect, but a lot of work has gone into making some pretty clever and at least at the time, novel features that no other sim dared touch. And airports go beyond just their surfaces ... there is also lighting (a
Re: [Flightgear-devel] heads up: FlightGear release plan
On Thu, 19 May 2011 17:47:43 +0100, Vivian wrote in message 6F98880E3CB048A183E86552C9E0CA5E@MAIN: Torsten wrote during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm and myself developed a strategy and a concept about how to kick out new releases of FlightGear on a regular schedule. Please find our first draft here: http://wiki.flightgear.org/Release_Plan For the impatient reader, this is the abstract: We plan to have two releases per year, one in February, one in August. The first scheduled release following this concept will be 2.4.0 in August this year, 2.6.0 is scheduled for February 2012. If no major objections arise, we will set the version number on the current development stream to 2.3.0 and will call out a feature freeze on June 17th. Any comment and certainly any help for actually preparing the release is welcome. It's as good a plan as any other. However we missed the last planned release (2.2.0). I'm unaware of the reason(s), but I assume that release is dead. So I think the question we have to ask is not when but how. Until that is solved, the when is pretty meaningless. Nevertheless, having a plan at all is a good start. Vivian ..my opinion is the release guru should play around until he finds a bunch of git versions he likes and then release that combination as 2.2.0, might even become the preferred way. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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] Need help on including osgEarth in FlightGear
In addition, I have two questions for You, one is nice and other is not so. Firstly not so nice question. When? I mean, surfing on the rocket it's not so easy on itself and only fanatics will try it when there is no Earth surface visible but lags and fallouts instead of it. Even me, who put more than half of year everyday work in it, do not like to fly it much now. So future improvement of Vostok is unreasonable due to absence of people who would be interested in it until terrain engine improvements. I do want to know when it will be improved to plan my work. Secondly, nice question. Can I help to do it faster somehow? I really interested in continue Vostok and other such crafts development in FG. I could do something for terrain engine improvement if someone would teach me how to do so. Victor -- 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] heads up: FlightGear release plan
It's as good a plan as any other. There was another release plan? Wasn't aware of it ;-) However we missed the last planned release (2.2.0). I'm unaware of the reason(s), but I assume that release is dead. Yes, we simply declare it dead. To much has changed since the day we branched. So I think the question we have to ask is not when but how. Until that is solved, the when is pretty meaningless. You name it! That's why we spend an entire evening (with good pizza and good beer!) discussing the how which, in the end, automatically lead to the when. Torsten -- 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] Need help on including osgEarth in FlightGear
GoogleEarth/osgEarth type systems look incredible from altitudes of a few thousand feet on up. But if you ever put your view point very close to the ground and try to look at roads or airports, you'll see that all the great imagery washes out and all that depth and shadow goes away and you just see an ugly mishmash of unintelligible pixels. We need to look good in some of these situations ... flying a 3 degree glide slope means we are looking at the airport surface nearly edge on. This is a worst case scenario for polygon texturing schemes. Well, I do not talk about dropping off current engine totally. It's ok for what it was created, for 30km/3Mach altitudes/speeds flight. There is no reason to dropping it in those conditions since most of users fly in it and most of users are satisfied. But it, as You of course know, completely useless for 25km altitudes. To make it become useful in that conditions it's, truly, very complicated story until we do not have completely new math as Outerra and similar engines of that type have to recalculate tiles in runtime somehow. I had talked about easy solution. To 25km everything works as now. From 25km there is flat surface what looks relief by shader. You can not see other craft what flying near surface on great distance from that altitude anyway. And no 5deg approaches on that altitude. Actually it's hard to see not runways but whole cities, so You may do not care about ground contacts. You will not touch Earth until You come lower there original engine will turned on already. Actually I had talked about 100km and higher altitudes. It could look, as I had shown, that way http://i.imgur.com/2TZKX.jpg As You may see, if there was some shader instead of multipoligonal tiles You could not see the difference. Of course that switch is somehow wrong solution since it absented in real life. But it could start work in visible time instead of other solutions. I understand what there is not so many people who interested in flying in something instead of Boing, F14, Bo, Cessna and so on. But I personally could do something for other guys who interested in X-15, SR-71, Mercury-Atlas and so on, because me personally interested in it. I suppose it's possible to automatically make that flat tiles with altitude in alpha channel out of current terrain in same resolution for every tile. Then there could not be some problems with matches. Regards, Victor. -- 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] OT: android/ipad development
Le 18 mai 2011 à 20:36, Curtis Olson a écrit : This is a bit off topic, but I was wondering if we have any developers here who might be interested in talking about a specific android (or ipad) project. As many of you may know, I am involved with a small company that is developing a UAS (UAV) and autopilot. We have a PC based ground station already developed, but we thought it could be cool to investigate developing something for a mobile tablet platform. The sorts of things we would be looking at include: - live moving map to track the flight in real time (along with other important data) - route plotting/planning - accept and relay basic commands to the UAS (like route changes, altitude or airspeed changes, etc.) - glass cockpit display (similar to this: http://www.youtube.com/watch?v=YkZEX45Hx-s) - display or overlay other real time data from the UAS (for debugging or detailed monitoring of the flight in certain circumstances) - maybe some sort of IP based live video feed (?) This is a low budget project, but we might be able to find a small amount of funding to go towards this effort if we found the right person. Anyone want to chat more about this? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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 Hello Curt ! I am very interested ! Actually, an iOS FlightGear compatible glass cockpit display is one of my summer-planned-projets. As soon as I'm finished with my other contracted works... I work as a freelance programmer in France (stuffs like games, 3d, Unity, C++, audio, iPhone...). Some ideas I was thinking about : -FlightGear remote : connect via telnet, control FlightGear sim remotely. -Glass cockpit : jet, propeller, airliner... Something inspired by the FlightGear 2d panel system (or forked from ?). -mpmap : port the Multiplayer map to iOS. So your project seems interesting, can you tell more about it ? cheers, Jonathan. -- 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] Testing OSG-trunk / bug issue #268
Hi all!
At last I had time to look at the black sky problem which resulted every
time visibility was 1000 meters (or feet?). Anyways, I found the
problem.
Indeed I changed the clear color to be black to make space look better.
But what I didn't know was that the whole sky (dome and stars etc) is
optimised away if visibility is less than that 1000 units.
So the solution is either change the clear color to what it was, or make
it ramp linearly to black or something with altitude.
Or change simgear/scene/sky.cxx around line 117 (repaint method), there
is a
if ( effective_visibility 1000.0 ) {
...
} else {
// turn off sky
disable();
}
so taking that condition away would solve the problem.
What would be the best solution, what do you think?
Zan
--
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] Modified download_and_compile.sh script
Am Donnerstag, den 19.05.2011, 18:34 +0200 schrieb Francesco Angelo Brisa: Hi, I merged the script, applying fixes from Brandano (Who I really thank) and moved version number to 1.4 Thanks Francesco, pushed: https://www.gitorious.org/fg/fgmeta/commit/ae211a06f79aa405273df3d6bfc9963c98b33263 noob question: how to make a git request ? Short explanation: you need a private clone of fgmeta: http://www.gitorious.org/fg/fgmeta = Clone repository Then git pull your private clone to your local machine, update your local repository and git push the changes back to your gitorious clone. Once your private clone on gitorious.org is updated, you can use the Request merge button there. If that's the only file you're working on using git, it may not be worth to set this all up. Otherwise it'll be worth looking at the git manual - or some git-related in our archives. cheers, Thorsten -- 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] heads up: FlightGear release plan
Am Donnerstag, den 19.05.2011, 17:47 +0100 schrieb Vivian Meazza: I think the question we have to ask is not when but how. Until that is solved, the when is pretty meaningless. And the last release got stalled more on a who than a how alone, when several people became too busy/blocked with RL commitments. You may not like that, but you can't blame anyone who has done a lot for FG and who has already invested a lot of free time into the project, that they suddenly need to shift their priorities or need a break for personal reasons. The new plan alone doesn't exclude the risk of this repeating - but there more people actively participate in the release, the less likely we're going to get stalled. So, it's up to all of us. And all of you can help: you can help by testing FlightGear right now and of course the upcoming release candidates and file bug reports. Of course we need as much help as possible for fixing issues. Things in the FG core will need to be fixed - but also issues concerning fgdata, such as working on aircraft or GUI. Everyone can look at the bug tracker, pick issues and submit patches. And even if you can't work on code or aircraft, you can still help by trying to narrow done what exactly causes a specific bug issue (such as testing which commit introduced a particular problem or what command-line/environment/... setting exactly triggers a certain problem). Or you can help with updating/improving manuals. Lots to do - any help is welcome! cheers, Thorsten -- 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] Testing OSG-trunk / bug issue #268
I think that the best setup would use a broken line rather than a simple linear
ramp, to show actual transition outside of atmospheric flight. Would something
like that affect performance much?
Alessandro
From: lauri.pelto...@gmail.com
To: flightgear-devel@lists.sourceforge.net
Date: Thu, 19 May 2011 21:38:38 +0300
Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
Hi all!
At last I had time to look at the black sky problem which resulted every
time visibility was 1000 meters (or feet?). Anyways, I found the
problem.
Indeed I changed the clear color to be black to make space look better.
But what I didn't know was that the whole sky (dome and stars etc) is
optimised away if visibility is less than that 1000 units.
So the solution is either change the clear color to what it was, or make
it ramp linearly to black or something with altitude.
Or change simgear/scene/sky.cxx around line 117 (repaint method), there
is a
if ( effective_visibility 1000.0 ) {
...
} else {
// turn off sky
disable();
}
so taking that condition away would solve the problem.
What would be the best solution, what do you think?
Zan
--
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
--
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
Le 19/05/2011 20:16, flightgear-devel-requ...@lists.sourceforge.net a écrit : 6 Posts unnecessary poluent the devel list just for the pleasure of drooling over the others. Heiko Bravo. People see for themselves. The update of the Lark was barely over when you came to criticize without knowing. It took me 5 minutes to add the 4 versions as suggested by Ron. 5 minutes during which I answered you in private but only in private. And if I made this post here is to carefully explained that I responded to your silly attacks. But no, contaminated the Devel list. But it seems that, in addition to not understand, you do not know to use a computer. Groucho aka Oliver Fels ? Who are this people ? I have known people to justify their defamatory used the names and peudos other people. But then, you're the best at this game. Personally, I take my writing and I do not quote people who did not ask anyone. -- BARANGER Emmanuel http://helijah.free.fr -- 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
