Re: [Flightgear-devel] FlightGear 2.0.0 release process: Update
On Wed, Feb 3, 2010 at 12:33 AM, John Denker wrote: > > > The "rc4" from a couple of days ago has a glitch > that I haven't seen before: > > FRAGMENT glCompileShader "" FAILED > FRAGMENT Shader "" infolog: > Fragment shader failed to compile with the following errors: > ERROR: 0:28: error(#162) Wrong operand types no operation '*' exists that > takes a left-hand operand of type 'default varying 4-component vector of > float' and a right operand of type '3-component vector of float' (or there > is no acceptable conversion) > ERROR: 0:27: error(#160) Cannot convert from '4-component vector of float' > to '3-component vector of float' > ERROR: error(#273) 2 compilation errors. No code generated > > What hardware and driver? A possible workaround is to comment out the conditional tests related to gl_FrontFacing in Shaders/default.frag and Shaders/mat-anim.frag. Tim -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
On 02/03/2010 12:22 AM, Tim Moore wrote: > This might be associated with the replay system, and I don't see a good way > to turn it off completely. Try starting with /sim/replay/disable set to true > and see if that changes anything. No change. Also FWIW turning off random vegetation = no change. Also FWIW there are intermittent segfaults. (The memory hemorrhage is 100% reproducible chez moi, but the segfaults are not.) For example: http://www.av8n.com/fly/fgfs/jfk-segv-2feb10.log > Does this number keep going up after the scenery is loaded? All the relevant scenery was loaded in the first minute. Remember, this occurs while sitting on the ground. No movement, no new scenery. Well, actually there is some movement, because we still have problems with parked aircraft sliding around, but that's a whole different bug. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Get rid of annoying "Failed to load object" message
John Denker wrote: > The commit messages for these commits seem self-explanatory. > > commit f38db3f433e77cd59c2332dbda779774768bcf96 > Author: John Denker > Date: Tue Feb 2 22:00:17 2010 -0700 > > Get rid of annoying "Failed to load object" message. > > diff --git a/materials.xml b/materials.xml > index 0ccd581..9e65486 100644 > --- a/materials.xml > +++ b/materials.xml > @@ -988,7 +988,6 @@ Shared parameters for various materials. > Models/Residential/zone_maisons_carre-ba.ac > Models/Residential/zone_maisons_long-ba.ac > Models/Residential/zone_maisons_grd-ba.ac > - > 10 > random > Oops, my bad. Thanks for the report. Erik -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 2.0.0 release process: Update
On Wed, Feb 3, 2010 at 9:09 AM, Tim Moore wrote: > > > On Wed, Feb 3, 2010 at 12:33 AM, John Denker wrote: > >> >> >> The "rc4" from a couple of days ago has a glitch >> that I haven't seen before: >> >> FRAGMENT glCompileShader "" FAILED >> FRAGMENT Shader "" infolog: >> Fragment shader failed to compile with the following errors: >> ERROR: 0:28: error(#162) Wrong operand types no operation '*' exists that >> takes a left-hand operand of type 'default varying 4-component vector of >> float' and a right operand of type '3-component vector of float' (or there >> is no acceptable conversion) >> ERROR: 0:27: error(#160) Cannot convert from '4-component vector of float' >> to '3-component vector of float' >> ERROR: error(#273) 2 compilation errors. No code generated >> >> What hardware and driver? A possible workaround is to comment out the > conditional tests related to gl_FrontFacing > in Shaders/default.frag and Shaders/mat-anim.frag. > Tim > > Whoops, never mind. Try the Shaders/mat-anim.frag that I just checked into CVS data. I devine that the hardware is ATI... Tim -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
On Wed, Feb 3, 2010 at 9:10 AM, John Denker wrote: > On 02/03/2010 12:22 AM, Tim Moore wrote: > > This might be associated with the replay system, and I don't see a good > way > > to turn it off completely. Try starting with /sim/replay/disable set to > true > > and see if that changes anything. > > No change. > > Also FWIW turning off random vegetation = no change. > > Also FWIW there are intermittent segfaults. (The > memory hemorrhage is 100% reproducible chez moi, but > the segfaults are not.) For example: > http://www.av8n.com/fly/fgfs/jfk-segv-2feb10.log > > > Does this number keep going up after the scenery is loaded? > > All the relevant scenery was loaded in the first minute. > > Remember, this occurs while sitting on the ground. No > movement, no new scenery. > I can't reproduce the memory hemorrhage here, with either the default aircraft or the dhc3W. Do you still get it now, after the shader errors have (hopefully) been banished? Tim -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] BugFix - 787
( not sure how to reply to the thread, I don't have it in my mail. This is in reference to : http://sourceforge.net/mailarchive/message.php?msg_name=4B58FCDF.1000905%40daffodil.uk.com ) Hello, I have been looking into the 787 yasim fuselage , using the blender import script by Melchior Franz as suggested. Using the original 787.xml file as it is in CVS now, ie : we see the following : http://imagebin.org/83127 Without surprise, that fuselage section has zero length. I stretched it in blender so that it fits the model fuselage ( shown in wire on the image ) : http://imagebin.org/83128 So blender gives us the following measurements for the tip of that section: http://imagebin.org/83129 Given that X is reverted in blender, the corrected relevant yasim line would then be : This makes a total yasim fuselage length of 25.91 + 29.338 = 55.248, closer to the 56.7 that LeeE gives us as reference. I presume this fix makes it much closer to the author's original intention. Now this would need flight testing, and I am no expert with 787 flight, so my experiments would not give a good lighting on the problem. If someone with 787 knowledge could try this, and finds it flies correctly, maybe we could commit it to CVS, hoping that the author will not be upset that we change his file. I just wanted to give my 2 cents , and try to revive a plane that seems to be a nice one , and suffers a little typo that sticks it in the garage :) Please find the corrected 787.xml file attached. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BugFix - Re: Bugs: 787
Hello, I have been looking into the 787 yasim fuselage , using the blender import script by Melchior Franz as suggested. Using the original 787.xml file as it is in CVS now, ie : we see the following : http://imagebin.org/83127 Without surprise, that fuselage section has zero length. I stretched it in blender so that it fits the model fuselage ( shown in wire on the image ) : http://imagebin.org/83128 So blender gives us the following measurements for the tip of that section: http://imagebin.org/83129 Given that X is reverted in blender, the corrected relevant yasim line would then be : This makes a total yasim fuselage length of 25.91 + 29.338 = 55.248, closer to the 56.7 that LeeE gives us as reference. I presume this fix makes it much closer to the author's original intention. Now this would need flight testing, and I am no expert with 787 flight, so my experiments would not give a good lighting on the problem. If someone with 787 knowledge could try this, and finds it flies correctly, maybe we could commit it to CVS, hoping that the author will not be upset that we change his file. I just wanted to give my 2 cents , and try to revive a plane that seems to be a nice one , and suffers a little typo that sticks it in the garage :) Please find the corrected 787.xml file attached. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration info
On 02/03/2010 01:37 AM, Tim Moore wrote: >>> What hardware and driver? A possible workaround is to comment out the >> conditional tests related to gl_FrontFacing >> in Shaders/default.frag and Shaders/mat-anim.frag. >> Tim >> >> Whoops, never mind. Try the Shaders/mat-anim.frag that I just checked into > CVS data. > > I devine that the hardware is ATI... No need for divination. As always, configuration info is at http://www.av8n.com/fly/fgfs/barf.log There is a little script to collect that information: http://www.av8n.com/fly/fgfs/barf You might want to encourage people to use such a script when submitting bug reports. It obviates a lot of divination. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
On 02/03/2010 02:00 AM, Tim Moore wrote: > Do you still get it now, after the shader errors have > (hopefully) been banished? Three answers: 1) The shader issue is greatly improved. No more nasty shader-related error messages on the console. This is an improvement at all airports, not just JFK, whereas the memory hemorrhage was observed only at JFK. 2) The memory issue is improved. I no longer observe the 144 megabytes per minute steady hemorrhage. The "RES" number goes rather quickly to about 900 megs and sits there. 3) Whether the new behavior is entirely correct is something we should discuss. The memory usage at JFK is 400 or 500 megs larger than it would be at a "normal" airport. I know the NYC scene is complex, but jeepers, 500 megs complex? As the saying goes, a picture is worth athousand words, but half a billion? Really? That's about 500 bytes for every pixel on the screen. I mention this because I betcha lots of users of the new release will not have hardware that can handle this. I've got a rather capable machine, capable of 70 frames per second of "normal" scenery, but it can only do 20 in the NYC area. An it is an ugly 20. Very jerky. It "looks" more like 10 fps, and sometimes only 5, even though FG writes 20 in the corner of the screen. Do we really need hundreds of bytes of scenery /for every pixel on the screen/ ... or is there some way to lower the memory usage and/or raise the frame rate? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] memory hemorrhage
Hi, > > I mention this because I betcha lots of users of > the new release will not have hardware that can > handle this. I've got a rather capable machine, > capable of 70 frames per second of "normal" > scenery, but it can only do 20 in the NYC area. > An it is an ugly 20. Very jerky. It "looks" > more like 10 fps, and sometimes only 5, even > though FG writes 20 in the corner of the screen. > > Do we really need hundreds of bytes of scenery > /for every pixel on the screen/ ... or is there > some way to lower the memory usage and/or raise > the frame rate? > I did not yet look at at this scenery tile, but could it be that it uses a lot of .xml's? Vivian and me noticed already that a scenery using many .xml's will slow down even high capable systems a lot! Bad example are Paris and currently EDDP around the small villages inside the airport. Cheers Heiko __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Mac OS X pre3
Hi, I tested pre3 on my two macs. Dual core 27" iMac report: As previously fg won't work on my iMac. As with the previous pre-releases fg crashes during initialization. I am working on getting a debug compile of Tats code. I've reached the end of compiling all the packages but fail on getting the linker to produce fgfs - the linker complains about not being able to find fopen!! I have started a new repoupdate and compile of macflightgear with debug flags using Tat's localbuild script. Atlas crashes too, more about this below. Dual core 2 year old MacBook Pro: fg and terrasync works. Atlas fails. Atlas: The issue with Atlas crashing is that the apt.dat.gz in the package outdated. If I replace apt.dat.gz with the latest CVS version Atlas works. The issue with ATLAS/apt.dat.gz was reported some days ago and fixed in CVS. There is another issue with Atlas. The map goes black when starting from another airport than San Fransisco. Restarting fg will not generated the needed png's. Is Map run properly? Cheers, Jari On 2/3/10 2:53 AM, Tatsuhiro Nishioka wrote: > Hi there, > > I've released the pre3 package of FlightGear Mac OS X at the macflightgear > site. > http://macflightgear.sourceforge.net > > Please check it out very quickly so I can have improve the quality of 2.0.0. > > Best, > > Tat > > p.s. > Many mac users who gave me emails in the past week: > Sorry for my very late reply. > I'll be replying one by one tonight. > > > -- > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Mac OS X pre3
Hi Tat, First of all, thanks for putting the OS X release together - great work. I have just been trying 2.0.0 pre 3, and have a few comments. Overall, just about everything works, and it is very stable. I am using OS X 10.4 on MacBook (Intel GMA 950 graphics chip set). I flew from KSFO, and went around SF Bay, flying the Seneca II. 1. Shaders: not working. The land mass and water reflection shaders showed strange textures. The fancy new clouds were partly right. They look good, but they are all the same shape, and are 2d. (I can post images if needed) 2. Atlas: did not run when selected in the launcher. (No problems here with 1.9.1) 3. Frame rates are about the same or a bit lower, but much lower when flying over KSFO. I think that might be the extra models in the scenery (there are a lot more electricity towers than in 1.9.1). 4. Cessna 172: this did not work on my machine in 1.9.1 (a crash somewhere in OSG), but does run in 2.0.0, although the frame rate is very low when looking from outside the plane. Something in the aircraft model perhaps? 5. Chase view: The chase view view point does not follow the airplane. The airplane stays in view, but the view point does not stay behind the aircraft, maintaining a constant direction of view (relative to ground rather than aircraft). Hope this is useful feedback. Cheers Andrew On 03/02/2010, at 11:53 AM, Tatsuhiro Nishioka wrote: > Hi there, > > I've released the pre3 package of FlightGear Mac OS X at the > macflightgear site. > http://macflightgear.sourceforge.net > > Please check it out very quickly so I can have improve the quality > of 2.0.0. > > Best, > > Tat > > p.s. > Many mac users who gave me emails in the past week: > Sorry for my very late reply. > I'll be replying one by one tonight. > > > -- > > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in > the business > Choose flexible plans and management services without long-term > contracts > Personal 24x7 support from experience hosting pros just a phone > call away. > http://p.sf.net/sfu/theplanet-com > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
