RE: [Flightgear-devel] fgrun improvements
Paul Surgeon wrote: On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Are there any unwanted effects elsewhere, or can this be used as a patch to our code? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 10:33, Vivian Meazza wrote: Paul Surgeon wrote: On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Are there any unwanted effects elsewhere, or can this be used as a patch to our code? Well the endhanced lighting with GL_POINT_SMOOTH looks awful on my Ti 4200. Big square shaped polygons. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 12:11, you wrote: On Tuesday, 25 January 2005 10:33, Vivian Meazza wrote: Paul Surgeon wrote: On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Are there any unwanted effects elsewhere, or can this be used as a patch to our code? Well the endhanced lighting with GL_POINT_SMOOTH looks awful on my Ti 4200. Big square shaped polygons. Paul Oops! I meant enhanced runway lighting looks awful *WITHOUT* GL_POINT_SMOOTH enabled. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Oliver wrote --(en/dis)able-enhanced-lighting This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Very nice. But i suggest to move the enhanced-lighting option into the advanced menu or at least adding a notice in brackets that tells the user that this option can lead to a large frame rate drop. Because this is what happens on a typical end-user computer when this option is activated. Here i get 1 fps at night when i activate this option on an Athlon 2000+ with a Geforce 4 Ti 4200 videocard, without it, i get 39 fps. End users tend to activate everything and then they wonder why FlightGear is running at 1 fps, that's why it is better to hide such options in the advanced menu. On a Pentium 4 2.8 with a GeForce 5200 I get similar results. In addition, checking this option during run-time changes the colours in the cockpit of the some 3d models (I haven't tested them all). Unchecking it doesn't change the colour back. Is this a viable option, or is there something wrong with it? This is by way of a rhetorical question as on my system I don't actually need it. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote: On a Pentium 4 2.8 with a GeForce 5200 I get similar results. In addition, checking this option during run-time changes the colours in the cockpit of the some 3d models (I haven't tested them all). Unchecking it doesn't change the colour back. Is this a viable option, or is there something wrong with it? This is by way of a rhetorical question as on my system I don't actually need it. This options adds specular highlight for _textured_ surfaces which isn't covered by default OpenGL. It doesn't do anything for non-textured (or textures that are very bright of themselves) so it takes probably two or three times to see what is actually happening. In the end it will give properly defined models a shiny metallic look (for textured objects). It's up to the user if he/she finds this useful or not. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Erik Hofman wrote: Vivian Meazza wrote: On a Pentium 4 2.8 with a GeForce 5200 I get similar results. In addition, checking this option during run-time changes the colours in the cockpit of the some 3d models (I haven't tested them all). Unchecking it doesn't change the colour back. Is this a viable option, or is there something wrong with it? This is by way of a rhetorical question as on my system I don't actually need it. This options adds specular highlight for _textured_ surfaces which isn't covered by default OpenGL. It doesn't do anything for non-textured (or textures that are very bright of themselves) so it takes probably two or three times to see what is actually happening. In the end it will give properly defined models a shiny metallic look (for textured objects). It's up to the user if he/she finds this useful or not. Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Why is it so expensive of frame-rate? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederic Bouvier schrieb: Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. The latest screen shots looked like a good solution. An alternative (which I thougt of, before seeing the current implementation) could be to add an button that opens a pop up with the command line. An also quite important point (dunno if it's already implemented) are descriptions for the options. I wouldn't know what Horizon effect would change in FGFS. Is it possible to have bubble-helps for that? Keep up the good work! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9Mf0lhWtxOxWNFcRAmwIAJ9cAt1g3wOQ60mIO4McUMeHODdxnACePmP5 Fh6rU9fWC1Esz0Gesn8JnsI= =Kqe/ -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Erik wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. Enhanced runway lighting makes the runway lights bigger than the usual one pixel dot, like in real life (adding the halo so to speak). Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. Erik Right, so ignore all the foregoing - why does 'enhanced lighting (runway)' change the colour of some 3d panels? Perhaps an artifact of the video card? And why isn't it reversible? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote: Right, so ignore all the foregoing - why does 'enhanced lighting (runway)' change the colour of some 3d panels? Perhaps an artifact of the video card? And why isn't it reversible? I'm not sure about the change in color of the 3d panels, I've never noticed that myself. Regarding the enhanced lighting option, are you sure you don't mean distance attenuation here? That option is only effective if enhanced lighting is activated. So it might look as if it doesn't do anything, but it only works in a particular order: enhanced-lighting on - distance attenuation on enhanced lighting off = distance attenuation off Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Erik Hofman wrote: Vivian Meazza wrote: Right, so ignore all the foregoing - why does 'enhanced lighting (runway)' change the colour of some 3d panels? Perhaps an artifact of the video card? And why isn't it reversible? I'm not sure about the change in color of the 3d panels, I've never noticed that myself. Regarding the enhanced lighting option, are you sure you don't mean distance attenuation here? That option is only effective if enhanced lighting is activated. So it might look as if it doesn't do anything, but it only works in a particular order: enhanced-lighting on - distance attenuation on enhanced lighting off = distance attenuation off No, I mean enhanced lighting: if I use the Hunter, by day, with distance attenuation checked, when I check enhanced lighting the panel and parts of some instruments change from grey to dark grey. If I then uncheck enhanced lighting, they don't change back. This may be a 'feature' of my video card, or of the textures I'm using. I'm working on these right now. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 January 2005 11:05, Erik Hofman wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. No, i was talking about enhanced runway lightning, this is what i get when running flightgear with this option: --enable-enhanced-lighting I was not talking about specular highlights. Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. The only consumer videocards we have today are from Ati and NVidia, do their newest models support this? If not, then we should move it to the advanced options. I also want to mention, that MS FS2004 has something similar, but without framerate drop, so there must be another way to display runway lights in such a way. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 13:37, Oliver C. wrote: On Monday 24 January 2005 11:05, Erik Hofman wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. No, i was talking about enhanced runway lightning, this is what i get when running flightgear with this option: --enable-enhanced-lighting I was not talking about specular highlights. Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. The only consumer videocards we have today are from Ati and NVidia, do their newest models support this? If not, then we should move it to the advanced options. I also want to mention, that MS FS2004 has something similar, but without framerate drop, so there must be another way to display runway lights in such a way. Best Regards, Oliver C. I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 January 2005 15:05, Dave Martin wrote: I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Dave Martin I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Dave Martin wrote: On Monday 24 Jan 2005 13:37, Oliver C. wrote: On Monday 24 January 2005 11:05, Erik Hofman wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. No, i was talking about enhanced runway lightning, this is what i get when running flightgear with this option: --enable-enhanced-lighting I was not talking about specular highlights. Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. The only consumer videocards we have today are from Ati and NVidia, do their newest models support this? If not, then we should move it to the advanced options. I also want to mention, that MS FS2004 has something similar, but without framerate drop, so there must be another way to display runway lights in such a way. Best Regards, Oliver C. I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Simple answer - too many vertices. Someone will give us the right answer -Erik Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 14:01, Oliver C. wrote: On Monday 24 January 2005 15:05, Dave Martin wrote: I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Dave Martin I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 14:24, Erik Hofman wrote: Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d How about basic poly with a tiny texture set as 'spherical' (much as is done with the bo105 lights) Would that allow for better performance on consumer hardware or is that too simmilar to the method in use? (I really don't know the first thing about this and I'm guessing) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Erik Hofman Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending ^^^ And in English that is ... ? :-) Is that some voodoo? which supposedly should perform quite well on all modern hardware. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote: Erik Hofman An alternative might be to use pentagonal vertex-fans and alpha blending ^^^ And in English that is ... ? :-) Is that some voodoo? Oh sorry, just a disc constructed from five polygons. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 14:47, Erik Hofman wrote: Dave Martin wrote: How about basic poly with a tiny texture set as 'spherical' (much as is done with the bo105 lights) Would that allow for better performance on consumer hardware or is that too simmilar to the method in use? It might be a good idea to test both methods and see which one looks best and/or has the best performance. Erik It's probably a bit beyond my abilities to do either - I assume it would need some coding to place the polys on the runway light locations without loading *every* one individually from an XML file. It would be nice to find a 'solution' to better frame-rates at illuminated airports tho because landing at EGLL at night can be near impossible even on 'good' hardware. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Dave Martin wrote: On Monday 24 Jan 2005 14:47, Erik Hofman wrote: Dave Martin wrote: How about basic poly with a tiny texture set as 'spherical' (much as is done with the bo105 lights) Would that allow for better performance on consumer hardware or is that too simmilar to the method in use? It might be a good idea to test both methods and see which one looks best and/or has the best performance. Erik It's probably a bit beyond my abilities to do either - I assume it would need some coding to place the polys on the runway light locations without loading *every* one individually from an XML file. It would be nice to find a 'solution' to better frame-rates at illuminated airports tho because landing at EGLL at night can be near impossible even on 'good' hardware. This is a good question: just haw are people managing this one? It's OK for me, but I've got good hardware tied to a 21 in screen. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 15:44, Vivian Meazza wrote: It would be nice to find a 'solution' to better frame-rates at illuminated airports tho because landing at EGLL at night can be near impossible even on 'good' hardware. This is a good question: just haw are people managing this one? It's OK for me, but I've got good hardware tied to a 21 in screen. Regards, Vivian Well, I'm basically showing it the sharp-end of an AMD 3200XP with 1GB dual-channel and a 128Mb GeFarce FX5800 Ultra-Leaf-Blower and hoping for the best. ;-) I'm also driving a 21 screen @ 1600x1200x32bpp so it does flog its guts out to hold 15-20fps on approach to London Heathrow at night. (even w/o the 'enhanced' lighting) At any other time (no runway lights in sight) I can expect 100fps or more - rarely dipping under 50fps when there are many buildings etc in sight. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier said: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Very nice! Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Dave Martin said: Well, I'm basically showing it the sharp-end of an AMD 3200XP with 1GB dual-channel and a 128Mb GeFarce FX5800 Ultra-Leaf-Blower and hoping for the best. ;-) Hehe...yeah...everyone should have one of those. My FX5700 LE, decidedly non-ultra consumer grade, goes into software rendering with the fancy lights on. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman said: Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. That might work quite well. I've kind of wondered myself what the deal is. It does not seem logical that adding that property should cause the driver to drop into software rendering. It ought to just ignore it. Just out of curiosity, is anyone getting this slowdown with ATI cards? Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 17:50, Jim Wilson wrote: Erik Hofman said: Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. That might work quite well. I've kind of wondered myself what the deal is. It does not seem logical that adding that property should cause the driver to drop into software rendering. It ought to just ignore it. If its of any interest, my GeFarce spits out that it is using OpenGL version 1.5.2 (NVIDIA 6629) and uses glx 1.3 and glu 1.3 Don't even know if thats useful tho :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Dave Martin wrote: On Monday 24 Jan 2005 17:50, Jim Wilson wrote: Erik Hofman said: Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. That might work quite well. I've kind of wondered myself what the deal is. It does not seem logical that adding that property should cause the driver to drop into software rendering. It ought to just ignore it. The opengl interface itself (for a variety of good reasons) doesn't provide you a way to directly tell if something is implimented in hardware or software. Note that this isn't dropping your whole card into software rendering mode, it's just the specific things that aren't supported in hardware need to be done in software. There are two sides to the issue of having the api tell you whats done in hardware vs. software. Believe me, it's been debated by a lot smarter people than we have here. :-) OpenGL has chosen a certain way to do it (for valid reasons) so we need to make the best of it. 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] fgrun improvements
On Monday, 24 January 2005 20:32, Curtis L. Olson wrote: The opengl interface itself (for a variety of good reasons) doesn't provide you a way to directly tell if something is implimented in hardware or software. Note that this isn't dropping your whole card into software rendering mode, it's just the specific things that aren't supported in hardware need to be done in software. There are two sides to the issue of having the api tell you whats done in hardware vs. software. Believe me, it's been debated by a lot smarter people than we have here. :-) OpenGL has chosen a certain way to do it (for valid reasons) so we need to make the best of it. But what we can do is check what type of video card or driver is being used and only allow that feature to be switched on if the hardware supports it. For instance my system returns : OpenGL vendor : NVIDIA Corporation OpenGL version : 1.5.2 NVIDIA 66.29 OpenGL renderer: GeForce4 Ti 4200 with AGP8X/AGP/SSE/3DNOW! If you need an SGI machine for the enhanced lighting then if you detect an nVidia or ATI string just disable the enhanced lighting or hide the option. Or alternatively check for an SGI string and if one is not found assume that the feature is not supported. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Paul Surgeon wrote: On Monday, 24 January 2005 20:32, Curtis L. Olson wrote: The opengl interface itself (for a variety of good reasons) doesn't provide you a way to directly tell if something is implimented in hardware or software. Note that this isn't dropping your whole card into software rendering mode, it's just the specific things that aren't supported in hardware need to be done in software. There are two sides to the issue of having the api tell you whats done in hardware vs. software. Believe me, it's been debated by a lot smarter people than we have here. :-) OpenGL has chosen a certain way to do it (for valid reasons) so we need to make the best of it. But what we can do is check what type of video card or driver is being used and only allow that feature to be switched on if the hardware supports it. For instance my system returns : OpenGL vendor : NVIDIA Corporation OpenGL version : 1.5.2 NVIDIA 66.29 OpenGL renderer: GeForce4 Ti 4200 with AGP8X/AGP/SSE/3DNOW! If you need an SGI machine for the enhanced lighting then if you detect an nVidia or ATI string just disable the enhanced lighting or hide the option. Or alternatively check for an SGI string and if one is not found assume that the feature is not supported. Something about runway lighting has changed recently. Either newer nvidia drivers/cards have intentionally slowed down some things, or we are doing something different. I don't recall a change on our end, but previously, I never saw any where near the slowdown I'm seeing now when runway lights come on. 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] fgrun improvements
On Monday 24 Jan 2005 19:39, Curtis L. Olson wrote: Something about runway lighting has changed recently. Either newer nvidia drivers/cards have intentionally slowed down some things, or we are doing something different. I don't recall a change on our end, but previously, I never saw any where near the slowdown I'm seeing now when runway lights come on. Regards, Curt. I will 'regress' my way back through the Nvidia drivers and check :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Erik wrote: Vivian Meazza wrote: Erik Hofman An alternative might be to use pentagonal vertex-fans and alpha blending ^^^ And in English that is ... ? :-) Is that some voodoo? Oh sorry, just a disc constructed from five polygons. OK I'm trying pentagonal vertex-fans and alpha blending for the nav lights I'm just doing for the Hunter. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 20:15, Dave Martin wrote: On Monday 24 Jan 2005 19:39, Curtis L. Olson wrote: Something about runway lighting has changed recently. Either newer nvidia drivers/cards have intentionally slowed down some things, or we are doing something different. I don't recall a change on our end, but previously, I never saw any where near the slowdown I'm seeing now when runway lights come on. Regards, Curt. I will 'regress' my way back through the Nvidia drivers and check :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm getting roughly the same fps hit due to runway lights with Nvidia drivers down to 4496. Would anyone else like to try and then compare notes? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 20:22, Vivian Meazza wrote: Erik wrote: Vivian Meazza wrote: Erik Hofman An alternative might be to use pentagonal vertex-fans and alpha blending ^^^ And in English that is ... ? :-) Is that some voodoo? Oh sorry, just a disc constructed from five polygons. OK I'm trying pentagonal vertex-fans and alpha blending for the nav lights I'm just doing for the Hunter. Regards, Vivian Any chance you could stack-up a hundred or so of them and see how the frame-rate goes ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Dave Martin wrote On Monday 24 Jan 2005 20:22, Vivian Meazza wrote: Erik wrote: Vivian Meazza wrote: Erik Hofman An alternative might be to use pentagonal vertex-fans and alpha blending ^^^ And in English that is ... ? :-) Is that some voodoo? Oh sorry, just a disc constructed from five polygons. OK I'm trying pentagonal vertex-fans and alpha blending for the nav lights I'm just doing for the Hunter. Regards, Vivian Any chance you could stack-up a hundred or so of them and see how the frame-rate goes ;-) Right now I can't get one to work correctly - some problem with mixing animations. But I think I know the answer - too many vertices. :-( Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote: Dave Martin wrote: On Monday 24 Jan 2005 13:37, Oliver C. wrote: On Monday 24 January 2005 11:05, Erik Hofman wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. No, i was talking about enhanced runway lightning, this is what i get when running flightgear with this option: --enable-enhanced-lighting I was not talking about specular highlights. Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. The only consumer videocards we have today are from Ati and NVidia, do their newest models support this? If not, then we should move it to the advanced options. I also want to mention, that MS FS2004 has something similar, but without framerate drop, so there must be another way to display runway lights in such a way. Best Regards, Oliver C. I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Simple answer - too many vertices. Someone will give us the right answer -Erik Regards, Vivian After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Regards, Tiago ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On January 24, 2005 12:50 pm, Jim Wilson wrote: Just out of curiosity, is anyone getting this slowdown with ATI cards? Best, Jim If you mean whether I get slow down on airport at night, the answer is yes. In external view, I get about 6-7fps. At night, the framerates get halved. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Tuesday, 25 January 2005 02:29, Tiago Gusmão wrote: After reading the glPointSize doc, I think the problem is in using point sizes bigger than 1 and point antialiasing at the same time I can't test it now, can someone do it? just disable GL_POINT_SMOOTH and see it there is an fps improvement Bingo! With GL_POINT_SMOOTH disabled the enhanced lighting runs at exactly the same speed as non-enhanced lighting. (40 fps sitting on 28R at KSFO) Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier a écrit : To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a add new button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. The airport list refresh fix and the message when launching fgfs are the next step -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier wrote: Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. Well, the aim is to get it more intuitive for Windows users. The could care less about the command-line option. I can also consider putting the text box in the Advanced section That might not be a bad idea, but only showing it when a user selects it. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Fred wrote Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section I'd go with the Advanced section - that's a common practice elsewhere. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote : Fred wrote Erik Hofman wrote : Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg If you're going this path (and it certainly does look good) then you might want to consider removing the command-line textbox altogether. It might look a bit daunting for a new user. Is there another path ? At least people are able to see immediately the result of their actions as the text is refresh in realtime. I can also consider putting the text box in the Advanced section I'd go with the Advanced section - that's a common practice elsewhere. I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier wrote: This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Looks great Frederic, good work! 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] fgrun improvements
Fred wrote: Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip Works nicely. However, the advanced options repeat some of the ordinary options, I suppose this is a legacy of earlier software: illogical though. I can't see any great value in the show command line option, since this is adequately covered (or should be) by the Advanced options. When the Show Command Line options are displayed, I felt that you were inviting these to be edited direct, indeed that would be nice. This is also a critism of the 'Advanced Options' - some of them aren't - e.g. Airport, Aircraft. I would think that options should be just that, and items should only be displayed where they can be changed. Finally, it would perhaps be better English to say: 'FlightGear has been started' or 'FlightGear starting' Good progress, and so quick too, Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Vivian Meazza wrote : Fred wrote: Erik Hofman a écrit : Frederic Bouvier wrote: I implemented something in between : http://frbouvi.free.fr/flightsim/fgrun-basic-2.jpg The popup on this window is modal and stay as long as FG is running : http://frbouvi.free.fr/flightsim/fgrun-basic-3.jpg Much better, great work! If someone want to try : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun-win32-20050123.zip Works nicely. However, the advanced options repeat some of the ordinary options, I suppose this is a legacy of earlier software: illogical though. I can't see any great value in the show command line option, since this is adequately covered (or should be) by the Advanced options. When the Show See Advanced as the reference : all options should be there. And you already noted : it's legacy. Command Line options are displayed, I felt that you were inviting these to be edited direct, indeed that would be nice. This is also a critism of the 'Advanced Options' - some of them aren't - e.g. Airport, Aircraft. I would think that options should be just that, and items should only be displayed where they can be changed. I want to have the resulting command line somewhere so I can copy/paste to ask support, or debug from the shell. And parsing the command line could be added in the future but it is at the bottom of my priority list. Finally, it would perhaps be better English to say: 'FlightGear has been started' or 'FlightGear starting' noted Good progress, and so quick too, Thanks, -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
--(en/dis)able-enhanced-lighting This is in CVS now ( should show up in a few hours on SF ). In the meantime, a screenshot : http://frbouvi.free.fr/flightsim/fgrun-basic.jpg Very nice. But i suggest to move the enhanced-lighting option into the advanced menu or at least adding a notice in brackets that tells the user that this option can lead to a large frame rate drop. Because this is what happens on a typical end-user computer when this option is activated. Here i get 1 fps at night when i activate this option on an Athlon 2000+ with a Geforce 4 Ti 4200 videocard, without it, i get 39 fps. End users tend to activate everything and then they wonder why FlightGear is running at 1 fps, that's why it is better to hide such options in the advanced menu. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier wrote: Comments welcome Great ideas, just one little concern: What measures are applied to identify which airports should show up in the selection list ? Consider a user has installed most of the world scenery, is FGrun then going to parse the whole scenery to see which airports are present ? I don't think so, because it will take too much time. To my impression FGrun looks at the base scenery directories and decides which airports lie in the present scenery areas (according to the airport database). Now what about those airports that are present in the airport database but not part of the senery - as all those helipads that, as you told, are now excluded from the scenery ? When I tried the 0.9.8 Win32 package I chose Alcatraz from the list in FGrun and noticed, that the field is actually not present in the scenery - this could be fixed, 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] fgrun improvements
Quoting Martin Spott : Frederic Bouvier wrote: Comments welcome Great ideas, just one little concern: What measures are applied to identify which airports should show up in the selection list ? Consider a user has installed most of the world scenery, is FGrun then going to parse the whole scenery to see which airports are present ? I don't think so, because it will take too much time. To my impression FGrun looks at the base scenery directories and decides which airports lie in the present scenery areas (according to the airport database). Now what about those airports that are present in the airport database but not part of the senery - as all those helipads that, as you told, are now excluded from the scenery ? When I tried the 0.9.8 Win32 package I chose Alcatraz from the list in FGrun and noticed, that the field is actually not present in the scenery - this could be fixed, I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On 21/01/2005 at 13:16 Frederic Bouvier wrote: To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a add new button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. Comments welcome It would be nice if fgrun could detect when Map/Atlas were installed, and have an option to create the maps of the installed scenery using Map (with a warning that this might take a while!). 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] fgrun improvements
Frederic Bouvier wrote: I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. Now that we use apt.dat (X-Plane format) it would be possible to walk the list and get the lat/lon of the aircraft (first two parameters of the runway definition if I'm not mistaken). This allows you to search in for the proper directory right away instead of checking every airport in every directory. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Erik Hofman wrote: Now that we use apt.dat (X-Plane format) it would be possible to walk the list and get the lat/lon of the aircraft (first two parameters of Make that airport Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Quoting Erik Hofman: Frederic Bouvier wrote: I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. Now that we use apt.dat (X-Plane format) it would be possible to walk the list and get the lat/lon of the aircraft (first two parameters of the runway definition if I'm not mistaken). This allows you to search in for the proper directory right away instead of checking every airport in every directory. As scenery are packed by chunked of 10x10 degrees, it seems useless to check deeper inside the scenery tree. And at least we could start at heliport locations that are in apt.dat but not in the scenery. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Frederic Bouvier said: To bring fgrun to 1.0 quality grade, and after receiving suggestions from Curt, I am now planning to add basic options to the wizard instead of keeping them hidden behind the Advanced button. Maybe by reducing the size of the command line textfield ( it could also be move to the Advanced section ). For the moment, my shortlist for basic options is : --geometry ( with a combo box of standard resolutions ) --time-of-day --(en/dis)able-game-mode --(en/dis)able-random-objects --(en/dis)able-ai-models --(en/dis)able-auto-coordination --(en/dis)able-real-weather-fetch --(en/dis)able-horizon-effect --(en/dis)able-enhanced-lighting --(en/dis)able-specular-highlight and optionally --atlas ( with default options ) --3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) --multiplayer I also want to have better resizing to have a more professional look. Also it would be nice to be able to fetch and install aircraft and scenery directly from the master server ( a add new button that connect via http ). Maybe it would require that the script that generate the aircraft download page also generate an XML file that could be remotely parsed to ease aircraft selection. Comments welcome This sounds great. A couple things I could add: 1. Make the label for the game mode check box say Game Mode (Full screen) as many non-developers don't understand what game mode means. 2. Include the geometry in an easy place and make it two textboxes so to look something like this: Length [ ] X Width [ ], then let the app concact the string. 3. It would be nice to specify default values at build time. On a system that has no fgrun.prefs, the c172p should come up selected and the KSFO airport should come up selected. We could change those if they were handled as build parameters. Basically fgrun should have something set there instead of nothing. I understand that flightgear will use its own defaults, this is just for user interface value. Alternatively (I'm not familiar with how fltk works) maybe we could install a static fgrun.prefs at a system wide level (/etc on linux, /windows/system32 on windows) and fall back to that if the local user copy does not exist. 4. The view target offsets (if they are available) might help with the model preview window. Right now the aircraft with origin at the nose are rotating about the nose which looks a little odd. Also, I don't know if anyone noticed but the b105 from 0.9.8 is a tiny little spec in the preview window. I haven't checked but I think that there might be a renegade vertex in the model hanging out several hundred units from the origin. Bugs: There are a couple bugs or at least they were there a week or so ago. One is just a mapping typo where latitude goes into both latitude and altitude. The other is under linux the fg-root and fg-scenery parameters don't get saved and passed on to fgfs (no prefs.set done) unless you hit previous to display page[0] (the function that processes page[0] saves those strings). It is great to see more work going into this excellent program. I'll download cvs and test what your doing and maybe help with a couple things. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Stewart Andreason wrote: Jim Wilson wrote: There are a couple bugs or at least they were there a week or so ago. One is just a mapping typo where latitude goes into both latitude and altitude. The other is under linux the fg-root and fg-scenery parameters don't get saved and passed on to fgfs (no prefs.set done) unless you hit previous to display page[0] (the function that processes page[0] saves those strings). Ah, is this why fgfs get stuck in a freezing loop, when I give latitude and longitude parameters at the command line? (Tries a few more runs) Ah! that's it. If I give a --lat that is less than the ground elevation, it freezes in a loop. and ignores the --altitude parameter. I believe I reported this Jan.11, but had not figured out the exact conditions that triggered it. Thanks Jim. A serious bug. I can explain the bug to you. If you specify a lon/lat that lies on the *exact* border between two tiles (i.e. --lat=90 --lon=45) then at startup the ground intersection code can fail. This means that the scenery subsystem never returns a valid groud elevation. Now the problem is that the flight dynamics model *needs* to know the ground elevation before it can position the aircraft. Complicating the matter is that when the FDM is first initialized the tiled scenery loader may not have the current tile loaded yet. So the FDM doesn't know if it's in a dead lock state or if it just needs to wait a bit longer for the threaded tile loader to catch up. The solution would be to make the ground intersection code more robust to this boundary condition, but I believe that might be burried deep in plib. 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] fgrun improvements
Curtis L. Olson writes:
Stewart Andreason wrote:
Jim Wilson wrote:
There are a couple bugs or at least they were there a week or so
ago. One is
just a mapping typo where latitude goes into both latitude and
altitude. The
other is under linux the fg-root and fg-scenery parameters don't get
saved and
passed on to fgfs (no prefs.set done) unless you hit previous to display
page[0] (the function that processes page[0] saves those strings).
Ah, is this why fgfs get stuck in a freezing loop, when I give
latitude and longitude parameters at the command line?
(Tries a few more runs)
Ah! that's it. If I give a --lat that is less than the ground
elevation, it freezes in a loop. and ignores the --altitude parameter.
I believe I reported this Jan.11, but had not figured out the exact
conditions that triggered it.
Thanks Jim.
A serious bug.
I can explain the bug to you. If you specify a lon/lat that lies on the
*exact* border between two tiles (i.e. --lat=90 --lon=45) then at
startup the ground intersection code can fail. This means that the
scenery subsystem never returns a valid groud elevation. Now the
problem is that the flight dynamics model *needs* to know the ground
elevation before it can position the aircraft. Complicating the matter
is that when the FDM is first initialized the tiled scenery loader may
not have the current tile loaded yet. So the FDM doesn't know if it's
in a dead lock state or if it just needs to wait a bit longer for the
threaded tile loader to catch up.
The solution would be to make the ground intersection code more robust
to this boundary condition, but I believe that might be burried deep in
plib.
This might help
hitlist.cxx
inline static bool IN_RANGE( sgdVec3 v, double radius ) {
-return ( sgdScalarProductVec3(v, v) (radius*radius) );
+return ( sgdScalarProductVec3(v, v) = ((radius*radius) +FLT_EPSILON) );
}
but I don't see where setting the lat less then the ground elevation
has any bearing on this this sounds more like a parsing error
Norman
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] fgrun improvements
Norman Vine said: but I don't see where setting the lat less then the ground elevation has any bearing on this this sounds more like a parsing error Norman Well, yeah, fgrun still needs to be fixed. Just the same, fgfs should not loop because of a command line entry if at all possible. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Curtis L. Olson wrote: I can explain the bug to you. If you specify a lon/lat that lies on the *exact* border between two tiles (i.e. --lat=90 --lon=45) then at startup the ground intersection code can fail. This means that the scenery subsystem never returns a valid groud elevation. Oh. I didn't think of that possibility. Need to add 0.01 to the lat|lon if mod()== .00 to fix it. Stewart ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Friday, 21 January 2005 14:59, Frederic Bouvier wrote: I forgot this one. It is not an improvement though, rather a fix ;-) The scenery scan is done every time and is very long although it is threaded and doesn't prevent you to launch flightgear. Curt suggested to show all the content of apt.dat.gz and check the availability afterward. I am now thinking to check only against the first level of directories to see if they lie in an existing 10x10 chunk ( eventually with special case for the 2 1x1 chunks of the base package ). And rely more on the refresh button already present than a systematic scan. Why not store the results of the scan and allow the user to rebuild the DB manually at a later stage? New users will 99% of the time run FG without installing extra scenery so the initial DB build will be VERY quick. Then when users add more scenery at a later stage they can build a new DB manually. I wrote this functionality into an app I was busy coding before I got sidetracked with other projects. http://surgdom.hollosite.com/flightgear/fg_central/index.html Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
Jim Wilson wrote : Norman Vine said: but I don't see where setting the lat less then the ground elevation has any bearing on this this sounds more like a parsing error Norman Well, yeah, fgrun still needs to be fixed. The fix is in CVS -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
