Re: [Flightgear-devel] Re: Release of v0.9.9 source code
Josh Babcock wrote: Won't the FDM have to tell the sound system when the wheels are skidding? You can figure out touchdown pretty easily, but not say, skidding from braking. The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] publicity
Been lurking for a while now ... but here goes ... I am the owner of Aircraft.co.za, and I'm willing to do a complete review of FlightGear on my site ... If you have any specific features/aircraft/sceneries I should focus on, please tell me so I can include it in the review ... The site currently receives approx. 100,000 hits per month, so it should give some nice exposure ... Lemme know what you guys think ... Danie Heath -Original Message- From: [EMAIL PROTECTED] on behalf of Vassilii Khachaturov Sent: Tue 11/22/2005 10:16 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] publicity anyone feeling responsible for alerting major anouncement sites (such as happypenguin.org) about the new release? posted one on freshmeat yesterday. Somebody else welcome to announce on happypenguin and/or linuxgames. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d winmail.dat___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flightgear 0.9.9 RPMs for Fedora Core 2, 3, 4 on i386
Please help yourselves to my RPMs: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/RPMS/i386/FlightGear-0.9.9-0.FC.i386.rpm ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/RPMS/i386/openal-20050209-0.FC2.i386.rpm Ignore the 'FC2' suffix on the openal package: it should be fine for FC2 onwards. For the convenience of non-techie users (not that there are any using Fedora Core!) the Flightgear RPM adds a launcher to the 'Games' category of the Red Hat Start tool (bottom left of the screen). Yes, it probably should create a category called 'Simulators' and put the icon and launcher in there instead. However, I couldn't work out how to do that - if anyone knows how, please post and tell me. --- You don't need the 'devel' RPMs unless you plan building the SRPMs for flightgear. If you do want the SRPMs, they are in the directory: ftp://tallyho.bc.nu/pub/steve/flightgear/0.9.9/SRPMS/ (of course). Scenery RPMs (for the UK, Ireland and Faroe Islands) coming soon using the scheme I used for 0.9.8. Not to everyone's taste I know, but convenient if you like keeping your software under RPM's control. Steve. PS: Could someone mirror these RPMs somewhere please. They're currently hosted on rather a puny machine on a slow WAN. Thanks in advance. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Realistic daytime skycolor
Hello, first of all let me say that seeing the screenshots on your website just now (of version 0.9.9 I assume) , I'm very impressed, especially with the new clouds! I'm still using 0.9.6 (because it's the version coming with debian sarge) and was completely unaware of your progress. Keep up the good work. Anyway I'm working on a sort of free flightsim myself (nothing like flightgear though, more like what you would call a game) and have recently completed the implementation of the skycolor part of Preetham's paper A Practical Analytic Model for Daylight. It only yesterday dawned on me that such an implementation might be of interest to you folks since as far as I can tell from running 0.9.6 and screenshots and the feature list of 0.9.9 you're using some sort of simple gradient method for skycolor. The nice part about this model, is that it is parametric based on sun elevation and azimuth and sky turbidity. This will integrate nicely with your existing sky model which is also based on real time and weather conditions. The bad parts are the following: 1) It can't accurately model all atmosphere conditions. The paper says it's mostly suited for relatively clear or overcast skies and I've found it to fail for turbidities outside the range, say [1, 10] (depending also on sun position). By failure I mean weird sky colors like greenish etc. which might though be desirable in some situations (if you want to render a weird sky for example:). This I consider not so important though as, again judging from some, possibly old, screenshots, it should be more accurate than your skycolor model. 2) Assuming you want the sky to change in real time, some work may be required. Timing a run to create a sky texture of size 1024x512, I get less than a second on my machine (an atlhon 2000+). This is obviously too slow to run every frame but that would be overkill anyway. Running this say once per second would require just a millisecond per frame which should not be much of an overhead, but some way to run the model asynchronuously would be required. This should be easy to do if you want to run it for a few pixels per frame, which doesn't guarantee any strict time budget but still provides an effective way to trade temporal resolution for processing power. It should be a little harder to run it in a seperate thread or otherwise ensure that the routine runs for a few ms per frame and I don't think it would be worth the trouble. With all that said, I should note that a 1024x512 texture is too big anyway and you could probably get a way with half that size (and 4 times less computations; takes about 0.25 ms on my computer), with nice results and even less for slower computers. This of course can be adjustable. 3) This model is not meant to be used for nightskies. You'll have to use your current code for that. I want to implement somenthing nice for night scenes as well, but I need to make progress in other, more significant areas, like integrating jsbsim or some sort of cloud scheme in my project, before attempting that. I'm afraid I can't really spare the time right now to integrate this myself into flightgear. Or rather, since I consider this pretty straightforward I assume that most of the time I'd just be trying to find my way around the flightgear codebase which wouldn't be the case for some experienced flightgear developer. I have implementations in both octave and C and they're standalone programs creating ppm image files of the sky texture, not just ripped code from my own project. If you're using a textured skydome integrating this into flightgear should be 10 minutes worth of work (I know, it never actually takes 10 minutes but it shouldn't take too long anyway) for the static case and some more for the dynamic. If you're using vertex colors some adjustments would have to be made to sample the colors at the skydome vertex positions which should again be very easy (you might need a dense or adaptive tesselation of the dome to get good results in this case though; I'd recommend using textures instead). To wrap it up let me say that this is nothing big in terms of complexity, it's just 150 lines of code in C, but I believe, and you can judge for yourself from the screenshots below, that it will make the sky in flightgear quite nicer, especially in some conditions like sunset/rise. Well I think that's all, let me know if you're interested, Dimitris P. PS: Almost forgot. You can find a few sample outputs from the model and also a couple of screenshots from my own code (so that you can what it should look like when integrated into flightgear) here: http://hal.csd.auth.gr/~jimmyp/ There are a myriad other combinations of sunposition and atmosphere turbidity possible so this are, well, just samples. They should, though, show off the more essential features of the model, e.g. luminance and chromaticity variations based on
[Flightgear-devel] OT: picture of two USAF thuderbirds in mirror formation
Off topic, but something similar to this might make two interesting AI aircraft for around KSFO or KDCA or Nellis AFB, Nevada, USA where they're based. 8-) Best regards, Ima From netscape.com gallery: http://cdn-channels.netscape.com/gallery/i/p/popular112105/ apohcomrr_AVIATION_NATIO_1B.jpg The netscape.com/gallery caption reads: Two U.S. Air Force Thunderbirds perform a mirror formation during Aviation Nation Air Show at Nellis Air Force Base in Las Vegas on Saturday, Nov. 12, 2005. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS: data/Aircraft/b1900d ...
* Syd Adams: [...] Having some trouble with material animation ... it appears global material changes only affect objects that share the same texture file global doesn't only look at what ac3d files define in a MATERIAL entry, but at all material parameters, including the texture. It affects all objects that share the same ssgSimpleState. Every single difference requires us to clone the ssgSimpleState node, and then the connection between such objects is lost. You just have to do what you do in all other animations then: list all objects in object-name tags. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Ampere K. Hardraade wrote: \ Finally, here is a thought that has been floating in my mind for a while, and I hope you could try it out: take some stereoscopic views of aircrafts. Having some stereoscopic photographs of an aircraft may help modellers make estimations better. (Okay, this is just a theory, but this would be a good opportunity to vertify my theory with an experiment.) :P Ampere Good theory, I'll have to test it if I get the chance. Unfortunately I can only make the pics, I don't have stereo capable hardware right now. I was also thinking that this community must have a treasure trove of airshow pics. Obviously most people won't want to put them up on airliners.net, but maybe we could have some sort of forum where we can post wanted ads and lists of planes we have pics of. Or we could just make a habit of being considerate like Innis and posting on the devel list :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Searching for TerraGear-Bug-Hunters
Hi all, about two weeks ago Curt started preparations for a scenery regeneration run using the new shapefile data from Martin Spott's Terrain Data Database. In order to be able to accept custom scenery modifications to the standard scenery we need to get this part working. This is what he reported to me: I haven't had a chance to dig into this yet (and I'm not sure I will today) but when processing the rivers_stream database, it reports 760648 records. However, the process quit peacefully after processing only about 72000 records (i.e. 10% of the reported number of records). Any ideas. I didn't see any sort of segfault/coredump type message. I was unable to reproduce the problem up to now and we're kinda stuck. I'm therefore searching for helpers who can get TerraGear running on their system and try to reproduce the bug. You can use src/Prep/ShapeFile/process.sh for this. Download the shapefiles ftp://ftp.ihg.uni-duisburg.de/FlightGear/TGShapes/rivers_stream.tar.bz2 and optionally ftp://ftp.ihg.uni-duisburg.de/FlightGear/TGShapes/landmass_default.tar.bz2 and untar them into a new directory. Change process.sh to have SHAPEBASE point at these shapefiles and WORKBASE at a place where you want to put the results. Try it only with rivers_stream.tar.bz2 for starters, but I'm not sure whether the previous instance of shapedecode (decoding landmass) already mixes up the working directory, which could cause the crashes as well. WARNING: This test run will take many GBs of your free disk space. The last time I tried, I wasn't yet at the 72000 records mark and my disk was full (previously 5GB free). So far we found out that the polygons for lines touching the date line (180 deg longitude E/W) get mixed up, as the widened polygons for these lines cross the date line. However, we were not able to find out whether this has anything to do with the crash/termination Curt described. So far Curt saw it crash on these records: 72447, 194774, 196576 Thanks in advance. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Erik Hofman wrote: The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Yeah, but just putting them on doesn't make them skid (I hope). Hearing screeching wheels when you tap your brakes during a slow speed taxi would be a bit silly. You would need to know at least the force from the wheels and the coefficient of friction for the current conditions. The latter I suppose you could make a good educated guess at based on the weather. Ground speed is a very useful thing to have, especially on a by-wheel basis. It allows for very good looking wheel rolling animations during taxi turns. Andy put this into YASim a while back, and it makes the B29 wheels look just plain hot. (my only small complaint is that they don't spin down after takeoff, so if you forget to tap your brakes after takeoff, the wheels will still be spinning when you lower you gear for landing!) If the ground speed where to reflect the wheels locking up that would be even cooler, but it still won't tell you when the wheels are skidding sideways enough to cause a screech. This is something that you probably want if you are ever planning on doing a ground loop, and I tend to do a lot of those in FG ;) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] tiny ch47 patch
This must be one of the lesser flewn models in FG. Two years has passed since the last patch, and noone has noticed that Erik forgot (tsk tsk) that there are /two/ rotors on the Chinook. Make also the other rotor (collective) work the same way as the first rotor. (and same as bo105, i.e. zero throttle on the joystick throttle axis means full lift). --- ch47.xml2005-11-22 15:48:16.0 +0100 +++ ch47.xml.new2005-11-22 15:55:31.0 +0100 @@ -74,9 +74,9 @@ src0=-1.0 src1=1.0 dst0=-0.3 dst1=0.3/ control-input axis=/controls/engines/engine[1]/throttle control=COLLECTIVE src0=-0.0 src1=1.0 - dst0=-1.0 dst1=1.0/ + dst0=1.0 dst1=-1.0/ control-input axis=/controls/engines/engine[0]/magnetos control=ROTORENGINEON/ /rotor ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Josh Babcock wrote: Erik Hofman wrote: The FDM already reveals when the brakes are applied in the property tree. One thing that still is missing (and I have a solution for the next JSBSim release) is a ground-speed property. Yeah, but just putting them on doesn't make them skid (I hope). Hearing screeching wheels when you tap your brakes during a slow speed taxi would be a bit silly. You would need to know at least the force from the wheels and the coefficient of friction for the current conditions. The latter I suppose you could make a good educated guess at based on the weather. So far I've done pretty well for touchdown skis sounds, I don't think ground loop squeels would be much more difficult. Did you take a look at the c172p-sound.xml configuration file already? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: tiny ch47 patch
* Joacim Persson -- Tuesday 22 November 2005 16:19: This must be one of the lesser flewn models in FG. Two years has passed since the last patch, and noone has noticed that Erik forgot (tsk tsk) that there are /two/ rotors on the Chinook. Could well have been my patch, not Erik's. All helicopters other than the bo105 are unmaintained, broken, and have no model. These are models that should be moved to the Attic/, or at least be removed from the download page. They serve no other purpose than to fool annoy users, and to make fgfs look bad. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Dimitris Papavasiliou wrote: Anyway I'm working on a sort of free flightsim myself (nothing like flightgear though, more like what you would call a game) and have recently completed the implementation of the skycolor part of Preetham's paper A Practical Analytic Model for Daylight. It only yesterday dawned on me that such an implementation might be of interest to you folks since as far as I can tell from running 0.9.6 and screenshots and the feature list of 0.9.9 you're using some sort of simple gradient method for skycolor. The nice part about this model, is that it is parametric based on sun elevation and azimuth and sky turbidity. This will integrate nicely with your existing sky model which is also based on real time and weather conditions. The bad parts are the following: The skylight model we are using is also based on physical properties and isn't far off from the model you describe. That model however doesn't allow for some of the cloud colorings features we are doing. In fact our model still has a lot of potential left. I wouldn't want to trade it for another approach. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
On Tue, 22 Nov 2005, Josh Babcock wrote: Ampere K. Hardraade wrote: Having some stereoscopic photographs of an aircraft may help modellers make estimations better. (Okay, this is just a theory, but this would be a good opportunity to vertify my theory with an experiment.) :P Good theory, I'll have to test it if I get the chance. Unfortunately I can only make the pics, I don't have stereo capable hardware right now. How about simply taking photos from various angles, but document the exact position from which each photo is taken? From that it should be possible to calculate the position for a number of points with (hopefully) fairly good precision. If the photographing method is standardised, it could even be possible to write a script for the calculations. Like snaps taken 30° apart from a defined distance. Identify the same spot on the craft in two or more pictures etc... Use the same lens for all photographs. Take also a photo of a grid so you know where you have the angles in pictures taken with that setting. The high-tech method would be using a laser scanner. ;)___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
On Tuesday 22 November 2005 15:41, Erik Hofman wrote: The skylight model we are using is also based on physical properties and isn't far off from the model you describe. That model however doesn't allow for some of the cloud colorings features we are doing. Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg In fact our model still has a lot of potential left. I wouldn't want to trade it for another approach. I don't know anything about the theory of it all, but I do know that the sky in FG looks truly amazing at dawn and dusk in particular (colours, moon phases, star positions etc) - and I think we are _really_ underselling FG by not having a few screenshots illustrating that on the website. I'm sure others can come up with much nicer ones than I have... they're all going to offend the darkness police whatever :-) Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Am Dienstag 22 November 2005 17:06 schrieb AJ MacLeod: On Tuesday 22 November 2005 15:41, Erik Hofman wrote: The skylight model we are using is also based on physical properties and isn't far off from the model you describe. That model however doesn't allow for some of the cloud colorings features we are doing. Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg In fact our model still has a lot of potential left. I wouldn't want to trade it for another approach. I don't know anything about the theory of it all, but I do know that the sky in FG looks truly amazing at dawn and dusk in particular (colours, moon phases, star positions etc) - and I think we are _really_ underselling FG by not having a few screenshots illustrating that on the website. I'm sure others can come up with much nicer ones than I have... they're all going to offend the darkness police whatever :-) I think Melchior knows how to swap textures/materials at runtime. Probably it's time for fake lighted livery... In a Berlin building in Jon's Scenery Objects DB (Park Inn Hotel), I used a light emitting material together with a night texture (basically to darken the shadow areas) to fake an illuminated facade. Maybe this technique can also be applied to the stabilizer to light the company logo. I'm sure this would improve your scene enough to pass Curt's artistic judgement. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg [snip] I don't know anything about the theory of it all, but I do know that the sky in FG looks truly amazing at dawn and dusk in particular (colours, moon phases, star positions etc) - and I think we are _really_ underselling FG by not having a few screenshots illustrating that on the website. Agreed 100%. I'm sure others can come up with much nicer ones than I have... they're all going to offend the darkness police whatever :-) A trivial solution comes to mind --- create a decent out-of-cockpit screenshot facing a scene like that. Your particular image would offend not just the darkness police but the FAA as well for not sporting the exterior aircraft lighting when it should be on! V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Vassilii Khachaturov wrote: Not being an aircraft modeller myself, I don't know exactly what's needed; but those with specific requirements could also try posting in the rec.aviation.* newsgroups (the .piloting and .simulators come to mind), and folks out there will probably respond. Google before you go, because somebody ahead of you on these newsgroup may have posted the very info you're looking for. BTW, there hasn't been an announcement of the 0.9.9 in the rec.aviation.simulators, so one can probably do the 2 things at one go. Yeah, a while back I stopped posting me email address on usenet news. It gets into the web archives, goes all over the internet and the world, and pretty soon you are back to measure your spam in messages per second ... :-( But if anyone else is feeling brave, be my guest. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Vassilii Khachaturov wrote: Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg [snip] I don't know anything about the theory of it all, but I do know that the sky in FG looks truly amazing at dawn and dusk in particular (colours, moon phases, star positions etc) - and I think we are _really_ underselling FG by not having a few screenshots illustrating that on the website. Agreed 100%. I'm sure others can come up with much nicer ones than I have... they're all going to offend the darkness police whatever :-) A trivial solution comes to mind --- create a decent out-of-cockpit screenshot facing a scene like that. Your particular image would offend not just the darkness police but the FAA as well for not sporting the exterior aircraft lighting when it should be on! I forget who posted this original 'dark' screen shot, but here's the issue, due to gamma differences, this image comes out completely black on my screen. From that standpoint, it's not a useful screen shot. Many people that download it are going to say, huh! This isn't an easy problem to circumvent because there is a wide swath of gamma configurations and monitors out there. But in this case, we simply need something with more light to make it widely useable. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Yeah, a while back I stopped posting me email address on usenet news. It gets into the web archives, goes all over the internet and the world, and pretty soon you are back to measure your spam in messages per second ... :-( I'm proudly posting my email address on the webpages and never changed it. All I needed to do is tweak my spam-processing software, and periodically upgrade it (I stick to spambouncer + a couple of handwritten procmail recipes). In the inbox and the dedicated bulk mail inbox for the subscribed lists I don't get any spam. In the block folder, I get most always spam, and occasionally (within 5 times a month) an email from a clueless someone using a generic free email and posting in HTML with their ads image embedded. Whatever is tagged as virus or spam, is always safe to throw. BTW, i'd like to express the gratitude to the list master(s) at this time (Curt, that's you, right?) for no spam in our list. But if anyone else is feeling brave, be my guest. I'm brave enough as I have said, but I am not a modeller. If somebody posts a detailed announcement+request for information here, I'll be happy to forward it on to the r.a.simulators and/or .piloting on the behalf of the fgfs devel team, of which I am a happy junior member :-) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Josh Babcock wrote: I was also thinking that this community must have a treasure trove of airshow pics. Obviously most people won't want to put them up on airliners.net, but maybe we could have some sort of forum where we can post wanted ads and lists of planes we have pics of. Or we could just make a habit of being considerate like Innis and posting on the devel list :) You'll find most of my airshow and museum pics here: http://photos.stockill.org/g45.html There may be others scattered around that site. If people need somewhere to put pictures online then www.fotopic.net will give you 250MB of space to host them (disclaimer: I'm biased - this is where I work). I know the museum at Doncaster has a large number of aircraft, and cockpit sections on display (there's a list here: http://www.aeroventure.org.uk/mainexhibits.php ). If there are any that people are particularly interested in then if you can tell me what you want photos of, or what you need measuring then I can try to get you the info you need when I'm next there. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Invisible panel on C310
Buchanan, Stuart wrote: Hi All, I've been trying to change the panel on the civilian (non-u3a) C310 model. However, I keep hitting a problem where the bulkhead behind the panel (part of the .ac file) is being rendered on-top of the panel, even if the panel is placed right up at the view-point. I think this is the reason why the c310-dpm-3d aircraft doesn't seem to have any instrumentation. Strangely, I can see the panel through the yoke and pedals of the model, but I think that may be due to a texture problem. Does anyone have a pointer as to what is going on? I was hoping to get a decent 3-D panel for the 310, but this has me stumped. If it is any help, the bulkhead seems to be part of the cabin object, so I wonder if FG is rendering it last because part of it is closer to the viewpoint ? Regards, -Stuart I think you are talking about a 2.5D panel. You have a draw order problem between your transparent part, the non transparent ones and the panel. Usually planes using a 2.5D panel are using a texture with an alpha channel to fool ssg so that all the plane is drawn after the panel. Or check the c150 if you don't want to use an alpha channel. I used depth-test = true in the panel tag and an animation to change the rendering order of the panel. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RenderTexture bug
Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Quoting Erik Hofman : Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik, search the string '_vsnSG_LOG' in rendertexture.cpp -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: picture of two USAF thuderbirds in mirror formation
On Tue, 22 Nov 2005 07:49:16 -0500, Ima wrote in message [EMAIL PROTECTED]: Off topic, but something similar to this might make two interesting AI aircraft for around KSFO or KDCA or Nellis AFB, Nevada, USA where they're based. 8-) Best regards, Ima From netscape.com gallery: http://cdn-channels.netscape.com/gallery/i/p/popular112105/apohcomrr _AVIATION_NATIO_1B.jpg ..heh, reminds me of a couple of my buddies, they flew 2 Curare-20's on 25 or 40 power AFAIR, training for some air show, F3A mirror style. Worked all nicely until that last big nice lazy loop. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Erik Hofman wrote: I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Yes, but I won't see 'my' PeeCee, the one at my customers location that's equipped with an r200 board, before thursday, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Erik Hofman wrote: The skylight model we are using is also based on physical properties and isn't far off from the model you describe. That model however doesn't allow for some of the cloud colorings features we are doing. In fact our model still has a lot of potential left. I wouldn't want to trade it for another approach. Erik Hmmm, on closer inspection it doesn't seem to be a simple gradient indeed. Does the color depend on the weather (that is turbidity) as well? Also bear in mind that the paper also describes a way to calculate sunlight color based on sun position and other parameters, in case that's what you need for cloud coloring. Still I suppose it was naive of me to assume that something like the sky model would be not interconnected with other parts of the code in a project like flightgear and thus easy to replace. Dimitris ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Frederic Bouvier wrote: search the string '_vsnSG_LOG' in rendertexture.cpp In case you missed the CVS log message; this is fixed now. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Dimitris Papavasiliou wrote: Hmmm, on closer inspection it doesn't seem to be a simple gradient indeed. Does the color depend on the weather (that is turbidity) as well? Yes. Also bear in mind that the paper also describes a way to calculate sunlight color based on sun position and other parameters, in case that's what you need for cloud coloring. Still I suppose it was naive of me to assume that something like the sky model would be not interconnected with other parts of the code in a project like flightgear and thus easy to replace. I think we all made that mistake at least once. :-) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Request to the Mac folk
Hi guys, Are there any Mac developers here who might be able to make up a Mac package of TaxiDraw v0.32 for me? The last version was done an X-Plane user, but there is no Mac binary available for the current version, and the Mac is popular among X-Plane users. TaxiDraw source can be found at http://taxidraw.sf.net There should be very few code tweaks needed (I *think* I got most of the patches required for the last version into the code), but a non-unicode version of wxWidgets is needed for compilation (the next version of TaxiDraw should be unicode-safe). If anyone is able to do this, TIA. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Two issues/question
I am not sure of the status of each of these. I am using the release code of 0.9.9 on a Mac 10.4 gcc 4.0.1. 1) If I fly out of an airport that is located out of the included sample scenery, then at the command line I get: Failed to open file repeated twice. I am using 0.9.8 scenery in that case, because that is all that is available. But there is no indication of what files are not opening, or what the problem is. Is there a difference between the 0.9.8 and 0.9.9 scenery and thus this is just a bug that will go away when the new scenery build is complete? 2) If I start with --enable-clouds3d then I just don't get any of the low level clouds to show up at all. In other words, without that feature, I get clouds at 5,000 feet, but with that flag I don't get any, but I don't see any errors either. I know that a while ago 3-d clouds were broken on the Mac. Are 3d clouds now working? Does it depend on the specific video card? If they don't work, should they at least fail back to the 2d clouds that do work fine? --Adam ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 22 Nov 2005, at 23:50, David Luff wrote:Are there any Mac developers here who might be able to make up a Mac package of TaxiDraw v0.32 for me? The last version was done an X-Plane user, but there is no Mac binary available for the current version, and the Mac is popular among X-Plane users. TaxiDraw source can be found at http://taxidraw.sf.net There should be very few code tweaks needed (I *think* I got most of the patches required for the last version into the code), but a non-unicode version of wxWidgets is needed for compilation (the next version of TaxiDraw should be unicode-safe). I built a binary that ran last year, haven't tried in ages - the issue is getting everything required linked statically, I think. I shall experiment, but don't let that stop any other Mac people having a go.HHJames___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear CVS error SG_LOG Cygwin
Hi, with the newest SimGear CVS I get this compiling error (Cygwin, gcc 3.4.4): RenderTexture.cpp:1595:44: macro SG_LOG passed 4 arguments, but takes just 3 RenderTexture.cpp: In member function `void RenderTexture::_ParseModeString(const char*, std::vectorint, std::allocatorint , std::vectorint, std::allocatorint )': RenderTexture.cpp:1592: error: `SG_LOG' undeclared (first use this function) RenderTexture.cpp:1592: error: (Each undeclared identifier is reported only once for each function it appears in.) RenderTexture.cpp:1642:72: macro SG_LOG passed 4 arguments, but takes just 3 make[3]: *** [RenderTexture.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all] Error 2 make: *** [all-recursive] Error 1 Anyone else with this problem? Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: 回复： [Flightgear-devel] thesis?
Is water shader about making the water look better? Right now I don't now how much work would be the integration and what it is about. Do you think it is a good topic for a thesis? Szabi On 22/11/05, Dai Qiang [EMAIL PROTECTED] wrote: Hi Berecz, It's good to hear that another person has selected FGFS as thesis topic. The things on my to-do list is to add water shader and integrate Mathius' work of carrier taking off and landing with current SimGear CVS. Maybe we can cooperate on the issues. Best, - Qiang --- Szabolcs Berecz [EMAIL PROTECTED]写道: Hi! I'm thinking about my thesis which I have to write next semester. I'm interested in FlightGear, but haven't got the time to dig into it, yet, so I don't know what needs to be done. Is there something which should be done, but you don't have the time for it? Maybe I would be willing to do it, but it shouldn't be too big, because I have to write most of it in a couple of months. It shouldn't be too easy, either. Do I want too much? :) Oh, and usually I'm not too interested in user interfaces and graphics, but I don't say there is no chance to work on something like that... I will have time to go into details and start working on something the next week. I would appreciate if you could suggest something. Thanks, Szabi ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 http://cn.mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 22 Nov 2005, at 23:17, James Turner wrote:I built a binary that ran last year, haven't tried in ages - the issue is getting everything required linked statically, I think. I shall experiment, but don't let that stop any other Mac people having a go.Okay, so building it was pretty painless (mostly because wxMac almost works out of the box these days; I had to create a few symlinks to get it to link, but anyway). I have a static taxidraw binary, which should work on Tiger (10.4), but probably not on anything earlier, I'll try Panther at work tomorrow.And now the bad news - when I point TD at my (CVS) apt.dat (unzipped), and do 'New...', I enter an ICAO code (say, EGPH), and crash. The crash is consistent at line 48 of fgfsIO.cpp: looking at the code it seems like a string-pointer issue. Is this a Mac-specific problem? I can dig deeper, but some guidance would be good.Alternatively, I can just upload what I have someplace and people can try - perhaps X-Plane data files would work.HHJames -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 23 Nov 2005, at 00:23, James Turner wrote:And now the bad news - when I point TD at my (CVS) apt.dat (unzipped), and do 'New...', I enter an ICAO code (say, EGPH), and crash. The crash is consistent at line 48 of fgfsIO.cpp: looking at the code it seems like a string-pointer issue. Is this a Mac-specific problem? I can dig deeper, but some guidance would be good.Alternatively, I can just upload what I have someplace and people can try - perhaps X-Plane data files would work.Disregard this, using the current X-Plane data everything works. It's my fault for not reading the instructions. Will test some more (and, err, get some sleep) and post a link to a .dmg once I verify what happens on Panther.BTW, David, you should really investigate using a config.h - your compile lines are, uh, rather long :)HHJames -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Wheel skid sounds - Was: [Flightgear-devel] Re: Release of v0.9.9 source code
Erik Hofman wrote: So far I've done pretty well for touchdown skis sounds, I don't think ground loop squeels would be much more difficult. Did you take a look at the c172p-sound.xml configuration file already? Erik Erik, No, I was responding based entirely on the e-mails. I did just take a peek, and it seems like a neat way of making the touchdown squeal if I am reading it right. What is the dt_stop section about though? If you can make squeals for over braking (locking the wheels) and ground loops without any modifications to the code, I will be interested in seeing it, and will definitely use it. This might be a good bit to include in the generic sound.xml file. Out of curiosity, do blowouts produce a squealing sound? I would think not, but I have never experienced one in a plane :) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thesis?
Szabolcs Berecz schrieb: Hi! I'm thinking about my thesis which I have to write next semester. I'm interested in FlightGear, but haven't got the time to dig into it, yet, so I don't know what needs to be done. Is there something which should be done, but you don't have the time for it? Maybe I would be willing to do it, but it shouldn't be too big, because I have to write most of it in a couple of months. It shouldn't be too easy, either. Do I want too much? :) Oh, and usually I'm not too interested in user interfaces and graphics, but I don't say there is no chance to work on something like that... I will have time to go into details and start working on something the next week. I would appreciate if you could suggest something. Thanks, Szabi ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Hi Szabi, I am only a user and not a developer (and can't therefore of no big help for you when you realize your project) but I want to make a suggestion: At the moment it is not very comfortable to place an object into the FlightGear world. First you have to calculate the tile-number via a separate Perl script (Lat/Lon - tilenumber), then you have to get the right elevation of that place, then you have to think about the angle you want to place the object into the world, then you have to create the *.stg file and write the things into it (or add them). All without any visual control and without the possibility to place a complete set of normally single objects into the scenery at one time. I am inspired by the FLY! object editor and as this always has been created for another (old) flightsim it might collide with what you have to do for your students work, but anyway I want to describe how it works in FLY: You fire the sim, fly/go to the place where you want to put your object/set of objects, press a key-combination. Then you see the scenery from above (bird-view) with a cross-marker (it aims to the point where the object is placed if you want to do so). You can go nearer of farer, to all directions (and even angles) to view the scenery. Then you select an object from a menue (grafical view) and place it into the scenery. You can now move it to the place you want to have it, select the height if other than ground (ie an object you want to place into the air or onto an already existing object), then you may safe your work. (In FLY! it is even more comfortable as you can select *every* object already placed in the scenery, move, scale and put it together, but I think this might a little bit too complicated for a several months work :-) ) When the object is safed, your code should make all calculations, changes or creations of new files - and if it is possible, make an initialisation of the scenery if you go out of the editing mode into normal flight mode, so that the new object is placed in the virtual world and can be seen. An add-on could be a little program outside of FlightGear where you can place several single objects into a fixed set which can be placed into the scenery by your new object-edit-code as described above. (This might be a collection of houses, trees, cars, etc to build some sort of a small generic village, or all other sort of small sceneries (small harbour, power plant, etc) which you want to place more than once into FlightGear. Ok, this was just my thought what could be done by you if interested. Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
回复： Re: 回复： [Flightgear-de vel] thesis?
--- Szabolcs Berecz [EMAIL PROTECTED]写道: Is water shader about making the water look better? Yeah, the water would look like this after adding the shader: http://www.openscenegraph.org/osgwiki/uploads/Screenshots/pirates-2005-06-01-07.jpg Right now I don't now how much work would be the integration and what it is about. Do you think it is a good topic for a thesis? Well, I don't know much about it either, coz I haven't started it yet, I'm helping my supervisor with other projects at the moment. You can post a letter in the mailing list to ask for more information. Szabi On 22/11/05, Dai Qiang [EMAIL PROTECTED] wrote: Hi Berecz, It's good to hear that another person has selected FGFS as thesis topic. The things on my to-do list is to add water shader and integrate Mathius' work of carrier taking off and landing with current SimGear CVS. Maybe we can cooperate on the issues. Best, - Qiang --- Szabolcs Berecz [EMAIL PROTECTED]写道: Hi! I'm thinking about my thesis which I have to write next semester. I'm interested in FlightGear, but haven't got the time to dig into it, yet, so I don't know what needs to be done. Is there something which should be done, but you don't have the time for it? Maybe I would be willing to do it, but it shouldn't be too big, because I have to write most of it in a couple of months. It shouldn't be too easy, either. Do I want too much? :) Oh, and usually I'm not too interested in user interfaces and graphics, but I don't say there is no chance to work on something like that... I will have time to go into details and start working on something the next week. I would appreciate if you could suggest something. Thanks, Szabi ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 http://cn.mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ 雅虎免费G邮箱－No.1的防毒防垃圾超大邮箱 http://cn.mail.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] material animation...
* Syd Adams: [...] Having some trouble with material animation ... it appears global material changes only affect objects that share the same texture file global doesn't only look at what ac3d files define in a "MATERIAL" entry, but at all material parameters, including the texture. It affects all objects that share the same ssgSimpleState. Every single difference requires us to clone the ssgSimpleState node, and then the connection between such objects is lost. You just have to do what you do in all other animations then: list all objects in object-name tags. m. If I understand you correctly , I need to list all objects that the animation applies to ? I was doing this before , (without global ) and everything worked fine ... but in the documentation it says using an object and global affects all objects that share that material, that is was a faster and preferred method. Unless I misunderstood the documentation , or you :) Still trying to figure out how to do the exhaust blur I saw from the Hunter, and trying to find out where this 'chrome ' effect is I heard about a week or so ago... Thanks for the tip, m . Cheers ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thesis?
On November 21, 2005 09:47 pm, Szabolcs Berecz wrote: Oh, and usually I'm not too interested in user interfaces and graphics, but I don't say there is no chance to work on something like that... I will have time to go into details and start working on something the next week. I would appreciate if you could suggest something. Thanks, Szabi Algorithm related: Interpetating, storing, altering and displaying accurate GIS data in WGS84 Coordinate System. (www.terragera.org) AI related: Application of artificial intelligent in civilian aviation, and experimentation of AI ATC within FlightGear Flight Simulator. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 22, 2005 01:06 pm, Erik Hofman wrote: Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik I do. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
On November 22, 2005 10:51 am, Joacim Persson wrote: How about simply taking photos from various angles, but document the exact position from which each photo is taken? From that it should be possible to calculate the position for a number of points with (hopefully) fairly good precision. I don't see how that's going to work unless one has a fisheye lense and is able to take pictures with exactly 180 degrees view. If the photographing method is standardised, it could even be possible to write a script for the calculations. Like snaps taken 30° apart from a defined distance. Identify the same spot on the craft in two or more pictures etc... Use the same lens for all photographs. Take also a photo of a grid so you know where you have the angles in pictures taken with that setting. The high-tech method would be using a laser scanner. ;) Laser huh? Last year, some people in the upper year in my faculty made a device called Geopod. It can measure the range and angle for points on a building. It has a fish eye lens at the top, which is tied to a digital camera, as well as a mirror and a laser range finder at the bottom. Using a labtop connected to the device, one can specify points on the photograph taken by the digitial camera for measurment, and the mirror will rotate to allow the laser range finder to calculate the range of the points. Using the data gathered, one can reconstruct the building (or a room) in a computer. It is not exactly a high tech device, but the components used to build it are darn expensive. Beside, I doubt one can bring such a device to an airshow without arousing suspicion. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Speaking of sky and color, I think FlightGear could use more blue in its ambient light source. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. thanks, cheers -E Erik Hofman wrote: Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Enrique Vaamonde wrote: Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. The fact that the crash is inside the ati driver makes me just a little suspicious of a driver bug. What would be possibly useful is to see the lines further along in the backtrace so we can see where in the flightgear/simgear code the crash happen. Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thesis?
On 23/11/05, Ampere K. Hardraade [EMAIL PROTECTED] wrote: Algorithm related: Interpetating, storing, altering and displaying accurate GIS data in WGS84 Coordinate System. (www.terragera.org) Sounds interesting. I will think about it... AI related: Application of artificial intelligent in civilian aviation, and experimentation of AI ATC within FlightGear Flight Simulator. Sounds more interesting :) I suppose ATC is functional in FlighGear. I will look up these things in two or three weeks. If you have any other suggestions, let me know, please. Szabi ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Hi Curt, as a matter of fact, the last line of the bt is this: #24939 0xafc88a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so (gdb) ...after that it's all empty...any clues? am I missing something? thank you :) -E Curtis L. Olson wrote: Enrique Vaamonde wrote: Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. The fact that the crash is inside the ati driver makes me just a little suspicious of a driver bug. What would be possibly useful is to see the lines further along in the backtrace so we can see where in the flightgear/simgear code the crash happen. Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Enrique Vaamonde wrote: Hi Curt, as a matter of fact, the last line of the bt is this: #24939 0xafc88a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so (gdb) ...after that it's all empty...any clues? am I missing something? thank you :) There are situations where gdb barfs and says nothing useful. Not to pick on gdb ... I've never got the borland debugger to tell me anything useful after any crash, but that's a different story. Tracking down the specific spot of a crash can sometimes be easy (if gdb plays along) or can turn into an art form if the easy tricks fail ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Hi Curt, disregard the last message, I must have screwed up somewhere... anyway...here's the bt after the ATI driver errors: #87344 0x08418821 in ssgVtxTable::draw_geometry (this=0xecd8ba8) at ssgVtxTable.cxx:635 #87345 0x08417fe9 in ssgVtxTable::draw (this=0xecd8ba8) at ssgVtxTable.cxx:560 #87346 0x08405a1b in ssgSelector::cull (this=0xebd9bb0, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgSelector.cxx:73 #87347 0x0840feea in ssgRangeSelector::cull (this=0xebd9a98, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgRangeSelector.cxx:92 #87348 0x0840deb7 in ssgTransform::cull (this=0xebdc4d0, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgTransform.cxx:83 #87349 0x083f8230 in ssgBranch::cull (this=0xa719b18, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgBranch.cxx:276 #87350 0x083fa22b in ssgContext::cull (this=0x1bfc, r=0x0) at ssgContext.cxx:260 #87351 0x083f6102 in ssgCullAndDraw (r=0xa719b18) at ssg.cxx:303 #87352 0x08056ca8 in FGRenderer::update (refresh_camera_settings=true) at renderer.cxx:673 #87353 0x08054b7d in FGRenderer::update () at renderer.hxx:34 #87354 0x08081cc1 in GLUTdraw () at fg_os.cxx:118 #87355 0xb7f70884 in glutJoystickGetCenter () from /usr/lib/libglut.so.3 #87356 0xb7f74478 in fgEnumWindows () from /usr/lib/libglut.so.3 #87357 0xb7f70d6f in glutMainLoopEvent () from /usr/lib/libglut.so.3 #87358 0xb7f717fe in glutMainLoop () from /usr/lib/libglut.so.3 #87359 0x08051a82 in fgMainInit (argc=2, argv=0xbf8d6934) at main.cxx:1007 #87360 0x08051259 in main (argc=2, argv=0xbf8d6934) at bootstrap.cxx:193 I will try to understand this but like I mentioned before...I'm not really a graphics programmer. thanks for the help! -E Curtis L. Olson wrote: Enrique Vaamonde wrote: Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. The fact that the crash is inside the ati driver makes me just a little suspicious of a driver bug. What would be possibly useful is to see the lines further along in the backtrace so we can see where in the flightgear/simgear code the crash happen. Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Hnmm, according to this you are crashing trying to draw the ambient ground light points. That should just be a collection of simple points with no strange opengl calls, unless you've turned on some of the fancy point lighting effects. If you have those on, you might want to turn them off. Otherwise, it looks like the driver is crashing just drawing simple untextured/colored points ... ( ? ) Curt. Enrique Vaamonde wrote: Hi Curt, disregard the last message, I must have screwed up somewhere... anyway...here's the bt after the ATI driver errors: #87344 0x08418821 in ssgVtxTable::draw_geometry (this=0xecd8ba8) at ssgVtxTable.cxx:635 #87345 0x08417fe9 in ssgVtxTable::draw (this=0xecd8ba8) at ssgVtxTable.cxx:560 #87346 0x08405a1b in ssgSelector::cull (this=0xebd9bb0, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgSelector.cxx:73 #87347 0x0840feea in ssgRangeSelector::cull (this=0xebd9a98, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgRangeSelector.cxx:92 #87348 0x0840deb7 in ssgTransform::cull (this=0xebdc4d0, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgTransform.cxx:83 #87349 0x083f8230 in ssgBranch::cull (this=0xa719b18, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgBranch.cxx:276 #87350 0x083fa22b in ssgContext::cull (this=0x1bfc, r=0x0) at ssgContext.cxx:260 #87351 0x083f6102 in ssgCullAndDraw (r=0xa719b18) at ssg.cxx:303 #87352 0x08056ca8 in FGRenderer::update (refresh_camera_settings=true) at renderer.cxx:673 #87353 0x08054b7d in FGRenderer::update () at renderer.hxx:34 #87354 0x08081cc1 in GLUTdraw () at fg_os.cxx:118 #87355 0xb7f70884 in glutJoystickGetCenter () from /usr/lib/libglut.so.3 #87356 0xb7f74478 in fgEnumWindows () from /usr/lib/libglut.so.3 #87357 0xb7f70d6f in glutMainLoopEvent () from /usr/lib/libglut.so.3 #87358 0xb7f717fe in glutMainLoop () from /usr/lib/libglut.so.3 #87359 0x08051a82 in fgMainInit (argc=2, argv=0xbf8d6934) at main.cxx:1007 #87360 0x08051259 in main (argc=2, argv=0xbf8d6934) at bootstrap.cxx:193 I will try to understand this but like I mentioned before...I'm not really a graphics programmer. thanks for the help! -E Curtis L. Olson wrote: Enrique Vaamonde wrote: Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. The fact that the crash is inside the ati driver makes me just a little suspicious of a driver bug. What would be possibly useful is to see the lines further along in the backtrace so we can see where in the flightgear/simgear code the crash happen. Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Acctually I shouldn't be using any advanced or fancy point lightning effects unless they come turned on in the default preferences in the cvs. Funny thing is: why is the driver crashing only in the bay area scenery? I don't seem to have any night flying problems with the other area I use (w070n10). Could it be an object? I will try removing 3D objects around the bay area scenery and will also try going back to freeglut 2.2 and let you know. thanks for your help, -E Curtis L. Olson wrote: Hnmm, according to this you are crashing trying to draw the ambient ground light points. That should just be a collection of simple points with no strange opengl calls, unless you've turned on some of the fancy point lighting effects. If you have those on, you might want to turn them off. Otherwise, it looks like the driver is crashing just drawing simple untextured/colored points ... ( ? ) Curt. Enrique Vaamonde wrote: Hi Curt, disregard the last message, I must have screwed up somewhere... anyway...here's the bt after the ATI driver errors: #87344 0x08418821 in ssgVtxTable::draw_geometry (this=0xecd8ba8) at ssgVtxTable.cxx:635 #87345 0x08417fe9 in ssgVtxTable::draw (this=0xecd8ba8) at ssgVtxTable.cxx:560 #87346 0x08405a1b in ssgSelector::cull (this=0xebd9bb0, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgSelector.cxx:73 #87347 0x0840feea in ssgRangeSelector::cull (this=0xebd9a98, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgRangeSelector.cxx:92 #87348 0x0840deb7 in ssgTransform::cull (this=0xebdc4d0, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgTransform.cxx:83 #87349 0x083f8230 in ssgBranch::cull (this=0xa719b18, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgBranch.cxx:276 #87350 0x083fa22b in ssgContext::cull (this=0x1bfc, r=0x0) at ssgContext.cxx:260 #87351 0x083f6102 in ssgCullAndDraw (r=0xa719b18) at ssg.cxx:303 #87352 0x08056ca8 in FGRenderer::update (refresh_camera_settings=true) at renderer.cxx:673 #87353 0x08054b7d in FGRenderer::update () at renderer.hxx:34 #87354 0x08081cc1 in GLUTdraw () at fg_os.cxx:118 #87355 0xb7f70884 in glutJoystickGetCenter () from /usr/lib/libglut.so.3 #87356 0xb7f74478 in fgEnumWindows () from /usr/lib/libglut.so.3 #87357 0xb7f70d6f in glutMainLoopEvent () from /usr/lib/libglut.so.3 #87358 0xb7f717fe in glutMainLoop () from /usr/lib/libglut.so.3 #87359 0x08051a82 in fgMainInit (argc=2, argv=0xbf8d6934) at main.cxx:1007 #87360 0x08051259 in main (argc=2, argv=0xbf8d6934) at bootstrap.cxx:193 I will try to understand this but like I mentioned before...I'm not really a graphics programmer. thanks for the help! -E Curtis L. Olson wrote: Enrique Vaamonde wrote: Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. The fact that the crash is inside the ati driver makes me just a little suspicious of a driver bug. What would be possibly useful is to see the lines further along in the backtrace so we can see where in the flightgear/simgear code the crash happen. Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Well, neither disabling 3D objects nor going back to freeglut 2.2 (and recompiling simgear/fg with it, just in case) fixed the problem... if any of you has a suggestion, please do speak up :) By the way...additional problems: no 3d clouds at all and the sun is displayed as a black circle. I will try to use the open source drivers and see if anything improves, which I doubt. thanks! cheers, -E Enrique Vaamonde wrote: Acctually I shouldn't be using any advanced or fancy point lightning effects unless they come turned on in the default preferences in the cvs. Funny thing is: why is the driver crashing only in the bay area scenery? I don't seem to have any night flying problems with the other area I use (w070n10). Could it be an object? I will try removing 3D objects around the bay area scenery and will also try going back to freeglut 2.2 and let you know. thanks for your help, -E Curtis L. Olson wrote: Hnmm, according to this you are crashing trying to draw the ambient ground light points. That should just be a collection of simple points with no strange opengl calls, unless you've turned on some of the fancy point lighting effects. If you have those on, you might want to turn them off. Otherwise, it looks like the driver is crashing just drawing simple untextured/colored points ... ( ? ) Curt. Enrique Vaamonde wrote: Hi Curt, disregard the last message, I must have screwed up somewhere... anyway...here's the bt after the ATI driver errors: #87344 0x08418821 in ssgVtxTable::draw_geometry (this=0xecd8ba8) at ssgVtxTable.cxx:635 #87345 0x08417fe9 in ssgVtxTable::draw (this=0xecd8ba8) at ssgVtxTable.cxx:560 #87346 0x08405a1b in ssgSelector::cull (this=0xebd9bb0, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgSelector.cxx:73 #87347 0x0840feea in ssgRangeSelector::cull (this=0xebd9a98, f=0x8dd0020, m=0xbf8d62ec, test_needed=1) at ssgRangeSelector.cxx:92 #87348 0x0840deb7 in ssgTransform::cull (this=0xebdc4d0, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgTransform.cxx:83 #87349 0x083f8230 in ssgBranch::cull (this=0xa719b18, f=0x8dd0020, m=0x8dcffc8, test_needed=1) at ssgBranch.cxx:276 #87350 0x083fa22b in ssgContext::cull (this=0x1bfc, r=0x0) at ssgContext.cxx:260 #87351 0x083f6102 in ssgCullAndDraw (r=0xa719b18) at ssg.cxx:303 #87352 0x08056ca8 in FGRenderer::update (refresh_camera_settings=true) at renderer.cxx:673 #87353 0x08054b7d in FGRenderer::update () at renderer.hxx:34 #87354 0x08081cc1 in GLUTdraw () at fg_os.cxx:118 #87355 0xb7f70884 in glutJoystickGetCenter () from /usr/lib/libglut.so.3 #87356 0xb7f74478 in fgEnumWindows () from /usr/lib/libglut.so.3 #87357 0xb7f70d6f in glutMainLoopEvent () from /usr/lib/libglut.so.3 #87358 0xb7f717fe in glutMainLoop () from /usr/lib/libglut.so.3 #87359 0x08051a82 in fgMainInit (argc=2, argv=0xbf8d6934) at main.cxx:1007 #87360 0x08051259 in main (argc=2, argv=0xbf8d6934) at bootstrap.cxx:193 I will try to understand this but like I mentioned before...I'm not really a graphics programmer. thanks for the help! -E Curtis L. Olson wrote: Enrique Vaamonde wrote: Hi Erik, I have tried tonight the cvs version and although I'm not suffering the RenderTexture problem (I use ATI's propietary binary driver - latest version 8.19.10), I have found the following error when starting up FG. RenderTexture Error: glXCreateGLXPbufferPtr() failed The program loads fine after that tho', however, I am still experiencing a segmentation fault when flying at night in the default San Francisco area. It only happens at night in this area, it won't happen when flying during the day in SF or when flying at night somewhere else (at least in the other scenery where I fly). When I take off (usually default runway 28R), I'd fly runway heading for some 15 to 30 seconds and then comes the segmentation fault. So far, running the program inside gdb gives little (at least to me), but I am pasting part of the output below, just hoping it can help anyone to track this issue: 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #0 0xafc361b3 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #1 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so #2 0xafc35a19 in __glim_R200TCLDrawArrays () from /usr/X11R6/lib/modules/dri/atiogl_a_dri.so . . . and goes on and on If you or anyone need any information or additional testing please let me know ... I will try to use the open source driver in the next few days to see how it goes for me. The fact that the crash is inside the ati driver makes me just a little suspicious of a driver bug. What would be possibly useful is to see the lines further along in the backtrace so we can see where in the flightgear/simgear code the crash happen. Thanks, Curt. ___ Flightgear-devel mailing list
[Flightgear-devel] Re: material animation...
* syd -- Wednesday 23 November 2005 02:31: If I understand you correctly , I need to list all objects that the animation applies to ? I was doing this before , (without global ) and everything worked fine ... but in the documentation it says using an object and global affects all objects that share that material, that is was a faster and preferred method. You make it sound as if there's a contradiction. Yes, global is faster and preferred, but it only works for identical material. Two materials (ssgSimpleState) with different textures are different. So you use the slightly slower way: listing all objects in object-names. It's slower because it has to manipulate several ssgSimpleStates rather than just one, but I wouldn't overrate that. It's what the p51d and others do/did all the time. material animations don't waste any time if there is no change to be made. Just a few number comparisons. Not that they waste any time otherwise ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Enrique Vaamonde wrote: I will try to use the open source drivers and see if anything improves, which I doubt. The OpenSource drivers should do - at least they did for me for a long time, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two issues/question
1) If I fly out of an airport that is located out of the included sample scenery, then at the command line I get: Failed to open file repeated twice. I am using 0.9.8 scenery in that case, because that is all that is available. But there is no indication of what files are not opening, or what the problem is. Is there a difference This is something related to the broken exception throwing, be thankful it doesn't crash at the moment you see the message because it fetches its parts from freed memory! I'm now working on a huge patch fixing these issues all around the fg/sg/atlas/fgrun, and meanwhile you can run with --log-level=info and see what is the file it is trying to open just before the message is printed. V ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
