Re: [Flightgear-devel] Flightgear-devel Digest, Vol 61, Issue 9
> Message: 3 > Date: Wed, 18 May 2011 10:33:50 + (UTC) > From: Martin Spott > Subject: Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New > FDM by > To: flightgear-devel@lists.sourceforge.net > Message-ID: > > Heiko Schulz wrote: > >> I hate to say it, but the the new fdm is completly wrong and doesn't >> apply to the real one in any way. > In general I'd recommend first to discuss the item with the author of > the change. 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. > > Cheers, > Martin - being a veritable admirer of the old Alouette II (the > real one, I mean). Thanks Martin, 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 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. This is what it is today. Even if this requires a little cheating. 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 :) ) I notice that Heiko has taken over from Robin G. to attempt to discredit FG and everything that surrounds it. I do not congratulate. Regards. Emmanuel -- 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. On Wed, May 18, 2011 at 9:52 PM, Ron Jensen wrote: > On Wednesday 18 May 2011 18:39:50 Heiko Schulz wrote: > > > 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 > > Helijah's workflow should make it dead simple to create another -set file, > maybe alouette2-easy-set.xml to load the easy fdm. All the settings are in > aloutte2-base.xml anyway. > > My $0.02 > > Ron > > > -- > 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 > -- 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
Re: [Flightgear-devel] GIT commit 31819df8: Alouette II - New FDM by
On Wednesday 18 May 2011 18:39:50 Heiko Schulz wrote: > 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 Helijah's workflow should make it dead simple to create another -set file, maybe alouette2-easy-set.xml to load the easy fdm. All the settings are in aloutte2-base.xml anyway. My $0.02 Ron -- 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] OT: android/ipad development
If you wanted to broadest platform support, I'd suggest looking at WebGL instead, even though it's bleeding edge. As Android and iOS are so different from each other (Programming language, API etc), the amount of effort to build something specific for one platform would exhaust you from building something for the other. There are several JavaScript frameworks that sit on top of WebGL and there are some interesting demos around the Interwebs, the performance is quite impressive for something running in the browser, currently Mozilla Firefox 4 and Google Chrome 11 are the first out with decent implementations, Apple and Opera have said they will implement WebGL as part of their HTML5 canvas implementation. The chromeexperiments website allows you to see the source code for different aspects, the code looks very familiar and quite simple. Some links: http://doesmybrowsersupportwebgl.com/ http://www.chromeexperiments.com/webgl http://blog.tojicode.com/2011/05/ios-rage-rendered-with-webgl.html http://www.glge.org/webgl-demo-sky-and-new-fog-options-in-glge/ http://www.khronos.org/webgl/wiki/Demo_Repository http://helloracer.com/webgl/ https://sites.google.com/a/chromium.org/dev/developers/demos-gpu-acceleration-and-webgl enjoy S. On Wed, 2011-05-18 at 13:36 -0500, Curtis Olson wrote: > 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 -- 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
I currently am in possession of a ARM Cortex-A8 development board, complete with graphics processor(PowerVR SGX) and Android support. If you need any hardware to test software on, I'll be willing to help. It has a screen, though pretty low res(480x272), and the LCD interface got a small issue, but I'll fix this very soon. It also has only 256 MB of RAM. > On Wednesday, May 18, 2011 03:12:24 PM Curtis Olson wrote: > > On Wed, May 18, 2011 at 1:58 PM, Claus Christmann wrote: > > > Have you looked at the "ground control station" for the Parrot AR Drone? > > > http://youtu.be/wtlp7jwvkd4 > > > > The Parrot AR drone is a cool product, but that's a proprietary system, > > right? In our case we would have significantly different design and usage > > goals compared to the parrot drone, but certainly we would need to > > accomplish many of the same technical hurdles. > > > > Our drone flies well beyond wifi range. We are primarily focused on > > outdoor use. The parrot AR drone (as best as I can tell from the videos > > I've seen) is primarily a remote piloted vehicle -- with computer > > stabilization. It probably wouldn't take much to make it fully > > autonomous, but that's not the primary usage that I've seen. (Interactive > > real/VR blended dog fights.) > > > > Curt. > > Hi Curt, > > you are right in all of your points. I was just wondering if you simply > looked > at their software SDK (for a GCS). AFAIK their GCS is iPhone only, but some > people have compiled it for Android. So maybe those guys could give you a > hand > for your GCS system. > > http://www.shellware.com/BlogEngine.Web/page/ARPro-for-Android.aspx is one > example of an Android GCS for the Parrot.AR > > Good Luck, > > Claus > -- 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
How hard would it be to change the background colour based on the camera altitude? Even a linear gradient between two set points would work, I think. > Date: Wed, 18 May 2011 22:41:54 +0200 > From: bre...@gmail.com > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268 > > Ok, the black sky issue was indeed caused by changing the clear color. > The effect is really ugly - black sky when flying through clouds or > fog. Also black sky when flying above a cloud layer. And it's not > restricted to 2D clouds alone. > > That's the relevant commit: > http://www.gitorious.org/fg/flightgear/commit/b36b33f716031ef5933d41a1e5c17c6be3e54c28 > > Apparently the change was introduced "only" to turn the color of space > black instead of gray. I think flying through clouds/fog is more > important than space-flights for now, so I'm planning to revert that > particular commit shortly until we have a better solution. I know it's > a pity and I apologize to all Vostok-1 cosmonauts. :-) > > Any objections (preferably accompanied by a patch ;-) )? > > cheers, > Thorsten > > > On Wed, May 18, 2011 at 9:58 PM, Alan Teeder wrote: > > > > -- > > From: "Martin Spott" > > Sent: Wednesday, May 18, 2011 8:15 PM > > Newsgroups: list.flightgear-devel > > To: > > Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268 > > > >> ThorstenB wrote: > >> > >>> Thanks Curt, that sounds very much like a possible reason. Was that a > >>> change to fg/sg or fgdata? Anyone remembers the exact commit? > >> > >> As far as I remember, it's related to "Lauri Peltonen" and "sky dome", > >> it's implementing a shader (among other stuff) and was indeed meant to > >> bring FG closer to how the sky looks in real life: black :-) > >> I'd have a few commits on offer which might be related, but at least > >> one of them is hiding the possible changes in a big reformatting rush > >> (preferences.xml). > >> > > > > > > Thorsten, Martin. > > > > There is a reference to the black sky problem on the forum at > > http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&start=30 by > > "Zan", the author of the atmospheric scattering patch . > > > > I have been trying various cloud combinations with an aircraft parked on the > > runway, but so far have not made any visible changes. > > > > Alan > > -- > 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] Golf Course Textures
"J. Holden" wrote: > http://www.stattosoftware.com/flightgear/golfcourse.png > AND > http://www.stattosoftware.com/flightgear/golfcourse_winter.png > > If someone could commit these to git and update materials.xml, well, I'd be > very happy. I'm planning to commit these textures together with the corresponding 'materials' update, I'm just having a few other items in the queue. > Not the best textures admittedly ... but considering we don't > currently have a golf course texture, I think necessary. I'm on the same page: Having a reasonably working proof-of-concept for dealing with these more recent landclasses is better than hiding these neat nuances behind the old default textures. 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] Linking in external libraries / make setup of FG
On Wednesday, May 18, 2011 02:50:02 PM Claus Christmann wrote: > Hi, > > I am trying to combine a personal project of mine with FlightGear. In > order to do that, I am writing some C++ code to interact with Matlab (to > be precise, with the Matlab engine). However, I run into trouble when > trying to compile/link my stuff in FG - hence my question on how to do it > "properly" > > Here is what I want to do: > > * I need to include some Matlab specific headers in > /usr/local/MATLAB/R2010b/extern/include > * I need to link against some Matlab libraries in > /usr/local/MATLAB/bin/glnxa64 > > Here is my setup: > > * I put my sources (*.cxx and *.hxx) in a new folder in $FG/src/ETP > * I made a new $FG/src/ETP/Makefile.am : http://pastebin.com/2iGgdWAP > * I altered $FG/src/Main/gf_init.cxx to load my new subsystem: > http://pastebin.com/nWNHGX81 > * I altered $FG/src/Main/Makefile.am to reflect that change : > http://pastebin.com/8cS50Xd4 > * I have the path to the matlab libraries (/usr/local/MATLAB/bin/glnxa64) > in my LD_LIBRARY_PATH via my ~/.bashrc: > export > LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/MATLAB/R2010b/bin/glnxa64 > > I would like to use the sequence > > :$FG> make distclean > :$FG> ./autogen.sh > :$FG> ./configure > :$FG> make > > However, autogen already spits out errors: http://pastebin.com/feCvty3b . > Fixing those, however, does't seem to fix my problem: > http://pastebin.com/wLbBPTFk > > Obviously, ignoring those errors results in not-linked in Matlab libraries, > as the linker will tell me when it tries to link the project: all the > Matlab specific commands used in my sources are unrecognized... > > So could somebody point me to a Makefile.am that includes/links in some > external libraries? Or even better, point me to a (preferably brief) > writeup on how to write Makefile.am s for FG? > > Thanks for any efforts spend... > > Claus So to answer my own post, here is a (as I find very hacked) solution: a) do not include the external libraries into the new sub project. I used this Makefile.am : http://pastebin.com/Pw8EeLrp b) do the linking in the binary, i.e. in ../src/Main. I modified the Makefile.am there to look like this: http://pastebin.com/RfJ5MQRx So the solution is to inlcude the external libraries via -lxxx where you also would include the subprojects libXXX.a and alter the _LDFLAGS to s.t. a direct path to the external libraries is given... (i.e. add -L/where/ever/libs) Although this works, (and as of now I don't intend to change it), I would be interested how to do this "properly"... Regards, Claus -- Claus Christmann, M.S. Graduate Research Assistant Georgia Institute of Technology 270 Ferst Dr NW Atlanta, GA 30332-0150 http://uav.ae.gatech.edu -- 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
I did actually speak with Brisa this afternoon, and he will probably merge the changes tomorrow or in the next few days. I only posted this version to the ML because the changes to FGCOM compilation are a couple of weeks old and I thought Francesco had already requested them to be included into GIT. I have my own slightly divergent copy of the script, and only realized the issue was still outstanding when someone on IRC was having trouble compiling a couple of days ago. Ciao, Alessandro > Date: Wed, 18 May 2011 20:52:01 +0200 > From: bre...@gmail.com > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Modified download_and_compile.sh script > > On 18.05.2011 01:08, TDO_Brandano - wrote: > > I have applied a couple of small modifications to the script to fix > > FGCOM and ATLAS compilation with the current repository versions of > > both. The changes are relatively small, just a couple of sed rule > > changes for the FGCOM makefile and a renamed function in ATLAS to match > > the updated SimGear. I have also altered the script version string and > > name to avoid confusion with Brisa's original, but I have no idea on who > > decides what is the current version of the script. Could someone have a > > quick look at the attached copy and see if the changes can be ported > > over to GIT? > > Hi Brandano, > I placed the script in GIT since > a) we want all build scripts to be part of the new "fgmeta" GIT > repository, which at some point will also reference consistent > simgear/flightgear/fgdata sets (and keep the history of matching > revisions) - so anyone can just pull "fgmeta" and always get a > consistent snap shot - including the build scripts. > b) we needed a repository where we can change all required versions > (flightgear, osg, ...) used by the build script whenever there's a need > to change. And we needed to stop it from using osg-trunk by default. > > What I didn't intend was to fork the script - so changing the name would > go in the wrong direction. It'd be great if you could try to contact > Brisa first and ask him to review or merge the scripts - so we avoid > maintaining separate branches here. > I'm happy to add any updates/improvements to fgmeta. You or Brisa could > send updates to me (or even place a GIT merge request). But I'd prefer > if Brisa stayed in the loop. > > 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 -- 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
On 18.05.2011 22:45, Csaba Halász wrote: > On Wed, May 18, 2011 at 8:19 PM, ThorstenB wrote: >> >> Thanks Csaba, that's already close! I looked at the commit logs but >> didn't find any obvious culprit. A good next test would be r12312 - > > ... which is broken. > Turns out 12303 is the cause for the constant sunshine ;) Great! Excellent you've found it! > Specifically, the GLSL version parsing has been broken: > > Original code: _glslLanguageVersion = asciiToFloat( langVerStr ); > New code: _glslLanguageVersion = ( asciiToFloat( glslvs.substr( > glslvs.find( "GLSL "+5 ) ).c_str() ) ); > > The version string for me here is simply "3.30" (using fglrx 11.4), so > the old code works but the new one doesn't. > Incidentally, the GL version parsing doesn't work either, because > version string is "3.3.10666 Compatibility Profile Context" and the > code (both the old and the new) expect a decimal number before the > space. > > I can't really believe this is the best way to get version numbers from > opengl. Indeed. And a very good find! I can't believe they've just hard-coded some "+5"s and "+8"s to the index to "parse" the version string. Stuff like this has to fail. Can you please post this find at osg-devel? I could cross-post for you, but then again it'd be good if you could do the follow ups on this. 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
On Wed, May 18, 2011 at 8:19 PM, ThorstenB wrote: > > Thanks Csaba, that's already close! I looked at the commit logs but > didn't find any obvious culprit. A good next test would be r12312 - ... which is broken. Turns out 12303 is the cause for the constant sunshine ;) Specifically, the GLSL version parsing has been broken: Original code: _glslLanguageVersion = asciiToFloat( langVerStr ); New code: _glslLanguageVersion = ( asciiToFloat( glslvs.substr( glslvs.find( "GLSL "+5 ) ).c_str() ) ); The version string for me here is simply "3.30" (using fglrx 11.4), so the old code works but the new one doesn't. Incidentally, the GL version parsing doesn't work either, because version string is "3.3.10666 Compatibility Profile Context" and the code (both the old and the new) expect a decimal number before the space. I can't really believe this is the best way to get version numbers from opengl. -- Csaba/Jester -- 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
Ok, the black sky issue was indeed caused by changing the clear color. The effect is really ugly - black sky when flying through clouds or fog. Also black sky when flying above a cloud layer. And it's not restricted to 2D clouds alone. That's the relevant commit: http://www.gitorious.org/fg/flightgear/commit/b36b33f716031ef5933d41a1e5c17c6be3e54c28 Apparently the change was introduced "only" to turn the color of space black instead of gray. I think flying through clouds/fog is more important than space-flights for now, so I'm planning to revert that particular commit shortly until we have a better solution. I know it's a pity and I apologize to all Vostok-1 cosmonauts. :-) Any objections (preferably accompanied by a patch ;-) )? cheers, Thorsten On Wed, May 18, 2011 at 9:58 PM, Alan Teeder wrote: > > -- > From: "Martin Spott" > Sent: Wednesday, May 18, 2011 8:15 PM > Newsgroups: list.flightgear-devel > To: > Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268 > >> ThorstenB wrote: >> >>> Thanks Curt, that sounds very much like a possible reason. Was that a >>> change to fg/sg or fgdata? Anyone remembers the exact commit? >> >> As far as I remember, it's related to "Lauri Peltonen" and "sky dome", >> it's implementing a shader (among other stuff) and was indeed meant to >> bring FG closer to how the sky looks in real life: black :-) >> I'd have a few commits on offer which might be related, but at least >> one of them is hiding the possible changes in a big reformatting rush >> (preferences.xml). >> > > > Thorsten, Martin. > > There is a reference to the black sky problem on the forum at > http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&start=30 by > "Zan", the author of the atmospheric scattering patch . > > I have been trying various cloud combinations with an aircraft parked on the > runway, but so far have not made any visible changes. > > Alan -- 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
-- From: "Martin Spott" Sent: Wednesday, May 18, 2011 8:15 PM Newsgroups: list.flightgear-devel To: Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268 > ThorstenB wrote: > >> Thanks Curt, that sounds very much like a possible reason. Was that a >> change to fg/sg or fgdata? Anyone remembers the exact commit? > > As far as I remember, it's related to "Lauri Peltonen" and "sky dome", > it's implementing a shader (among other stuff) and was indeed meant to > bring FG closer to how the sky looks in real life: black :-) > I'd have a few commits on offer which might be related, but at least > one of them is hiding the possible changes in a big reformatting rush > (preferences.xml). > Thorsten, Martin. There is a reference to the black sky problem on the forum at http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&start=30 by "Zan", the author of the atmospheric scattering patch . I have been trying various cloud combinations with an aircraft parked on the runway, but so far have not made any visible changes. Alan -- 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
Hi, Am 18.05.2011 21:09 schrieb Heiko Schulz: > >> 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. > actually I don't have a up to date Flightgear installation on my computer. Therefore I was not able to make a testflight with the new fdm. But I had a look to the xml file of the fdm and I am 99% sure, that this fdm has nothing to do with the flight behavior of the real aloutte 2. 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 -- 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
On Wednesday, May 18, 2011 03:12:24 PM Curtis Olson wrote: > On Wed, May 18, 2011 at 1:58 PM, Claus Christmann wrote: > > Have you looked at the "ground control station" for the Parrot AR Drone? > > http://youtu.be/wtlp7jwvkd4 > > The Parrot AR drone is a cool product, but that's a proprietary system, > right? In our case we would have significantly different design and usage > goals compared to the parrot drone, but certainly we would need to > accomplish many of the same technical hurdles. > > Our drone flies well beyond wifi range. We are primarily focused on > outdoor use. The parrot AR drone (as best as I can tell from the videos > I've seen) is primarily a remote piloted vehicle -- with computer > stabilization. It probably wouldn't take much to make it fully > autonomous, but that's not the primary usage that I've seen. (Interactive > real/VR blended dog fights.) > > Curt. Hi Curt, you are right in all of your points. I was just wondering if you simply looked at their software SDK (for a GCS). AFAIK their GCS is iPhone only, but some people have compiled it for Android. So maybe those guys could give you a hand for your GCS system. http://www.shellware.com/BlogEngine.Web/page/ARPro-for-Android.aspx is one example of an Android GCS for the Parrot.AR Good Luck, Claus -- Claus Christmann, M.S. Graduate Research Assistant Georgia Institute of Technology 270 Ferst Dr NW Atlanta, GA 30332-0150 http://uav.ae.gatech.edu -- 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
ThorstenB wrote: > Thanks Curt, that sounds very much like a possible reason. Was that a > change to fg/sg or fgdata? Anyone remembers the exact commit? As far as I remember, it's related to "Lauri Peltonen" and "sky dome", it's implementing a shader (among other stuff) and was indeed meant to bring FG closer to how the sky looks in real life: black :-) I'd have a few commits on offer which might be related, but at least one of them is hiding the possible changes in a big reformatting rush (preferences.xml). 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] OT: android/ipad development
On Wed, May 18, 2011 at 1:58 PM, Claus Christmann wrote: > Have you looked at the "ground control station" for the Parrot AR Drone? > http://youtu.be/wtlp7jwvkd4 > The Parrot AR drone is a cool product, but that's a proprietary system, right? In our case we would have significantly different design and usage goals compared to the parrot drone, but certainly we would need to accomplish many of the same technical hurdles. Our drone flies well beyond wifi range. We are primarily focused on outdoor use. The parrot AR drone (as best as I can tell from the videos I've seen) is primarily a remote piloted vehicle -- with computer stabilization. It probably wouldn't take much to make it fully autonomous, but that's not the primary usage that I've seen. (Interactive real/VR blended dog fights.) 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
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] OT: android/ipad development
On Wednesday, May 18, 2011 02:36:25 PM Curtis Olson wrote: > 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. Have you looked at the "ground control station" for the Parrot AR Drone? http://youtu.be/wtlp7jwvkd4 Claus -- Claus Christmann, M.S. Graduate Research Assistant Georgia Institute of Technology 270 Ferst Dr NW Atlanta, GA 30332-0150 http://uav.ae.gatech.edu -- 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
On 18.05.2011 20:39, Curtis Olson wrote: > I seem to recall we changed the clear color to black recently. It may > be that with 2d clouds we were depending on the clear color matching the > fog color for correct rendering? I'm not sure what the motivation for > changing the clear color was, but I'm guessing it was related to the sky > dome or drawing space views??? Thanks Curt, that sounds very much like a possible reason. Was that a change to fg/sg or fgdata? Anyone remembers the exact commit? Again, would be great if s.o. could test the 2D cloud / sky-color behaviour with and without the specific "clear color"-patch. If that patch was the cause, then we may need to revert it - and find a better solution. 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] Modified download_and_compile.sh script
On 18.05.2011 01:08, TDO_Brandano - wrote: > I have applied a couple of small modifications to the script to fix > FGCOM and ATLAS compilation with the current repository versions of > both. The changes are relatively small, just a couple of sed rule > changes for the FGCOM makefile and a renamed function in ATLAS to match > the updated SimGear. I have also altered the script version string and > name to avoid confusion with Brisa's original, but I have no idea on who > decides what is the current version of the script. Could someone have a > quick look at the attached copy and see if the changes can be ported > over to GIT? Hi Brandano, I placed the script in GIT since a) we want all build scripts to be part of the new "fgmeta" GIT repository, which at some point will also reference consistent simgear/flightgear/fgdata sets (and keep the history of matching revisions) - so anyone can just pull "fgmeta" and always get a consistent snap shot - including the build scripts. b) we needed a repository where we can change all required versions (flightgear, osg, ...) used by the build script whenever there's a need to change. And we needed to stop it from using osg-trunk by default. What I didn't intend was to fork the script - so changing the name would go in the wrong direction. It'd be great if you could try to contact Brisa first and ask him to review or merge the scripts - so we avoid maintaining separate branches here. I'm happy to add any updates/improvements to fgmeta. You or Brisa could send updates to me (or even place a GIT merge request). But I'd prefer if Brisa stayed in the loop. 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
[Flightgear-devel] Linking in external libraries / make setup of FG
Hi, I am trying to combine a personal project of mine with FlightGear. In order to do that, I am writing some C++ code to interact with Matlab (to be precise, with the Matlab engine). However, I run into trouble when trying to compile/link my stuff in FG - hence my question on how to do it "properly" Here is what I want to do: * I need to include some Matlab specific headers in /usr/local/MATLAB/R2010b/extern/include * I need to link against some Matlab libraries in /usr/local/MATLAB/bin/glnxa64 Here is my setup: * I put my sources (*.cxx and *.hxx) in a new folder in $FG/src/ETP * I made a new $FG/src/ETP/Makefile.am : http://pastebin.com/2iGgdWAP * I altered $FG/src/Main/gf_init.cxx to load my new subsystem: http://pastebin.com/nWNHGX81 * I altered $FG/src/Main/Makefile.am to reflect that change : http://pastebin.com/8cS50Xd4 * I have the path to the matlab libraries (/usr/local/MATLAB/bin/glnxa64) in my LD_LIBRARY_PATH via my ~/.bashrc: export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/MATLAB/R2010b/bin/glnxa64 I would like to use the sequence :$FG> make distclean :$FG> ./autogen.sh :$FG> ./configure :$FG> make However, autogen already spits out errors: http://pastebin.com/feCvty3b . Fixing those, however, does't seem to fix my problem: http://pastebin.com/wLbBPTFk Obviously, ignoring those errors results in not-linked in Matlab libraries, as the linker will tell me when it tries to link the project: all the Matlab specific commands used in my sources are unrecognized... So could somebody point me to a Makefile.am that includes/links in some external libraries? Or even better, point me to a (preferably brief) writeup on how to write Makefile.am s for FG? Thanks for any efforts spend... Claus -- Claus Christmann, M.S. Graduate Research Assistant Georgia Institute of Technology 270 Ferst Dr NW Atlanta, GA 30332-0150 http://uav.ae.gatech.edu -- 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 seem to recall we changed the clear color to black recently. It may be that with 2d clouds we were depending on the clear color matching the fog color for correct rendering? I'm not sure what the motivation for changing the clear color was, but I'm guessing it was related to the sky dome or drawing space views??? Curt. On Wed, May 18, 2011 at 1:30 PM, ThorstenB wrote: > On 18.05.2011 18:16, Alan Teeder wrote: > > As requested I have today tested with VC2010 and all the pre-compiled > > versions of OSG that I have available. > > > > These are OSG 2,8.4 and OSG trunk (at present OSG 2.9.12) from > > > http://openscenegraph.alphapixel.com/osg/downloads/free-openscenegraph-binary-downloads > > and and OSG 2.9.10 from > > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/). > > > > I have black sky in all 3 as we have discussed in > > http://sourceforge.net/mailarchive/message.php?msg_id=27467054. > > > > I did not bother with a cmake for each of these , just copied the OSG > bin, > > include and lib directories to my > > C:\FlightGear\install\msvc100\OpenSceneGraph directory and then did a > > build-clean followed by a build and install of both simgear and > flightgear. > > > > The random yelllow text bug was apparent on the splash screens as well. > > Ok, thanks for testing Alan. At LinuxTag we actually noticed an issue > that happened when 3D clouds were disabled. Whenever flying in between > 2D cloud sheets, the sky turned black (with white 2D clouds) - really > ugly. Didn't happen with 3D cloud support enabled. And we figured that's > a genuine FG bug, which must have been introduced only recently. Might > be the result of some shader change (maybe by introducing the new sky > dome shader, but not sure). Do you see a difference when > enabling/disabling 3D cloud support? > > 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 > -- 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
[Flightgear-devel] OT: android/ipad development
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
Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
On 18.05.2011 18:16, Alan Teeder wrote: > As requested I have today tested with VC2010 and all the pre-compiled > versions of OSG that I have available. > > These are OSG 2,8.4 and OSG trunk (at present OSG 2.9.12) from > http://openscenegraph.alphapixel.com/osg/downloads/free-openscenegraph-binary-downloads > and and OSG 2.9.10 from > ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/). > > I have black sky in all 3 as we have discussed in > http://sourceforge.net/mailarchive/message.php?msg_id=27467054. > > I did not bother with a cmake for each of these , just copied the OSG bin, > include and lib directories to my > C:\FlightGear\install\msvc100\OpenSceneGraph directory and then did a > build-clean followed by a build and install of both simgear and flightgear. > > The random yelllow text bug was apparent on the splash screens as well. Ok, thanks for testing Alan. At LinuxTag we actually noticed an issue that happened when 3D clouds were disabled. Whenever flying in between 2D cloud sheets, the sky turned black (with white 2D clouds) - really ugly. Didn't happen with 3D cloud support enabled. And we figured that's a genuine FG bug, which must have been introduced only recently. Might be the result of some shader change (maybe by introducing the new sky dome shader, but not sure). Do you see a difference when enabling/disabling 3D cloud support? 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
On 18.05.2011 19:29, Csaba Halász wrote: > On Wed, May 18, 2011 at 8:45 AM, ThorstenB wrote: >> working/non-working OSG revision in between 11900 and 12419, you're >> welcome to let us know. Also, maybe someone has an extremely powerful >> machine and could help with testing different OSG revisions. > > My machine is not extremely powerful, but 12300 works while 12330 doesn't. Thanks Csaba, that's already close! I looked at the commit logs but didn't find any obvious culprit. A good next test would be r12312 - which is the OSG 2.9.13 dev release. Everything before 12312 was actual development (nothing obvious), everything after 12312 were code changes to fix compiler warnings and Coverity code analysis issues. This one will be fun... ;-) > Message understood ;-) > I'll have al look during the next days. There is not much spare time to > dedicate to fg, though but I'll give it a try. Thanks Torsten, though the message wasn't specifically for you. But our FlightGear monster server could probably be helpful here indeed. 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
On Wed, May 18, 2011 at 8:45 AM, ThorstenB wrote: > working/non-working OSG revision in between 11900 and 12419, you're > welcome to let us know. Also, maybe someone has an extremely powerful > machine and could help with testing different OSG revisions. My machine is not extremely powerful, but 12300 works while 12330 doesn't. -- Csaba/Jester -- 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
As requested I have today tested with VC2010 and all the pre-compiled versions of OSG that I have available. These are OSG 2,8.4 and OSG trunk (at present OSG 2.9.12) from http://openscenegraph.alphapixel.com/osg/downloads/free-openscenegraph-binary-downloads and and OSG 2.9.10 from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/). I have black sky in all 3 as we have discussed in http://sourceforge.net/mailarchive/message.php?msg_id=27467054. I did not bother with a cmake for each of these , just copied the OSG bin, include and lib directories to my C:\FlightGear\install\msvc100\OpenSceneGraph directory and then did a build-clean followed by a build and install of both simgear and flightgear. The random yelllow text bug was apparent on the splash screens as well. Alan -- 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] Atmosphere
> From: "Torsten Dreyer" > > Loosing the ability to control the atmosphere within FlightGear would be > a massive loss of functionality. We currently control atmosphere in > several different ways like real weather based on METAR. The "local > weather" project has just started to create a complex weather simulation > system and I am (slowly but steadily) working on adding more live > weather data, including aloft wind, temp and dewpoint for any point of > this world. > It would be a huge degression to be able to fly within ICAO standard > atmosphere, only. > > Torsten I should have worded this better, because it's not my intention to propose removing functionality with FlightGear. What I mean to ask is what is the current (and planned) way that FlightGear interacts with atmosphere modeling (not referring to winds, at the moment)? The JSBSim standard atmosphere models the U.S. Standard Atmosphere, and supports user-supplied adjustments to the temperature. In the FlightGear/JSBSim interface there is an allowance made to drive the atmosphere model by setting temperature, pressure, and density. At this point (with FlightGear driving STP), any calculations done by the JSBSim standard atmosphere model because superfluous. In the case where FlightGear is to drive the atmosphere model for JSBSim aircraft, there should be what amounts to a null atmosphere model that only provides the C++ interface to storage and common atmosphere calculations (viscosity calcs, for instance). Trying to make the JSBSim standard atmosphere model serve both purposes has resulted in code that is convoluted and difficult to read, and error prone. So, the question that remains is to consider how to provide the capabilities that both parts need. I'm beginning to think that FlightGear should provide its own atmosphere model, and then just copy values into a null JSBSim atmosphere model when integrated with FlightGear, or be happy with the JSBSim implementation of the standard atmosphere with temperature and pressure offsets. Winds and turbulence are another matter. We have a couple of turbulence models and the recently added Milstd and Tustin wind models are looking pretty good. In a discussion on the JSBSim developer list, I proposed separating out the wind model and the atmosphere model. It's all open for discussion ... JB -- 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
If you want to do that, count me in. All you have to do is explain me a bit what I have to do. I have been looking at the source code, but I don´t know where the branches to merge are. Thanks for the information. See you, Marcel Fernández 2011/5/17 Martin Spott > Marcel Fernandez wrote: > > > Thanks for your help martin, I??m going to get a copy. > > BTW, I just reminded that I'm having a copy of a source code package > implementing OpenRadar-on-HLA (as an additional data feed for > OpenRadar, like FG multiplayer and ADEXP). Everything pure Java, like > the rest of OpenRadar, but I've hardly every looked into it. Might be > worth integrating as well, now that FlightGear has native HLA support > built in. > > 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 > -- 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] Atmosphere
Am 18.05.2011 14:32, schrieb Ron Jensen: > On Tuesday 17 May 2011 21:35:59 Jon S. Berndt wrote: >>> What is the requirement from the FlightGear side for an atmosphere >>> model? >>> I'd like to remove the capability to drive the JSBSim standard >>> atmosphere >>> model from FlightGear, but first I'd like to get a clear picture of how >>> FlightGear users interact with the atmosphere, if at all. >>> >>> Comments? >>> >>> Jon >> In other words, this property: >> >> /environment/params/control-fdm-atmosphere >> >> Will then be deprecated and have no effect. >> >> Jon > Jon, > > It is my understanding that this is an either/or situation where we either > have the FDM atmosphere model or the FlightGear supplied model based on this > value. Flightgear's model can be driven by live METAR data and has variable > lapse rates based on temperature and field pressure. Loosing the ability to control the atmosphere within FlightGear would be a massive loss of functionality. We currently control atmosphere in several different ways like real weather based on METAR. The "local weather" project has just started to create a complex weather simulation system and I am (slowly but steadily) working on adding more live weather data, including aloft wind, temp and dewpoint for any point of this world. It would be a huge degression to be able to fly within ICAO standard atmosphere, only. 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] Testing OSG-trunk / bug issue #268
> Ok, thanks. We'll probably have to narrow it down to the exact OSG > commit to see what changed there. If anyone else has a > working/non-working OSG revision in between 11900 and 12419, you're > welcome to let us know. Also, maybe someone has an extremely powerful > machine and could help with testing different OSG revisions. > I've created a tracker issue - you could just post working/non-working > revisions there: > http://code.google.com/p/flightgear-bugs/issues/detail?id=317 Message understood ;-) I'll have al look during the next days. There is not much spare time to dedicate to fg, though but I'll give it a try. Making osg, sg and fg is just a matter of 1-2 minutes on our machine. 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] Atmosphere
On Tuesday 17 May 2011 21:35:59 Jon S. Berndt wrote: > > What is the requirement from the FlightGear side for an atmosphere > > model? > > I'd like to remove the capability to drive the JSBSim standard > > atmosphere > > model from FlightGear, but first I'd like to get a clear picture of how > > FlightGear users interact with the atmosphere, if at all. > > > > Comments? > > > > Jon > > In other words, this property: > > /environment/params/control-fdm-atmosphere > > Will then be deprecated and have no effect. > > Jon Jon, It is my understanding that this is an either/or situation where we either have the FDM atmosphere model or the FlightGear supplied model based on this value. Flightgear's model can be driven by live METAR data and has variable lapse rates based on temperature and field pressure. Thanks, Ron -- 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
Heiko Schulz wrote: > I hate to say it, but the the new fdm is completly wrong and doesn't > apply to the real one in any way. In general I'd recommend first to discuss the item with the author of the change. 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. Cheers, Martin - being a veritable admirer of the old Alouette II (the real one, I mean). -- 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
[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] Testing OSG-trunk / bug issue #268
That's 519 possible culprits. It will take 10 compiles to find the exact revision by successive approximations. > Date: Wed, 18 May 2011 08:45:11 +0200 > From: bre...@gmail.com > To: flightgear-devel@lists.sourceforge.net > Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268 > > On 18.05.2011 01:42, Csaba Halász wrote: > >>> Also: it seems 3D clouds are broken with current OSG-trunk. Works well > >>> for me with older OSG versions. Can anyone else confirm the issue? > > Downgraded to svn rev 11900, got 3D clouds back. Note, I am not saying > > the breakage occurred there, I just randomly picked that as a testing > > point. > > Ok, thanks. We'll probably have to narrow it down to the exact OSG > commit to see what changed there. If anyone else has a > working/non-working OSG revision in between 11900 and 12419, you're > welcome to let us know. Also, maybe someone has an extremely powerful > machine and could help with testing different OSG revisions. > I've created a tracker issue - you could just post working/non-working > revisions there: > http://code.google.com/p/flightgear-bugs/issues/detail?id=317 > > 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 -- 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
