[Flightgear-devel] how to write XML files for scenery models
I want to create some scenery models which include some animation (comms tower with strobe light in this instance) in an XML file. Is there some documentation somewhere on just what to put in the XML file? I can cut and paste from other models, but knowing more about what can be done in XML would be good. Thanks Andrew -- 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] materials.xml request
Tim Moore wrote: On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman e...@ehofman.com wrote: Stuart Buchanan wrote: It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. Looks like that part is gone, at least the part where every random object in the scenery was in the same place every time you start up FlightGear. This used to be working at some point (and could be used for landmark navigation). I'm a bit confused. Are random objects actually starting up at different points in each run now? I haven't noticed that nor have I seen a report of that. All I've seen in this thread is that the code that resets the random generator in each tile (well, several times per tile) may be affecting the random distribution of some models. I managed to do a couple of test-flights to validate Erik's bug report without crashing my GPU. The problem appears to be limited to the case where there are multiple object path elements defined under the object node. In this case, the actual object placed at a given location varies from run to run. The effect can be quite subtle because the position of the object (and any trees) stay the same, and a lot of our object definitions only have a single path element so you often don't see the bug for large objects. From a code read I think the problem is that we don't actually define the specific path element to use in obj.cxx, but it gets selected later in SGMatModel::get_random_model(), which still uses sg_random() rather than the mt_rand(seed) code used elsewhere. This in turn is called by sgGetRandomModel(), which is called by SGLoadBTG(). So, I think the fix is for SGLoadBTG() to pass the seed generated at obj.cxx line 606 down through sgGetRandomModel() and for get_random_model() to use a call to mt_rand(seed) rather than sg_random() to determine the actual model to generate. The mt_rand code generates the same set of pseudo-random numbers across runs (and I believe computers) Apologies again that I can't fix this myself right now, but hopefully that should fix the problem in time for the release. -Stuart -- 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] materials.xml request
Stuart Buchanan wrote: I managed to do a couple of test-flights to validate Erik's bug report without crashing my GPU. The problem appears to be limited to the case where there are multiple object path elements defined under the object node. In this case, the actual object placed at a given location varies from run to run. The effect can be quite subtle because the position of the object (and any trees) stay the same, and a lot of our object definitions only have a single path element so you often don't see the bug for large objects. Indeed that was also my conclusion. 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] materials.xml request
On Mon, Feb 1, 2010 at 9:04 AM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: Tim Moore wrote: On Sun, Jan 31, 2010 at 8:07 PM, Erik Hofman e...@ehofman.com wrote: Stuart Buchanan wrote: It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. Looks like that part is gone, at least the part where every random object in the scenery was in the same place every time you start up FlightGear. This used to be working at some point (and could be used for landmark navigation). I'm a bit confused. Are random objects actually starting up at different points in each run now? I haven't noticed that nor have I seen a report of that. All I've seen in this thread is that the code that resets the random generator in each tile (well, several times per tile) may be affecting the random distribution of some models. I managed to do a couple of test-flights to validate Erik's bug report without crashing my GPU. The problem appears to be limited to the case where there are multiple object path elements defined under the object node. In this case, the actual object placed at a given location varies from run to run. The effect can be quite subtle because the position of the object (and any trees) stay the same, and a lot of our object definitions only have a single path element so you often don't see the bug for large objects. From a code read I think the problem is that we don't actually define the specific path element to use in obj.cxx, but it gets selected later in SGMatModel::get_random_model(), which still uses sg_random() rather than the mt_rand(seed) code used elsewhere. This in turn is called by sgGetRandomModel(), which is called by SGLoadBTG(). I was wondering about that while looking at the code last night. So, I think the fix is for SGLoadBTG() to pass the seed generated at obj.cxx line 606 down through sgGetRandomModel() and for get_random_model() to use a call to mt_rand(seed) rather than sg_random() to determine the actual model to generate. The mt_rand code generates the same set of pseudo-random numbers across runs (and I believe computers) Apologies again that I can't fix this myself right now, but hopefully that should fix the problem in time for the release. Since the bug is in model choice (not position), affects less than a third of the object definitions in materials.xml, and is being reported very late in our release process, I'm inclined to fix this in a 2.0.1 maintenance release. 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] materials.xml request
leee wrote: On Sunday 31 Jan 2010, Erik Hofman wrote: Stuart Buchanan wrote: It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. Looks like that part is gone, at least the part where every random object in the scenery was in the same place every time you start up FlightGear. This used to be working at some point (and could be used for landmark navigation). Erik It's a sad fact that much of which used to make FG extremely stable and consistant has been sacrificed to implement new features. Sorry folks, but all the new developments in FG, over the past few years, have come at the cost of stability and robustness. Codswallop :) This particular bug is in a feature that was introduced in post-plib, and is not a regression, as you seem to be implying. As I recall, the plib code didn't even attempt to make random object placement consistent across runs and I spent quite some time with help from a number of people in putting together something that provided that consistency. I remember the 0.9.8 and 0.9.9 releases all having issues, just as the 1.9.1b has and 2.0.0 releases will have. People have worked very hard to track down difficult bugs such as the NaN issue and to ensure consistency when enhancing FG (e.g. the sound system).. CVS has possibly become a little less stable, but I can't say that I've noticed, and my understanding is that the release team are working from a GIT branch of known-stable code to ensure that we've got a stable release. Sniping from the side-lines has absolutely no value unless you're prepared to roll up your sleeves, which you've stated you aren't. -Stuart -- 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] materials.xml request
Tim Moore wrote: Since the bug is in model choice (not position), affects less than a third of the object definitions in materials.xml, and is being reported very late in our release process, I'm inclined to fix this in a 2.0.1 maintenance release. Another way to fix it is to use a round-robin method instead of using random for model selection. This would probably be an easy fix. This method is also used for multiple scenery textures. 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] materials.xml request
Stuart Buchanan wrote: As I recall, the plib code didn't even attempt to make random object placement consistent across runs and I spent quite some time with help from a number of people in putting together something that provided that consistency. Actually FlightGear did this already for a very long time. I know because I started the discussion about it back then. 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] materials.xml request
Tim Moore wrote: Since the bug is in model choice (not position), affects less than a third of the object definitions in materials.xml, and is being reported very late in our release process, I'm inclined to fix this in a 2.0.1 maintenance release. As I'm out of the loop concerning the release date, and any plan for a follow-up maintenance release I'm more than happy to leave this to your judgement. -Stuart -- 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] materials.xml request
Erik Hofman wrote: Stuart Buchanan wrote: As I recall, the plib code didn't even attempt to make random object placement consistent across runs and I spent quite some time with help from a number of people in putting together something that provided that consistency. Actually FlightGear did this already for a very long time. I know because I started the discussion about it back then. looking at the code: mt_init(seed, unsigned(123)); Note that back then first I used a random seed of lat*36000+lon*100 (or vice versa) of the tile center as a seed, making each tile more random. 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] materials.xml request
Erik Hofman wrote: Tim Moore wrote: Since the bug is in model choice (not position), affects less than a third of the object definitions in materials.xml, and is being reported very late in our release process, I'm inclined to fix this in a 2.0.1 maintenance release. Another way to fix it is to use a round-robin method instead of using random for model selection. This would probably be an easy fix. This method is also used for multiple scenery textures. Alright, this is committed to CVS for now. It is tested and works reliably. After the release we could discuss if this is the right approach or using random would be better. 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] materials.xml request
Erik Hofman wrote: Another way to fix it is to use a round-robin method instead of using random for model selection. This would probably be an easy fix. This method is also used for multiple scenery textures. Alright, this is committed to CVS for now. It is tested and works reliably. After the release we could discuss if this is the right approach or using random would be better. Ok, this turn out not to be perfect; When starting at a different airport and then switching to KSFO (and probably when flying around for some time and returning to KSFO) you might find a different building at places then before. But at least that's consistent (also between sessions). 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] materials.xml request
Erik Hofman wrote: Erik Hofman wrote: Another way to fix it is to use a round-robin method instead of using random for model selection. This would probably be an easy fix. This method is also used for multiple scenery textures. Alright, this is committed to CVS for now. It is tested and works reliably. After the release we could discuss if this is the right approach or using random would be better. Ok, this turn out not to be perfect; When starting at a different airport and then switching to KSFO (and probably when flying around for some time and returning to KSFO) you might find a different building at places then before. But at least that's consistent (also between sessions). Thanks for sorting this out. I think the solution I proposed should resolve the remaining issues, and using lat/lon to inform the seeding process should create more pseudo-randomnes. I'll look into this in more detail once I have a working development machine. -Stuart -- 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] material animation still breaks pick highlights
On 01/31/2010 11:16 PM, Tim Moore wrote: On Thu, Jan 21, 2010 at 5:45 PM, dave perry skida...@mindspring.com mailto:skida...@mindspring.com wrote: Hi, I just added a pick object to a material animation so it would be illuminated when cockpit lighting is turned on. This pick object was highlighted as expected via ctrl-C before adding it to the material animation, but now even with the cockpit lighting off, the pick highlight no longer works. This is with yesterday's cvs. Is there an aircraft in CVS that exhibits this problem? Yes, the specific object referenced is the cabin door handle of the pa24-250. there are many objects in the pa24 that have this problem. E.g. all the switches, throttle, carb heat, prop control, and mixture. Thanks, Tim Dave P. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net mailto: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 -- 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] materials.xml request
Gene Buckle wrote: Here's a wild idea - once an object has been placed, why not record it's position in a configuration file? This _might_ work for 'normal' random objects since there are not too many objects, but will end up in a _very_ long list if you're trying to achieve the same results for a dense forest ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] error C5108 unknown semantics and C7011 implicit cast
Hi Tim, I never got any response, so I guess my email got lost. I am see a new error message with yesterday's cvs, so here is a new report with OSG_NOTIFY_LEVEL stepped up to DEBUG http://seahorseCorral.org/bugreport/fgfs-results.C172.KSFO.gz search for error yields 40 results: (25) : error C5108: unknown semantics FACE specified for gl_FrontFacing and now also 21 results for: (29) : warning C7011: implicit cast from vec4 to vec3 Tim Moore wrote: glLinkProgram FAILED Program infolog: Fragment info - (25) : error C5108: unknown semantics FACE specified for gl_FrontFacing Has anybody else seen this? Stewart What hardware? Linux 2.6.24, libc 2.7, gcc-4.2.3, windowmaker 0.92.0, glib 2.18.4 AMD Sempron 3000, Nvidia FX5200, driver 173.14.18 Stewart -- 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] error C5108 unknown semantics and C7011 implicit cast
On Mon, Feb 1, 2010 at 4:53 PM, S Andreason sandrea...@gmail.com wrote: Hi Tim, I never got any response, so I guess my email got lost. I am see a new error message with yesterday's cvs, so here is a new report with OSG_NOTIFY_LEVEL stepped up to DEBUG http://seahorseCorral.org/bugreport/fgfs-results.C172.KSFO.gz search for error yields 40 results: (25) : error C5108: unknown semantics FACE specified for gl_FrontFacing and now also 21 results for: (29) : warning C7011: implicit cast from vec4 to vec3 I've seen this reported recently on older ATI cards (on Macintosh). The workaround is to #ifdef out the code that looks like if (!gl_FrontFacing) n = -n; in Shaders/default.frag and Shaders/mat-anim.frag. I'll think about how to make this automatic for older hardware. Tim Tim Moore wrote: glLinkProgram FAILED Program infolog: Fragment info - (25) : error C5108: unknown semantics FACE specified for gl_FrontFacing Has anybody else seen this? Stewart What hardware? Linux 2.6.24, libc 2.7, gcc-4.2.3, windowmaker 0.92.0, glib 2.18.4 AMD Sempron 3000, Nvidia FX5200, driver 173.14.18 Stewart -- 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
[Flightgear-devel] Fwd: Threshold bug when using custom scenery enable
First email disappeared, so I'm sending again - Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct. KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint. KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct. KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected. Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks, Peter -- 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] error C5108 unknown semantics and C7011implicit cast
Tim Moore wrote: glLinkProgram FAILED Program infolog: Fragment info - (25) : error C5108: unknown semantics FACE specified for gl_FrontFacing Has anybody else seen this? Stewart What hardware? Linux 2.6.24, libc 2.7, gcc-4.2.3, windowmaker 0.92.0, glib 2.18.4 AMD Sempron 3000, Nvidia FX5200, driver 173.14.18 Stewart I also see the FACE error with Windows XP, Nvidia FX5200 driver 6.14.11.7519 Alan-- 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] Fwd: Threshold bug when using custom scenery enable
Hi, First email disappeared, so I'm sending again - Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here:http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct.KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint.KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct.KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected.Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks,Peter maybe this helps: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24424.html __ 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] Fwd: Threshold bug when using custom scenery enable
On Feb 1, 2010, at 12:25 PM, Heiko Schulz wrote: Hi, First email disappeared, so I'm sending again - Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here:http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct.KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint.KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct.KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected.Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks,Peter maybe this helps: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24424.html Thanks Heiko. In reading your link - It appears that Alex created a patch as stated here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24826.html But that was November, so perhaps the patch is not working or included in Tat's 2.0.0 pre1(273) ? The thread did not mention the tower viewpoint bug, which is also evident. Peter -- 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] FlightGear 2.0.0 release process: Update
Hi All, Here's just a quick update regarding the 2.0.0 release. The final release is really close now. We had planned to have a third release candidate by now, which we would promote to the final release within a few days from now, provided that no further showstopping bugs show up. We're currently having a few minor technical glitches to deal with, which has been delaying the roll up of this final release candidate. We're pretty close now, and I expect that the final glitches will be solved real soon now. Cheers, Durk -- 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] Fwd: Threshold bug when using custom scenery
Hi Peter, Peter Brown wrote: It appears that Alex created a patch as stated here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24826.html Let's pass archive links around ;-) As stated in: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg24701.html I think that touching the displaced threshold value is inappropriate, no matter from which end you're looking at it. I remember a _very_ old mailing list discussion which resulted in some small offset of just a few meters being added to the non-displaced threshold position in order to determine the startup position. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] materials.xml request
On Monday 01 Feb 2010, Stuart Buchanan wrote: leee wrote: On Sunday 31 Jan 2010, Erik Hofman wrote: Stuart Buchanan wrote: It's been a long time since I (re-)wrote the random object code for OSG, but my recollection is that we use the same random number seed when generating random model placements, to ensure that a building is in the same place on every computer. Looks like that part is gone, at least the part where every random object in the scenery was in the same place every time you start up FlightGear. This used to be working at some point (and could be used for landmark navigation). Erik It's a sad fact that much of which used to make FG extremely stable and consistant has been sacrificed to implement new features. Sorry folks, but all the new developments in FG, over the past few years, have come at the cost of stability and robustness. Codswallop :) This particular bug is in a feature that was introduced in post-plib, and is not a regression, as you seem to be implying. As I recall, the plib code didn't even attempt to make random object placement consistent across runs and I spent quite some time with help from a number of people in putting together something that provided that consistency. I remember the 0.9.8 and 0.9.9 releases all having issues, just as the 1.9.1b has and 2.0.0 releases will have. People have worked very hard to track down difficult bugs such as the NaN issue and to ensure consistency when enhancing FG (e.g. the sound system).. CVS has possibly become a little less stable, but I can't say that I've noticed, and my understanding is that the release team are working from a GIT branch of known-stable code to ensure that we've got a stable release. Sniping from the side-lines has absolutely no value unless you're prepared to roll up your sleeves, which you've stated you aren't. -Stuart In the past I was able to track down and fix a couple of minor code bugs, and add a couple of new filter types, but I simply don't have the C++ and OOP skills to delve more deeply into the code; it's not a question of not being prepared to roll up my sleeves but rather that to do so would just leave me standing around with cold arms. LeeE -- 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] Request for comments: Airport lighting
Hi! I've heard that there is need for ability to toggle certain runway lights on or off, depending on which runways are in use. I've done some tests with obj.cxx and GroundLightManager to group lights together and turn them on or off, and I think I have figured it out so that I could make the system work. BUT we need to have the information about which light belongs to which runway, so this would need some changes. I propose following: - Add 3 new property types to btg file format (http://wiki.flightgear.org/index.php/BTG_File_Format): 3: Grandparent node name (in light's case, this would be the ICAO code of the airport) 4: Parent node name (with lights this would be the runway code) 5: Direction, vector (could be used with directional runway and taxiway lights, if missing, assume point light) 3 and 4 would be strings of arbitrary length, and 5 could be 3 doubles, x, y and z. This way we could easily bind the lights to certain airport code and runway code, so they could be toggled on or off via easy properties. I also think that one light could have multiple parents, so opposite ends of runway would light up the same lights. I don't think this breaks compatibility with older versions of FG, since the .btg reader just discards unknown properties. I also have some questions about lighting in general: - Does the runway have same kind of lighting if it's used for takeoffs or landings? What about which end of the runway is used? - Can one runway have different sets of lights (simple, CATI, CATII, whatever they are?) - Are taxiway lights always on or do they depend on the runways being used? I also saw something interesting here, like the blinking runway guard lights, stop bar lights and lead-on lights. They should probably be taken into account for future versions. Link: http://www.caa.co.uk/docs/33/CAP637.PDF And an image from the forums showing current situation which may or may not be realistic: http://lh3.ggpht.com/_UQs70Ldx8uc/S2BAlMoiKqI/BEY/eWQaD5JufaI/fgfs-screen-007.png I'm glad to take any comments about this proposition, and if there are some things about the lights that should be taken into consideration. Sincerely, Lauri (Zan) -- Lauri Peltonen lauri.pelto...@gmail.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
[Flightgear-devel] Stencil Lighting
Hi All Lauri Peltonen (aka Zan) has produced a stencil shader which can be used to simulate the light cone of Taxi or Landing lights, or Floodlights for airport aprons. The possibilities are endless. I have put together a demo using the Buccaneer - some screenshots are here: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/lightcone11.jpg ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/lightcone12.jpg That's the good news - unfortunately, I cheated. There's some problem around the near/far camera changeover: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/lightcone10.jpg And as you can see, the light effect works quite well on terrain, but it floods other models with white. It also has hard edges, and no attenuation. I have applied a texture which helps a bit, but it is far from a realistic light. These aren't problems that look as if they will be solved short-term, if at all. Nevertheless, I think it's worth pursuing at least until we have light shaders available, so I have uploaded the shaders etc. to cvs-data. To complete the process, minor patches are required to FG and SG - here: ftp://ftp.abbeytheatre2.org.uk/fgfs/Light/ For those who want it an updated Windows binary including the stencil shader is at: ftp://ftp.abbeytheatre2.org.uk/fgfs/executable/ I don't think this code is sufficiently mature for inclusion in the upcoming release, but once that is complete, perhaps someone would apply the patches to cvs. Vivian -- 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] Stencil Lighting
Vivian, Thank you very much for all information. Very interesting! Best regards, Prestes 2010/2/1 Vivian Meazza vivian.mea...@lineone.net Hi All Lauri Peltonen (aka Zan) has produced a stencil shader which can be used to simulate the light cone of Taxi or Landing lights, or Floodlights for airport aprons. The possibilities are endless. I have put together a demo using the Buccaneer – some screenshots are here: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/lightcone11.jpg ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/lightcone12.jpg That’s the good news – unfortunately, I cheated. There’s some problem around the near/far camera changeover: ftp://ftp.abbeytheatre2.org.uk/fgfs/Screen-shots/lightcone10.jpg And as you can see, the light effect works quite well on terrain, but it floods other models with white. It also has hard edges, and no attenuation. I have applied a texture which helps a bit, but it is far from a realistic light. These aren’t problems that look as if they will be solved short-term, if at all. Nevertheless, I think it’s worth pursuing at least until we have light shaders available, so I have uploaded the shaders etc. to cvs-data. To complete the process, minor patches are required to FG and SG – here: ftp://ftp.abbeytheatre2.org.uk/fgfs/Light/ For those who want it an updated Windows binary including the stencil shader is at: ftp://ftp.abbeytheatre2.org.uk/fgfs/executable/ I don’t think this code is sufficiently mature for inclusion in the upcoming release, but once that is complete, perhaps someone would apply the patches to cvs. Vivian -- 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
[Flightgear-devel] Threshold bug when using custom scenery enable
Hey guys, I'm finding an issue using --prop:/sim/paths/use-custom-scenery-data=true Thresholds on a number of test airports are off by a large degree, and the tower viewpoint is an issue at some. When use-custom-scenery-data=false spawn locations and tower viewpoints are correct. Test photos are linked here: http://s512.photobucket.com/albums/t325/barefootr/Flightgear/Threshold%20Bug/ KSFO spawns you in the water off 28R. Tower viewpoint appears correct. KSLC appears to spawn same as normal, but tower viewpoint is far underground. Changing tower height in apt.dat file does not affect viewpoint. KBTV spawns off the end of runway 33, similar to KSFO. Tower viewpoint appears correct. KJFK spawns far off the end of 31L, and tower viewpoint is at zero (0) altitude. (Tower height is 320' in apt.dat, and shows correct when --prop:/sim/paths/use-custom-scenery-data=false) Oddly, other runway spawn locations appear to be unaffected. Issue has tested valid so far using: - Mac OS 10.6.2 (Snow Leopard) and Tat's 2.0.0-pre1(273) - Mac OS 10.4.11 and Tat's 2.0.0-pre1(273) Anyone know what's going on? Thanks, Peter-- 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] Fwd: Threshold bug when using custom scenery enable
If your using custom scenery , then it appears that tower info is read from Scenery/Airports/ ././. *.twr.xml -- 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
