Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
--- Melchior FRANZ [EMAIL PROTECTED] schrieb am Sa, 27.9.2008: Von: Melchior FRANZ [EMAIL PROTECTED] Betreff: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? An: flightgear-devel@lists.sourceforge.net Datum: Samstag, 27. September 2008, 20:08 * Heiko Schulz -- Saturday 27 September 2008: Can some explain why it loads the wrong file? That's an intentional bug, a.k.a. (mis)feature. You can also call it poor design. It was introduced after a discussion in this thread (where my objection was overruled): http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg12849.html And here's another thread where someone called Heiko complains about it ... ;-) http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg15466.html That feature is also why I have to redefine the OSG_FILE_PATH environment variable, so that OSG doesn't use the shiny OSG demo cow.osg instead of our own cow.ac. m. Just wanted to bring this back- for me it is definitely a bug, and should be changed! I don't see any advantages of that! __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Heiko Schulz wrote: --- Melchior FRANZ [EMAIL PROTECTED] schrieb am Sa, 27.9.2008: Von: Melchior FRANZ [EMAIL PROTECTED] Betreff: Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)? An: flightgear-devel@lists.sourceforge.net Datum: Samstag, 27. September 2008, 20:08 * Heiko Schulz -- Saturday 27 September 2008: Can some explain why it loads the wrong file? That's an intentional bug, a.k.a. (mis)feature. You can also call it poor design. It was introduced after a discussion in this thread (where my objection was overruled): You can call it whatever you like :) The consensus is not universally negative. http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg12849.html And here's another thread where someone called Heiko complains about it ... ;-) http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg15466.html That feature is also why I have to redefine the OSG_FILE_PATH environment variable, so that OSG doesn't use the shiny OSG demo cow.osg instead of our own cow.ac. m. Just wanted to bring this back- for me it is definitely a bug, and should be changed! I don't see any advantages of that! I introduced this feature when I found gross performance problems in some of our models; at the time it was radio masts. Some of the problems come from the way they were modeled, others from inefficiencies in the .ac format itself. I wrote a program to run the OSG optimizer, as well as some of my own optimizations, and write out the model in the .osg format. I'm sure you agree that it is not efficient to do this at scenery load time while running FG. The model names are embedded in the scenery, so it's not practical to change them without rebuilding the scenery, AFIAK. Hence, this substitution mechanism. The only problem I see is picking up files from unexpected places, which really means the OSG sample data directory. I didn't really see picking up the wrong cow model as a deal breaker :) But I'm willing to change this scheme if it's really too onerous. Would picking another file extension for the substitution, such as .fgm, satisfy you? Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mingw fixes
Hi Csaba, I commited a modified version of your patch. Csaba Halász a écrit : Hi! Here are some fixes for the mingw platform that I had to make for a successful build. Note, in 2 places I have changed a #include windows.h to a #include Winsock2.h, but that should be ok. For safety, somebody using msvc build please check. No, it broke MSVC build. For some reason, Winsock2.h is already included. Moreover, I am pretty sure the simple substitution of _MSC_VER by WIN32 would have broken an hypothetical Cygwin build. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
* Melchior FRANZ -- Sunday 28 September 2008: The change wasn't/isn't even necessary (see above). Another reason for the patch was that we could use OSG's model embedded particles in the same scenery. Now that we have XML configured OSG particles, this reason is obsolete, too. No reasons left, as far as I can see. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Screenshots of the coming helicopter Eurocopter EC 145
Matthias Boerner wrote: Hello, I would like to announce some screenshots of the coming helicopter Eurocopter EC 145. http://fgfs.i-net.hu/modules/xcgal/thumbnails.php?album=44 Nice details. Robert - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mingw fixes
Csaba Halász a écrit : On Sun, Sep 28, 2008 at 10:33 AM, Frederic Bouvier [EMAIL PROTECTED] wrote: Hi Csaba, I commited a modified version of your patch. Csaba Halász a écrit : Hi! Here are some fixes for the mingw platform that I had to make for a successful build. Note, in 2 places I have changed a #include windows.h to a #include Winsock2.h, but that should be ok. For safety, somebody using msvc build please check. No, it broke MSVC build. For some reason, Winsock2.h is already included. Moreover, I am pretty sure the simple substitution of _MSC_VER by WIN32 would have broken an hypothetical Cygwin build. Thanks Fred! FWIW, my cygwin does not seem to define WIN32 macro. line 226 of configure.ac defines it -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an acciden tly way to landinglights; -)?
On dimanche 28 septembre 2008, Vivian Meazza wrote: gerard robin wrote On dimanche 28 septembre 2008, Melchior FRANZ wrote: * Melchior FRANZ -- Sunday 28 September 2008: The change wasn't/isn't even necessary (see above). Another reason for the patch was that we could use OSG's model embedded particles in the same scenery. Now that we have XML configured OSG particles, this reason is obsolete, too. No reasons left, as far as I can see. m. Not fully right, the XML doesn't give ( all) the features which are into OSG, . So to me the paricles.osg object with animations is longer necessary. For instance, the Catalina and some others that i am working on. The OSG animation particles models could be very accurate within XML, but unfortunately there is missing a lot of features ( more than a lot :) ) which are there within OSG native model. I haven't noticed anything critical missing from the XML particles, and they do put the particles in the right frame of reference, and they do get the right wind, which the osg solution does not. What do you see as missing? Perhaps we can get on the case. There is an update to particles in osg in the pipeline, which I'm currently using, and that does improve the look of the .xml particles. I'm not aware of the current position of that patch. Vivian Since i don't know what is new in the pipeline, i can't precisely answer the question. I only can get some comparison with the actual CVS process ( we had a talk about it before ) The xml which is there, don't give the same result than we have with the .osg effects, and, my models (which are in CVS) are not perfect, i am working on a huge improvement regarding the wake.osg which will increase more the differences. Yes, a long line of trailing smoke is not possible, because there is not any interaction from .osg to .ac and/or externals ( like winds). So, i don't say that the xml is wrong, i only say that it don't give the same eye candy. To remember the first talk we had about it here the link : http://sourceforge.net/mailarchive/forum.php?thread_name=200808121328.41260.ghmalau%40gmail.comforum_name=flightgear-devel = Are we sure that, all the Particle features which are within OSG, are available with the new XML coding particlesystem ? When translating one of my .osg file to particlesystem .xml file, i don't get the same quality of result. It could be just me. I can be wrong. :( Or that new XML coding is may be a first step, and others improvements are coming :) No, all the features of particles are not available with the xml version, but I don't think that should affect performance. Tim recently fixed a bug which only showed up under MSVC9, and other bugs have been reported, in particular that the particles jitter. There are no further enhancements planned to the xml stuff that I am aware of, unless Tiago is doing something. SNIP Vivian = Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mingw fixes
On Sun, Sep 28, 2008 at 4:31 PM, Frederic Bouvier [EMAIL PROTECTED] wrote: Csaba Halász a écrit : Thanks Fred! FWIW, my cygwin does not seem to define WIN32 macro. line 226 of configure.ac defines it -Fred Right, I missed that.Thought it was a compiler built-in. Thanks again for fixing the patch. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug or Feature? Or an accidently way to landinglights; -)?
Hi, I haven't noticed anything critical missing from the XML particles, and they do put the particles in the right frame of reference, and they do get the right wind, which the osg solution does not. Here with win32 builds by Fred, I noticed that xml-particles linked to the aircrafts are broken sicne 2-3 weeks after their implementation! So I could only use it for 2-3 weeks correctly. Only the xml-particles used in scenery objects are behaves correct! What do you see as missing? Perhaps we can get on the case. There is an update to particles in osg in the pipeline, which I'm currently using, and that does improve the look of the .xml particles. I'm not aware of the current position of that patch. Vivian Hopefully it will bring back the particles in a correct way- I found it really annoying to see that a new and missing feature was broken just few weeks after coming in and not been fixed for a nearly half year! Reagrds HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Materials wrong for San Diego bay?
I haven't investigated why and I thought I'd ask whether anybody knows the answer offhand before following up with the underlying data. The entrance to San Diego bay (between North Island airport KNZY and Lindbergh field KSAN) isn't water; it has trees all over it. Is this just a consequence of old land use data, or an incorrect mapping through materials? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Correction for the f16's VRP
Hi, attached is a little patch for the f16. It's VRP is obviously wrong, when watching turns on the ground from outside. I did standard slipping-of-the-edge tests and found an x-value of -180in to improve the situation a lot. Regards, Nine ? Aircraft/f16/initfile.xml Index: Aircraft/f16/f16.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/f16/f16.xml,v retrieving revision 1.67 diff -u -3 -p -r1.67 f16.xml --- Aircraft/f16/f16.xml 23 Sep 2008 18:02:27 - 1.67 +++ Aircraft/f16/f16.xml 28 Sep 2008 18:55:47 - @@ -53,7 +53,7 @@ z 29.5 /z /location location name=VRP unit=IN -x 0 /x +x -180 /x y 0 /y z 0 /z /location - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] renderer.cxx: UPDATE_VISITOR_IN_VIEWER
(mostly for Tim) Chasing other problems, came across this in renderer.cxx, accompanied by: // XXX Make this go away when OSG 2.2 is released. #if (FG_OSG_VERSION = 21004) #define UPDATE_VISITOR_IN_VIEWER 1 #endif Would I be right in thinking this can die, since we're two major OSG releases past 2.2? Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] renderer.cxx: UPDATE_VISITOR_IN_VIEWER
James Turner wrote: (mostly for Tim) Chasing other problems, came across this in renderer.cxx, accompanied by: // XXX Make this go away when OSG 2.2 is released. #if (FG_OSG_VERSION = 21004) #define UPDATE_VISITOR_IN_VIEWER 1 #endif Would I be right in thinking this can die, since we're two major OSG releases past 2.2? Yes. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
