Re: [Flightgear-devel] How to convert from WGS84 coordinates?
I've found Geotrans Translator v.2.2.5 software; I tried using it for converting from WGS84/NUTM33 to WGS84/Geodetic coordinates and I had some not very good results. I don't know if I am making something wrong with that software or the starting coordinates are not accurate (although they should be :-) I'll investigate more and download GDAL too. Let's see. Do you know Geotrans too? Is it of any value? If this is the NIMA Geotans tool, it is an excellent tool. Norman Yes it is. But I'm not very happy with that. Maybe it's just me (I'm totally new to those coordinates systems) or the fgfs scenery are not accurate enough. Anyway the first results are not very satisfying. Objects placed into fgfs scenery, using the coordinates which Geotrans converted for me, are in the wrong place. Maybe I'm missing something. Are experienced with that Geotrans? May I send you some test files and double check with you what I am doing so to be shure it's not me doing it wrong? Thx in advance, Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Quoting Robicd : Datum: WGS84 Projection: NUTM33 Coordinate top left x: 353620.2 y: 4225543.6 Coordinate bottom right x: 354212.2 y: 4225976.1 These are UTM North Zone 33 I entered these coordinates in fgsd and I had my test picture mirrored upside down. It appears that your bottom has a northings (y) value greater than your top. Anyway, I get these ( decimal ) values : x: 353620.2 y: 4225543.6 = lat: 38.16592 lon: 13.32904 x: 354212.2 y: 4225976.1 = lat: 38.16991 lon: 13.33570 HTH -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
Hi Fred, Datum: WGS84 Projection: NUTM33 Coordinate top left x: 353620.2 y: 4225543.6 Coordinate bottom right x: 354212.2 y: 4225976.1 These are UTM North Zone 33 I entered these coordinates in fgsd and I had my test picture mirrored upside down. It appears that your bottom has a northings (y) value greater than your top. Anyway, I get these ( decimal ) values : x: 353620.2 y: 4225543.6 = lat: 38.16592 lon: 13.32904 x: 354212.2 y: 4225976.1 = lat: 38.16991 lon: 13.33570 You're totally right. That can't be. Bottom right coordinate is wrong of course. I checked again (not the same image, but from the same source, which is www.atlanteitaliano.it, and at almost same coordinates) and I got what follows: Top Left x: 353582.4 y: 4225544.6 Bottom right x: 354210.8 y: 4225048.5 Anyway, can you please explain to me how to place some aerial/pictures into a scene in order to texture the terrain? I'd like to use those pictures from www.atlanteitaliano.it but I don't find any docs about this procedure. I know it's possible, there are screenshots at www.flightgear.org, but there's no documentation. Thx, Roberto -- Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Indicated Turn Rate.
I'm working on a new aircraft model and have just come to putting some instruments in place. I discovered a problem with the turn-coordinator which takes input from /instrumentation/turn-indicator/indicated-turn-rate Unfortunately, as soon as FG starts, this value quickly drops to -2.50 and holds there. (regardless of how you move the aircraft). Has anyone got any ideas how I broke this? The TC doesn't need to be an electrical system does it? Thanks Dave Martin. Note: I'm using a weekend CVS build and the TC works in the other aircraft. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Indicated Turn Rate.
Dave Martin wrote: I'm working on a new aircraft model and have just come to putting some instruments in place. I discovered a problem with the turn-coordinator which takes input from /instrumentation/turn-indicator/indicated-turn-rate Unfortunately, as soon as FG starts, this value quickly drops to -2.50 and holds there. (regardless of how you move the aircraft). Has anyone got any ideas how I broke this? The TC doesn't need to be an electrical system does it? Thanks Dave Martin. Note: I'm using a weekend CVS build and the TC works in the other aircraft. I believe the default TC is designed to run off an electricly driven gyro ... so if you have no juice, the gyro will spin down (or never spin up) and you'll see symptoms like you describe. I would suggest dropping in the generic electrical system config to see if that takes care of the problem. 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] Runway lighting
Paul Surgeon wrote: I played around with some runway lighting today to see if textured polygons are feasible. Here is what textured, billboard runway lights look like : http://surgdom.hollosite.com/flightgear/screenshots/index.html With 6 * 1 ft runways all in view at one time my frame rate dropped from 50 down to 20 FPS on an old Ti 4200. I think 6 * 1 ft runways should pretty much cater for any large airport. That's close to 5000 runway lights. This is just a hardcoded test to see what the performance impact is if one uses a brute force approach with zero performance enhancements. One could probably cull in between lights beyond certain distances which would help performance and look a bit better from a distance. Also I'm not sure what sort of impact billboarding and distance scaling has on performance - it would probably be faster if I had fixed polygons. If my Ti4200 can do the job then I'm sure newer video cards like the nVidia FX 5700 and up should handle these lights quite nicely. One thing we would need to figure out before we could head down this path would be a way to hide runway lights that are viewed from behind. Approach and runway lights are directional and pointed directly at aircraft arriving on the glide slope. So as you view them off axis they will be dimmer and when viewed from behind you shouldn't see them at all. Currently lights are actually a triangle drawn in point mode with two of the verticies set to zero alpha. This way backface culling hides the lights from behind. But if we switch to some sort of billboarded quad for lights, we lose this capability. We would either need to come up with some clever trick, write a new ssg selector node with this sort of functionality, or use vertex shaders which plib doesn't support. Any ideas? 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] Indicated Turn Rate.
On Thursday 27 Jan 2005 18:06, Curtis L. Olson wrote: I believe the default TC is designed to run off an electricly driven gyro ... so if you have no juice, the gyro will spin down (or never spin up) and you'll see symptoms like you describe. I would suggest dropping in the generic electrical system config to see if that takes care of the problem. Curt. Thank's that fixed it :-) I think I should probably look into making a good electrical system for this model. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against Sun's
On Thu, 27 Jan 2005 07:12:49 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..this Groklaw thread suggests we cannot do a GPL port to Sun's new OpenSolaris, as we risk lawsuits: No, and the reason is stated here: Because Sun is not opening their patents to the entire open source community under any license, anyone who works on CDDL code and/or reviews the Sun patents is now tainted [...] Porting to OpenSolaris and working on OpenSolaris are two totally different topics. BTW: ..riiight, we all can agree on that, now try keeep in mind _none_ of us are IBM, and The SCO Group is still running its 2 yr old 419 scam in the 9'th Circuit Court before Judge Kimball in SLC, Utah. ..I mean, can _you_ disprove TSG's claim Linus stole UNIX code? As in; pay your own pack of law sharks, a court reporter's etc travel etc expenses to go visit Linus and have him get his lawyer etc to help his testify under oath Hell no, I wrote it myself!? ..eh, no? Then TSG's claim Linus stole UNIX code becomes a legally established case law fact. 1.) we get around 300 downloads of the Solaris package per _year_, ..yeah, it's we risk losing say 300 Solaris people against I risk losing my home etc on a patent infringement lawsuit from Sun, AFAICT. ..in Norway, I'm expected to know all about patents in my field, (which BTW thank God is thermochemical gasification ;o) ) as the expected due diligence, while Americans and software developers do their due diligence by _NOT!!!_ knowing _anything_ about patents. Yeehaw. 2.) I expect the sol8 package to run on sol9 and OpenSolaris as well. So why should be bother ..if our sol8 port works for sol9 and sol10 and OpenSolaris, we're home free, whether or not this continues to be the case, Sun decides. _If_ they decide to introduce Microsoft-style DR-DOS errors against us, my recommendation is we pull _all_ Solaris support, and go public on Groklaw and whatever else media is listening, it would also help Sun's remaining few supporters in the open source world push Sun C-level staff towards GPL and ditch their their cuddly TSCOG CDDL license. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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] Indicated Turn Rate.
Dave Martin wrote: On Thursday 27 Jan 2005 18:06, Curtis L. Olson wrote: I believe the default TC is designed to run off an electricly driven gyro ... so if you have no juice, the gyro will spin down (or never spin up) and you'll see symptoms like you describe. I would suggest dropping in the generic electrical system config to see if that takes care of the problem. Curt. Thank's that fixed it :-) I think I should probably look into making a good electrical system for this model. If you have questions about the config file format, please ask. 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] ..Groklawyers warns GPL developers against Sun's
Arnt Karlsen wrote: ..riiight, we all can agree on that, now try keeep in mind _none_ of us are IBM, and The SCO Group is still running its 2 yr old 419 scam in the 9'th Circuit Court before Judge Kimball in SLC, Utah. Relax. Under no circumstances will we be any more exposed than if we ported to *commercial* Solaris, where we have no rights to any Sun IP at all. This is a non-issue. The complaint is that the Sun patent grant is unfair and incompatible with the GPL, so free software developers should not attempt to use the Sun patents. We aren't, so we don't care. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On 27/01/2005 at 12:19 Curtis L. Olson wrote: snip rwy lights are dropping the frame rate Any ideas? Not on the technical side, but one thing we could do now is to ditch the green taxiway center lights. These aren't specified in the new format apt data, and the latest build has defaulted to enabling them for all taxiways that have edge lights. If we switch them off for the next scenery build, then the majority of smaller airports will probably be more accurate (ie. they shouldn't have them anyway), and the larger airports will gain a framerate boost at the expense of missing the green lights that might exist in real life. Currently the lighting at EGLL or KSFO drops my frame rate from around 30 to about 10. Based on a rough estimate of light numbers, I reckon that ditching the green taxiway centerlights might get back 3 - 4 fps, not brilliant but a start. Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
Arnt Karlsen wrote: ..if our sol8 port works for sol9 and sol10 and OpenSolaris, we're home free, whether or not this continues to be the case, Sun decides. _If_ they decide to introduce Microsoft-style DR-DOS errors against us, my recommendation is we pull _all_ Solaris support, and go public on Groklaw and whatever else media is listening, [...] I'm surprised there are still people out there having too much free spare time Maybe you don't know Sun very much. Sun has a significant history of supporting binaries of already outdated operating system versions, so we can expect our binaries to run on Solaris10. And _if_ we realize that there are users having access to a workstation that is capable of running FlightGear (as the requirements for FlightGear have grown rapidly I assume you need at least an XVR-1000 board), running Solaris10 and having difficulties with our sol8 binaries, then we still can think about putting Solaris10 on someone's machine and build FlightGear there. I think you have forgotten that Solaris10 is not a CDDL-thing only, as with previous releases you can still simply order the install media, 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] Runway lighting
David Luff wrote: On 27/01/2005 at 12:19 Curtis L. Olson wrote: snip rwy lights are dropping the frame rate Any ideas? Not on the technical side, but one thing we could do now is to ditch the green taxiway center lights. These aren't specified in the new format apt data, and the latest build has defaulted to enabling them for all taxiways that have edge lights. If we switch them off for the next scenery build, then the majority of smaller airports will probably be more accurate (ie. they shouldn't have them anyway), and the larger airports will gain a framerate boost at the expense of missing the green lights that might exist in real life. Currently the lighting at EGLL or KSFO drops my frame rate from around 30 to about 10. Based on a rough estimate of light numbers, I reckon that ditching the green taxiway centerlights might get back 3 - 4 fps, not brilliant but a start. Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. Could be VASI/PAPI slowing you down in daytime. 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] ..Groklawyers warns GPL developers against Sun's
On Thu, 27 Jan 2005 10:38:11 -0800, Andy wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..riiight, we all can agree on that, now try keeep in mind _none_ of us are IBM, and The SCO Group is still running its 2 yr old 419 scam in the 9'th Circuit Court before Judge Kimball in SLC, Utah. Relax. Under no circumstances will we be any more exposed than if we ported to *commercial* Solaris, where we have no rights to any Sun IP at all. ..true. This is a non-issue. The complaint is that the Sun patent grant is unfair and incompatible with the GPL, so free software developers should not attempt to use the Sun patents. We aren't, so we don't care. ..we don't know their patent claims, and the advice from Groklaw is don't look, or you'll pay 3 times more for wilful infringement. ..here, we're like in a WWI trench; if we duck, we don't see incoming shell shit, if we take a wee peek, we risk getting shot right down. ;o) ..the prudent way is, let Sun do the porting. They get the source any time they like, and if they want anything new into FlightGear, _they_ get to certify this is our GPL patch and does not infringe on any patent we know of. Requiring somesuch statement, we get to rip out their code and point any plaintiff _their_ way and be done with it like Linus and the kernel guys are done with the The SCO Group. ..other than that under these jurisdictions, I don't see what more can be done to fend off new TSCOG types, so yeah, non-issue it is. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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] ..Groklawyers warns GPL developers against
Martin Spott wrote: [...] And _if_ we realize that there are users having access to a workstation that is capable of running FlightGear (as the requirements for FlightGear have grown rapidly I assume you need at least an XVR-1000 board), While I'm at it I just read the following paragraph in a Sun document and I'd like to understand how this might relate to FlightGear: High-performance model coordinate (MC) devices, such as the Sun XVR-1200 graphics accelerator, typically implement vertex processing and transformations in hardware. A model coordinate device may perform lighting, coordinate transformations, clipping, and culling as well as rasterization and fragment processing in hardware, thereby providing very fast performance. Can anyone tell how this compares to a typical 3D graphics card for the PeeCee ? In case someone had one of this type of boards, would FlightGear make use of these capabilities, and if not, why and could this be changed ? Thanks, 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] ..Groklawyers warns GPL developers against
On Thu, 27 Jan 2005 19:02:34 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..if our sol8 port works for sol9 and sol10 and OpenSolaris, we're home free, whether or not this continues to be the case, Sun decides. _If_ they decide to introduce Microsoft-style DR-DOS errors against us, my recommendation is we pull _all_ Solaris support, and go public on Groklaw and whatever else media is listening, [...] I'm surprised there are still people out there having too much free spare time Maybe you don't know Sun very much. Sun has a significant history of ..precisely, _just_ like Vidkun Lauritz Abraham Jonssn Quisling helped save _several _million_ Ukrainians from starvation deaths in the early 1920ies, Norway only lost about 20,000 in WWII and still shot him, despite his _significant_ history in humanitarian relief work. ;o) And this discussion is off-topic enough here to move to Groklaw. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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] ..Groklawyers warns GPL developers against
Arnt Karlsen wrote: ..we don't know their patent claims, and the advice from Groklaw is don't look, or you'll pay 3 times more for wilful infringement. yes, but in a different context. You should have a clue before repeating such claims. ..the prudent way is, let Sun do the porting. Do you honestly want to advise me not to create Solaris binaries of FlightGear. Did Sun do anything wrong to you, did they steal your sandwitch ? 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] ..Groklawyers warns GPL developers against
Arnt Karlsen wrote: ..precisely, _just_ like Vidkun Lauritz Abraham Jonssremovedn Quisling helped save _several _million_ Ukrainians from starvation deaths in the early 1920ies, Norway only lost about 20,000 in WWII and still shot him, I don't doubt, but these incidents will never prevent me from employing Solaris wherever I feel it makes sense, 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] Runway lighting
On Thursday, 27 January 2005 20:47, David Luff wrote: Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. Is this with or without enhanced runway lighting enabled? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Secondary display - game mode
Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. Thanks. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On 28/01/2005 at 00:00 Paul Surgeon wrote: On Thursday, 27 January 2005 20:47, David Luff wrote: Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. Is this with or without enhanced runway lighting enabled? This is with the standard runway lighting. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
How about not rendering ground textures at night? Has this been done yet? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
Hi, in real life. Currently the lighting at EGLL or KSFO drops my frame rate from around 30 to about 10. Based on a rough estimate of light numbers, I reckon that ditching the green taxiway centerlights might get back 3 - 4 fps, not brilliant but a start. Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. most probably CPU limited. I'm not sure, but maybe a profiler could give you some useful information (if OpenGL symbols and call graph profiling are available). Do you have any triangle counts for the particular scene? I assume your system should be able to render 50 Mio. multi-textured triangles per second. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
Curtis L. Olson wrote: Paul Surgeon wrote: I played around with some runway lighting today to see if textured polygons are feasible. Here is what textured, billboard runway lights look like : http://surgdom.hollosite.com/flightgear/screenshots/index.html With 6 * 1 ft runways all in view at one time my frame rate dropped from 50 down to 20 FPS on an old Ti 4200. I think 6 * 1 ft runways should pretty much cater for any large airport. That's close to 5000 runway lights. This is just a hardcoded test to see what the performance impact is if one uses a brute force approach with zero performance enhancements. One could probably cull in between lights beyond certain distances which would help performance and look a bit better from a distance. Also I'm not sure what sort of impact billboarding and distance scaling has on performance - it would probably be faster if I had fixed polygons. If my Ti4200 can do the job then I'm sure newer video cards like the nVidia FX 5700 and up should handle these lights quite nicely. One thing we would need to figure out before we could head down this path would be a way to hide runway lights that are viewed from behind. Approach and runway lights are directional and pointed directly at aircraft arriving on the glide slope. So as you view them off axis they will be dimmer and when viewed from behind you shouldn't see them at all. Currently lights are actually a triangle drawn in point mode with two of the verticies set to zero alpha. This way backface culling hides the lights from behind. But if we switch to some sort of billboarded quad for lights, we lose this capability. We would either need to come up with some clever trick, write a new ssg selector node with this sort of functionality, or use vertex shaders which plib doesn't support. Any ideas? Curt. Altough the billboard itself always faces the POV, you can still set the normal the way the real light would be pointing to, them set a diffuse light on the POV and enable backface culling. I suppose performance hit should be minimal for TnL hardware. Regards, Tiago ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. --Ivo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
I appreciate that, and if I were using Linux, I'd have already known exactly what to do. :) I should have been more clear...unfortunatly, for this particular application I need to use Windows XP Pro, and I currently have an ATA Mobility Radeon 9000 in the laptop I'm using. I'm trying to get the image to display on a television screen as the secondary display...like I said, I have it working fine in window mode, but not in game mode. Thanks again, Drew On Fri, 28 Jan 2005 00:39:49 +0100, Ivo [EMAIL PROTECTED] wrote: On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. --Ivo ___ 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] Secondary display - game mode
On Thursday 27 Jan 2005 23:39, Ivo wrote: On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. --Ivo IIRC Xinerama doesn't yet work with OpenGL. I'm actually running a multi-head system but I use a 2nd card and normal x.org definitions for the second display; the drawback is that x.org doesn't (yet) support dragging one window to the other. So, unless I'm pleasantly mistaken, I'd have to presume Ivo is running Windows? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
On Friday 28 Jan 2005 00:02, Dave Martin wrote: On Thursday 27 Jan 2005 23:39, Ivo wrote: On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. --Ivo IIRC Xinerama doesn't yet work with OpenGL. I'm actually running a multi-head system but I use a 2nd card and normal x.org definitions for the second display; the drawback is that x.org doesn't (yet) support dragging one window to the other. So, unless I'm pleasantly mistaken, I'd have to presume Ivo is running Windows? Dave Martin Just to correct myself, that was mean to read 'Drew' not 'Ivo'. :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
Drew wrote: I appreciate that, and if I were using Linux, I'd have already known exactly what to do. :) I should have been more clear...unfortunatly, for this particular application I need to use Windows XP Pro, and I currently have an ATA Mobility Radeon 9000 in the laptop I'm using. I'm trying to get the image to display on a television screen as the secondary display...like I said, I have it working fine in window mode, but not in game mode. Thanks again, Drew On Fri, 28 Jan 2005 00:39:49 +0100, Ivo [EMAIL PROTECTED] wrote: On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. If you are running a binary compiled with SDL, then I don't think SDL supports that ... at least not on linux. That's one reason we need to keep glut support around, you can't go full screen in SDL on a multi headed system without blanking and locking out the other heads. 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] Runway lighting
Tiago Gusmão wrote: Altough the billboard itself always faces the POV, you can still set the normal the way the real light would be pointing to, them set a diffuse light on the POV and enable backface culling. I suppose performance hit should be minimal for TnL hardware. The normal only affects lighting. Backface culling is done based on the winding of the triangle. You would still see the light from every direction. 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] ..Groklawyers warns GPL developers against
On Thu, 27 Jan 2005 21:31:46 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..we don't know their patent claims, and the advice from Groklaw is don't look, or you'll pay 3 times more for wilful infringement. yes, but in a different context. You should have a clue before repeating such claims. ..agreed. My patenting experience is from a somewhat more innovation friendly environment; thermochemical gasification in petroleum producing Norway, where not trying to look qualifies as willful infringement, but I did look, there was nothing!, doesn't. ;o) ..the prudent way is, let Sun do the porting. Do you honestly want to advise me not to create Solaris binaries of FlightGear. ..no, but I feel that is the safer approach until Sun proves less hostile towards the GPL part of the F/OSS world than their corporate stances and policies on software patents, TSCOG, Microsoft etc, suggests. ..the media coverage suggests Sun may make statements to clarify some of these issues in the next few days, and I hear Groklaw people try tell us there is GPL friendly opposition within Sun, but that was also true for Caldera/TSCOG, the C-level people and the Board Membership in both these ailing firms run their firms as they see fit (or whatever). Did Sun do anything wrong to you, did they steal your sandwitch ? ..no, they haven't done me any harm except as a member of the F/OSS world and except for funding TSCOG's scam lawsuit by buying a US$ 12 mill license, forcing me to spend time at Groklaw to learn enough to save my own wee business, it's what funds my gasification work, without Groklaw, I probably would have had to liquidate my linux business, 2 years back, TSCOG etc was all over the media here. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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] ..Groklawyers warns GPL developers against
On Friday 28 Jan 2005 01:34, Arnt Karlsen wrote: Did Sun do anything wrong to you, did they steal your sandwitch ? ..no, they haven't done me any harm except as a member of the F/OSS world and except for funding TSCOG's scam lawsuit by buying a US$ 12 mill license, forcing me to spend time at Groklaw to learn enough to save my own wee business, it's what funds my gasification work, without Groklaw, I probably would have had to liquidate my linux business, 2 years back, TSCOG etc was all over the media here. Well, here's thanking you for having the backbone to look after your operation. Its a shame that (the) Sun is slowly burning away. I just hope that not too many more *nix based business are going to go the same way. (I'm still trying to buy a good SGI 02 but I'm having no luck) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
On Thu, 27 Jan 2005 21:49:36 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..precisely, _just_ like Vidkun Lauritz Abraham Jonssremovedn Quisling helped save _several _million_ Ukrainians from starvation deaths in the early 1920ies, Norway only lost about 20,000 in WWII and still shot him, I don't doubt, but these incidents will never prevent me from employing Solaris wherever I feel it makes sense, ..true, however, _does_ it make any sense from now on? To me and quite a few more at Groklaw, it looks like Sun too now wants a division, between the GPL world and everyone else, remember Microsoft funds them, and we know they put a lot of money into TSCOG, US$ 50 mill thru the BayStar deal alone, and it is really Sun who decides whether you're in a line of fire or not if you carry on as you perfectly legally has been working. ..none of us _knows_ the ramifications of Sun's new patent regime, the underhandedness in their CDDL and its OSI approval that gained Sun access to IBM's 500 patents while denying non-CDDL people access to Sun's 1600 open-to-CDDL tells a verifiable story and, like it or not, we will all get to see how this plays out. ..me, I don't do anything Sun or Java, so staying away is easy for me. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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] ..Groklawyers warns GPL developers against
On Fri, 28 Jan 2005 02:09:14 +, Dave wrote in message [EMAIL PROTECTED]: On Friday 28 Jan 2005 01:34, Arnt Karlsen wrote: Well, here's thanking you for having the backbone to look after your operation. .. ;o) Its a shame that (the) Sun is slowly burning away. I just hope that not too many more *nix based business are going to go the same way. ..agreed, all instead going GPL would allow porting the best bits between every'nix. (I'm still trying to buy a good SGI 02 but I'm having no luck) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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
[Flightgear-devel] [PATCH] Simgear support for dimmable panel lighting animation
This patch adds support to the model animation system for modifying emissive states on the fly so that it is possible to make lights appear to dimm. This is an example of a configuration entry which should explain how it is used: animation typematerial-emission/type object-nameFace/object-name property/controls/lighting/instruments-norm/property emiss-red1.0/emiss-red emiss-green0.8/emiss-green emiss-blue0.5/emiss-blue /animation Note the color entries are the emissive colors when the property value is 1.0. They are useful for tinting the light. The property itself must be float or double and is clamped to values between 0 ~ 1.0 inclusively. The property value is multiplied against the colors to get the actual material properties. Thus property value 0.0 = darkest, and 1.0 = brightest. Best, Jim Patch file: http://www.spiderbark.com/fgfs/emissanim.diff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On Friday 28 January 2005 02:18, Curtis L. Olson wrote: Tiago Gusmão wrote: Altough the billboard itself always faces the POV, you can still set the normal the way the real light would be pointing to, them set a diffuse light on the POV and enable backface culling. I suppose performance hit should be minimal for TnL hardware. The normal only affects lighting. Backface culling is done based on the winding of the triangle. You would still see the light from every direction. Regards, Curt. What about setting only one point at the beginning of the runway and then calculating an angel between it and the normal of the billboard. When the angel is 90° or - 90° the billboard is turned off when it is 90° or -90° then on. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
Oliver C. wrote: What about setting only one point at the beginning of the runway and then calculating an angel between it and the normal of the billboard. When the angel is 90° or - 90° the billboard is turned off when it is 90° or -90° then on. We might need to do something like that. What I think might be a useful approach would be to add some sort of ssgDirectionalSelector where you provide a normal vector, a point, and a max angle. If the angle between the view point and the ssgDirectionSelctor point is within the specified angle, the child(ren?) are selected, otherwise they are skipped. However, to make this work right, you'd need to do in per light (which would be *very* expensive) or for small groups of clustered lights (also probably expensive.) It would be nice to put the entire runway under a single node, but how do you pick the critical point? Too close to the start and the end lights will drop out too soon. Too close to the end and the front lights won't drop out soon enough. I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( 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] Runway lighting
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Thursday, January 27, 2005 8:14 PM Subject: Re: [Flightgear-devel] Runway lighting Oliver C. wrote: What about setting only one point at the beginning of the runway and then calculating an angel between it and the normal of the billboard. When the angel is 90° or - 90° the billboard is turned off when it is 90° or -90° then on. We might need to do something like that. What I think might be a useful approach would be to add some sort of ssgDirectionalSelector where you provide a normal vector, a point, and a max angle. If the angle between the view point and the ssgDirectionSelctor point is within the specified angle, the child(ren?) are selected, otherwise they are skipped. However, to make this work right, you'd need to do in per light (which would be *very* expensive) or for small groups of clustered lights (also probably expensive.) It would be nice to put the entire runway under a single node, but how do you pick the critical point? Too close to the start and the end lights will drop out too soon. Too close to the end and the front lights won't drop out soon enough. I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Hi guys! I have too framerate drops when lights are switch on. on my FX5950 ultra and PIV3500 We don't need to have plib support of shaders. I use shaders for runway lights. I don't use triangles I use points(pointsprites). and in shader I use normals to calculate visibility of light (dot with view direction) So on 1 light now you have spend 3 points and on my approach I spend 1 point. so w/o shaders framerate drops from 70 to 30 with shaders from 70 to 65. so guys take advantage from you real good videocards. I have framework of shaders that can be easyly integrate in fgfs. In that approach you can use GLSL, ARB and NV shaders. Shaders are in txt file. Long time ago I propose to use shaders. maybe runway light is the first thing to try? If you need this you can simply to ask me ;-) Bye Roman 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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
Arnt Karlsen wrote: On Thu, 27 Jan 2005 21:49:36 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: ..precisely, _just_ like Vidkun Lauritz Abraham Jonssremovedn Quisling helped save _several _million_ Ukrainians from starvation deaths in the early 1920ies, Norway only lost about 20,000 in WWII and still shot him, I don't doubt, but these incidents will never prevent me from employing Solaris wherever I feel it makes sense, ..true, however, _does_ it make any sense from now on? Absolutely, when you look at the facts then you'll realize that Solaris didn't change since yesterday, 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
[Flightgear-devel] Re: [Terragear-devel] Reducing airports polygon count
Dale E. Edmons wrote: This might also help others who are having problems with frame rate. Airports are currently very dense in terms of polygon count, and somewhat flat. Reducing the polygon and texture count would bound to improve FGFS's framerate too. To my experience the airport's runway itself doesn't have much influence on the frame rate, the most significant hit comes from runway lightning and additional scenery objects around the airfield. Compared to that the impact of the runway on the frame rate is neglectible. BTW, reducing the polygon count of the runway is a bit tricky. In many cases you must have the polygons at least match the _borders_ of the runway because, as in real life, the surroundung terrain is very often _not_ flat, so you have to distinct the level of the runway from the terrain. On the other hand the runway, while being smooth in order to avoid bumps, still should follow the terrain elevation in its longitudinal orientation, 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
