Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hi, I'm not sure whether emmisive, specular and diffuse lighting might give a different result here. Hmm, I don't think things are that dramatic... Admittetly, the following thoughts apply only to local (per-texel) image differences, but the big picture shoudln't be worse of. The specular term of a local reflection model normally does not depend on the object surface color, it merely emulates a highlight. Diffuse lighting could amplify a visual error locally if the local contribution of all light sources is larger than 1 (I assume emissiveness is just a constant light contribution term, similar to ambient). For a given wavelenght: diffuse_exact = min(1.0, lossless_surface_color*light_contributions) diffuse_lossy = min(1.0, lossy_surface_color*light_contributions) It follows that (diffuse_exaxt - diffuse_lossy) = (lossless_color - lossy_color)*light_contributions I.e., the difference image is scaled by the light source contributions. So, only if an area is strongly lit (contribution 1), artefacts will become more noticeable than in an unmodulated view of the image. Also keep in mind that most image differences will probably be in the same ballpark as the discretisation error; so the same problem presents itself with lossless textures, but probably in a less structued and therefore less noticeable manner. You just can't get dynamic range where there wasn't, same goes for spatial resolution. Don't take my musings as gospel, though :-) bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 01:44, Manuel Massing wrote: The real problem is that it's hard to get detailed textures for the whole world (and storage hungry!!). What I'd like to experiment with later on is to let a classifier run over the globally available 28.5m landsat textures, and use the resulting classifications to generate missing detail at runtime. But first things first... I don't see why we have to limit ourselves to *having* to have world coverage for the engine to be useful. This engine could be used to display synthetically generated textures which are pre-built along a specific flight path. One could build corridors of scenery from departure to destination before the flight or we could use the terrain engine to display synthetic scenery that is generated on the fly (like FS2004). Or people may have access to free photo scenery for their country or area and wish to use it for VFR flight or for familiarization of areas around an airport before going for a real flight. I think there is a mindset that one has to have all the scenery installed on hard disk which is a waste of space. How many people fly in all the countries of the world with FlightGear on a regular basis? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+2tolhWtxOxWNFcRAhSsAJ9M+L4LFk/hCluZyd25wqn6NI1BywCfVZ2a g+aaUNBAv2s4EQtKHYHQ66I= =yPwY -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 12:54, Christian Mayer wrote: Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 13:49, Paul Surgeon wrote: On Saturday, 29 January 2005 12:54, Christian Mayer wrote: Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? Paul I am corrected once again ... Norman just pointed JPEG 2000 out to me which is open source (and royalty free for GPL projects) and far better than the standard JPEG most of us use. It uses state-of-the-art wavelet compression and some of the comparisons I've seen are incredible. It supports both lossless and lossy compression. Some comparisons : http://www.leadtools.com/SDK/Raster/Raster-Addon-JPEG2000-Example.htm http://www.geocities.com/ee00224/btp2.html It could be worthwhile looking into if we need to store large images. The SDK with source code is available at http://www.ermapper.com Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hello, Norman just pointed JPEG 2000 out to me which is open source (and royalty free for GPL projects) and far better than the standard JPEG most of us use. It uses state-of-the-art wavelet compression and some of the comparisons I've seen are incredible. It supports both lossless and lossy compression. Some comparisons : http://www.leadtools.com/SDK/Raster/Raster-Addon-JPEG2000-Example.htm http://www.geocities.com/ee00224/btp2.html It could be worthwhile looking into if we need to store large images. The SDK with source code is available at http://www.ermapper.com The terrain engine also supports the jasper JPEG2000 library. Unfortunately, the last time I tested, JPEG2000 decoding performed badly (in terms of runtime) compared to optimized JPEG decoding routines. cheers, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Surgeon schrieb: On Saturday, 29 January 2005 12:54, Christian Mayer wrote: Manuel Massing schrieb: Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html There's still no open source alternative to jpg when it comes to storage size and storage is the major issue when dealing with lots of satellite or aerial photos. I did a test with the 18 century crop texture : JPG : 1024x1024 @ 85% quality = 508.4 KB PNG : 512x512 @ level 9 compression = 630.4 KB Four times higher resolution with hardly any noticable loss in quality (even when zoomed in) and it still comes out with a smaller footprint than a PNG that is 4 times lower resolution. Sometimes size does count. What do you suggest as a replacement to JPG that will give a similiar footprint size? (I haven't read the Jpeg2000 stuff, so I don't know if it fixes the problem) The trouble with JPEG isn't that it's lossy (you need that for hight compression ratios) but that it uses an algorithm that is tuned to the human eye. For normal photographs that's great - for textures that get scaled, projected, sheared (sp?), lit, ... the uses assumptions dodn't hold anymore. An extreme example: when you use a very high compression rate you'll see the blocking artefacts. So you use a not so high compression and are hapy with the result. If you zoom into the picture you'll start to see the blocking again as the pixels got large enough. When you use that picture as an texture and fly low enough you are basically zooming into the picture. Same problem as above. So JPEG isn't usefull. So what's the solution? 1st: I don't know. 2nd: Use an compression that doesn't introduce visible artefacts (i.e. artefacts that can be shown by zooming, projections, lighting, etc.) One solution that might work could be wavelets. (This is where JEPG2000 gets interesting again). But the wavelets used would need to be choosen carefully. You could also try your own compression format (i.e. one that is simmilar to the wavelet approach). Roughly do: Convert your image/texture to HSV, convert the whole picture (not small blocks like JPEG) to frequency space (i.e. fourier transformation). Then discretisize that values. In our case the high frequency are very important (- high resolution) and the low frequencies hardly matter (- just a few bits). But doing this is an project of its own. Epecially when you need performance... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+4tRlhWtxOxWNFcRAmbmAJkBh9SWIogEMkNpJoVo/9btWjvxnwCgl2Pq lbln/KQ9xim9VXVZ3eI0p2Y= =zpQm -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Runway lighting - What happened to the newterrain engine?
Manuel Massing writes: It could be worthwhile looking into if we need to store large images. The SDK with source code is available at http://www.ermapper.com The terrain engine also supports the jasper JPEG2000 library. Unfortunately, the last time I tested, JPEG2000 decoding performed badly (in terms of runtime) compared to optimized JPEG decoding routines. The Jasper library is notoriously slow, You should at least test the ermapper library brfore you give up on JPEG2000 :-) Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hi, For normal photographs that's great - for textures that get scaled, projected, sheared (sp?), lit, ... the uses assumptions dodn't hold anymore. Why should projection, shearing, scaling be a problem? Wouldn't every JPEG image displayed on your computer screen would look lousy when looking at your display from an angle, if this was generally true? The problem here is resampling (as indeed happens with texture mapping). If you sample your textures incorrectly, things might look worse than expected, but nobody says it isn't possible to do things correctly. This is why I don't like the article you referenced; it sure has some valid points, but they are presented in a manner which is a bit across-the-board. Lighting can be more of a problem, but areas are more often dimmed than fully lit, so I'd assume the the difference (i.e. error) between lossless and lossy texture is also dimmed. The one thing that really looks crappy is JPEG-compressed normal maps. An extreme example: when you use a very high compression rate you'll see the blocking artefacts. So you use a not so high compression and are hapy with the result. If you zoom into the picture you'll start to see the blocking again as the pixels got large enough. If you zoom in even further, you will single out individual pixels. So JPEG isn't usefull. Well, I think it is. Is surely isn't optimal, but things don't look nearly as bad as one would assume after heaving read JPEG's are evil, too :-) One solution that might work could be wavelets. (This is where JEPG2000 gets interesting again). But the wavelets used would need to be choosen carefully. Maybe the gwic library would be worth a look... bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 15:10, Christian Mayer wrote: For normal photographs that's great - for textures that get scaled, projected, sheared (sp?), lit, ... the uses assumptions dodn't hold anymore. An extreme example: when you use a very high compression rate you'll see the blocking artefacts. So you use a not so high compression and are hapy with the result. If you zoom into the picture you'll start to see the blocking again as the pixels got large enough. When you use that picture as an texture and fly low enough you are basically zooming into the picture. Same problem as above. So JPEG isn't usefull. Who said we have to use high compression levels? A JPEG with 95% quality does not display ANY blocking artifacts whatsoever yet is still 1/4 the size of a compressed PNG. Even when viewed at 1600% i could still not spot any blocking or banding. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Paul Surgeon wrote: I don't see why we have to limit ourselves to *having* to have world coverage for the engine to be useful. Yes, could the 10x10 degree sections be a mixture of: most made with the terragear engine, and some made with other engines? Perhaps depending on complexity, population density, popularity... I think there is a mindset that one has to have all the scenery installed on hard disk which is a waste of space. How many people fly in all the countries of the world with FlightGear on a regular basis? Stuck with a modem, I'd rather have a big hard drive and ready made scenery. Yes, I'm sure there are plenty of users who are happy with the current scenery engine and one of the advantages it has is that there is no paging of huge textures while flying. This allows for high speed flights without any pausing and can also be run on older hardware or where CPU cycles are best used elsewhere like instrument updates or FDM's. Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey scenery tiles because it couldn't build and page the textures fast enough. :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be very much appreciated. Yes, I agree. Could the scenery engine choose to load tiles at high ground speed, and then add the higher resolution texture engine at low speed? in the same way trees are only added when close enough to the ground. Or would this blending of 2 engines slow down the frame rate? Stewart ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Christian Mayer wrote: Manual Massing wrote: Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Andy Ross a écrit : Christian Mayer wrote: Manual Massing wrote: Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. It is still true that JPEG have no alpha channel, so not all textures could be converted. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Frederic Bourvier wrote: It is still true that JPEG have no alpha channel, so not all textures could be converted. Yes. Although the loader could play tricks like storing the alpha channel in a separate grayscale image. And I believe the already-mentioned jpeg2000 format does support 4-channel images. Many of the alpha images are actually poor choices for jpeg anyway, as the cutouts often have fine detail / high frequency shapes. But the point wasn't that jpeg was perfect for everything, just that refusing to use it where appropriate was silly. Especially for the terrain textures, it works really, really well. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hello Oliver, There is a trick to create textures with a 15 m resolution based on landsat data: http://www.terrainmap.com/rm29.html yes, fusing the panchromatic channel is a nice option. Ideally, one should devise an algorithm which can do the fusing at runtime (e.g. in the pixel shaders), so that the color information for the panchromatic channel doesn't need to be stored redundantly. BTW: Is it possible to use this classifier to create a new vector map with a larger landcover variety than Vmap0? well, the classifier you are referring to does not (yet) exist :-) But I know a graduand here at the university who is working on such a thing... I'll have to ask him how robust and usable it is (and if we could use it). I know it's supervised, so theoretically you should be able to train it all the classes you want, but that doesn't mean the classification will be robust. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Ross schrieb: Christian Mayer wrote: Manual Massing wrote: Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. Do you know: http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. I'm not against lossy compression. But JPEG hasn't the best algorithm for our use. JPEG2000 might, but I don't know enough about it. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Usually is any lossy format for inbetween dumb. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. This a point for lossy compression, not one for JPEG... One important point to remember is, that every lossy compression can compresse some data exact (the decompressed data...). So when we find a compression algorithm that creates decompressed data that is good enough for us, we can use it (even when the compressed data is in JPEG format). For our case that compressor must not rely on special optical tricks (because these get destroyed when they are used as an texture). If we find an JPEG compressor that fullfills this requirement, it's fine. If we don't, we need a different format. (If we find one, there's still a possible problem: people who don't know this special requirement are likely to submit wrongly generated files...) As only these special cautions allow one to use JPEGs, it's much saver to say: kids, don't try that at home! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+9HDlhWtxOxWNFcRAp0QAJ9MHzxlU0dvXQjIoOtBWXT3jtoz+gCfbliO bUCWTF+HZdZs7as8h3NWwv8= =1us6 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Martin schrieb: On Saturday 29 Jan 2005 17:39, Frederic Bouvier wrote: Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. It is still true that JPEG have no alpha channel, so not all textures could be converted. -Fred So on the same merit, how about PNG? On average you get about 1/3 the size of the SGI file while still being loss-less and keeping the alpha channel. PNG are fine (and should be our first choice as they are perfect for most of our textures) - but they aren't lossy. So you'll never get as good results as JPEG / JPEG2000 / ... will give you. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+9KelhWtxOxWNFcRAtgQAKCAT7HN4HeupuKrKdu0U9b6a++oMQCgj0kf HYSTy3j8bK6+nq849z0VEoI= =yHvY -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Saturday, 29 January 2005 19:39, Frederic Bouvier wrote: It is still true that JPEG have no alpha channel, so not all textures could be converted. There is no reason why the alpha channel cannot be shipped in a separate 8 bit bitmap of some sort with the JPEG just providing the color map. I've seen this done before to save space or bandwidth in commercial projects. It's really easy to combine the two images while loading them into RAM. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Christian Mayer wrote: For our case that compressor must not rely on special optical tricks (because these get destroyed when they are used as an texture). All lossy compressors rely on special optical tricks, that's the point. If all the data was equally important, you couldn't lose any of it without damaging the image. This is where Steve is overgeneralizing. Simply using an image as a texture (which is just a picture intended for viewing) does *not* destroy anything important. Yes, jpeg has artifacts that you need to be aware of. No, 3D texturing doesn't do anything magical to them other than stretch/shrink and downsample them. This is painfully simple to test. Take the terrain textures, convert them to jpeg, re-convert them to sgi+, fire up fgfs and take a screenshot. If you can see a difference, post a screenshot pair pointing out how awful jpeg is. I give 100:1 odds that no one can come up with such a situation. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Andy Ross wrote: All lossy compressors rely on special optical tricks, that's the point. If all the data was equally important, you couldn't lose any of it without damaging the image. This is where Steve is overgeneralizing. Simply using an image as a texture (which is just a picture intended for viewing) does *not* destroy anything important. Yes, jpeg has artifacts that you need to be aware of. No, 3D texturing doesn't do anything magical to them other than stretch/shrink and downsample them. I'm not sure whether emmisive, specular and diffuse lighting might give a different result here. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
Ampere K. Hardraade wrote: How about not rendering ground textures at night? Has this been done yet? I don't think turning off texturing makes any difference on common hardware (including my O2, it will give me 1fps more). The code to draw untextured terrain has been removed some time ago. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Runway lighting
Erik Hofman wrote: The code to draw untextured terrain has been removed some time ago. Saddly :-( Norman ___ 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman Sent: Friday, January 28, 2005 3:58 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Runway lighting Ampere K. Hardraade wrote: How about not rendering ground textures at night? Has this been done yet? I don't think turning off texturing makes any difference on common hardware (including my O2, it will give me 1fps more). The code to draw untextured terrain has been removed some time ago. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
Roman Grigoriev wrote: 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 ;-) Roman, could you post an URL to the changes you have made to FlightGear/SimGear? I would like to take a look at it. Unfortunately the last time I looked at your patches the code style didn't match that of FlightGear very well and therefore the code was hard to read. But if we can integrate something like this in SimGear (preferably) then it might be worth a shot. Erik ___ 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: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Friday, January 28, 2005 1:34 AM Subject: Re: [Flightgear-devel] Runway lighting Roman Grigoriev wrote: 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 ;-) Roman, could you post an URL to the changes you have made to FlightGear/SimGear? I would like to take a look at it. Unfortunately the last time I looked at your patches the code style didn't match that of FlightGear very well and therefore the code was hard to read. But if we can integrate something like this in SimGear (preferably) then it might be worth a shot. Ok I test my changes with flightgear cvs and send you. It took day or two. Bye Roman Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 January 2005 05:14, Curtis L. Olson wrote: I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. 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 - What happened to the new terrain engine?
Oliver C. wrote: On Friday 28 January 2005 05:14, Curtis L. Olson wrote: I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. It's not that easy. The plib scene graph lib is woven throughout our code. 3d models of aircraft, 3d cockpits, all the animation code is hardwired into plib structures. We will look into Manual's new terrain engine, but there again, he may have a few small areas available to fly in, but it's not just a drop in replacement that gives us the whole world. From what I've seen it does a nice job of drawing quality terrain. But it's unclear how well that will scale to the entire world. Certainly the data sizes to represent the whole world for this engine will be extreme. Probably 100x what our current approach uses. This is some *very* difficult stuff and we need to move slowly and cautiously to avoid breaking everything. 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 - What happened to the new terrain engine?
On Friday 28 January 2005 18:20, Curtis L. Olson wrote: Oliver C. wrote: On Friday 28 January 2005 05:14, Curtis L. Olson wrote: I'm told there is a way to do this with shaders, but plib/ssg doesn't support shaders. :-( Curt. What happended about Manual Massing's new alternative terrain engine? http://www.mail-archive.com/flightgear-devel@flightgear.org/msg29480.html Does it support shaders and does it get now integrated into Flightgear? As far as i understood, it is using its own scene graph so we would be independent from the plib library and this allows us to use VBO, shaders and multitexturing without the need to wait for an update of the plib library. It's not that easy. The plib scene graph lib is woven throughout our code. 3d models of aircraft, 3d cockpits, all the animation code is hardwired into plib structures. Are there plans or better a planned release date when the missing features will get added into plib? We will look into Manual's new terrain engine, Nice to hear. :) but there again, he may have a few small areas available to fly in, but it's not just a drop in replacement that gives us the whole world. From what I've seen it does a nice job of drawing quality terrain. But it's unclear how well that will scale to the entire world. Certainly the data sizes to represent the whole world for this engine will be extreme. Probably 100x what our current approach uses. But this is because of the landsat textures. I was more interested in the engine itself. At the moment we use generic textures to cover the whole world. This approach is okay, because it allows us to keep the scenery data small. But the thing that is missing at the current engine is multi texturing. With multi texturing we could still use generic textures but the scenery would look more diversified because multitexturing allows us to add random distorting textures to the base textures, the result is more variety. MS does use the same approach at their FS2004, but we can't use this at the moment because plib and the existing FG engine does not (AFAIK) support multitexturing. The other nice things which the alternate Engine allows and are good to have are the imposter in the background, VBO rendering etc. So i was more thinking about using this new engine to render generic multitextured sceneries instead of large landsat images. But of course it would also be good to be able to use landsat images for selected areas like large cities. This is some *very* difficult stuff and we need to move slowly and cautiously to avoid breaking everything. I understand. Are there ways to follow the changes and engine integration? 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 - What happened to the new terrain engine?
Oliver C. wrote: Are there plans or better a planned release date when the missing features will get added into plib? You'll have to ask the plib people. Steve is very persnickety about this section of the code and I suspect he may not allow significant changes unless he does them himself, especially in the area of shaders. And he is another extremely busy person so who knows when that will ever happen. But this is because of the landsat textures. I was more interested in the engine itself. At the moment we use generic textures to cover the whole world. This approach is okay, because it allows us to keep the scenery data small. But the thing that is missing at the current engine is multi texturing. With multi texturing we could still use generic textures but the scenery would look more diversified because multitexturing allows us to add random distorting textures to the base textures, the result is more variety. MS does use the same approach at their FS2004, but we can't use this at the moment because plib and the existing FG engine does not (AFAIK) support multitexturing. The other nice things which the alternate Engine allows and are good to have are the imposter in the background, VBO rendering etc. So i was more thinking about using this new engine to render generic multitextured sceneries instead of large landsat images. But of course it would also be good to be able to use landsat images for selected areas like large cities. Be a bit careful here. I've seen a demo of Manuel's engine and it was extremely impressive. However, it was only for a very small area. It's unclear if he's put any thought at all into paging textures or terrain data in real time without pauses. I also don't know how he handles his coordinate system and if he suffers map maker distortion problems, or if he can maintain a seamless wgs-84 oblate ellipsoid earth? If he has all these things, then that's wonderful, he has done an impressive piece of work. I'm not trying to be critical here, I'm just pointing out that this is *very* difficult stuff. It's one thing to do a nice little demo, it's something else entirely to tackle all the issues of doing this in a full sim where you are trying to model the world seamlessly. I understand. Are there ways to follow the changes and engine integration? I assume when something is workable, it will be in CVS. 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 - What happened to the new terrain engine?
Curtis L. Olson wrote: If he has all these things, then that's wonderful, he has done an impressive piece of work. I'm not trying to be critical here, I'm just pointing out that this is *very* difficult stuff. It's one thing to do a nice little demo, it's something else entirely to tackle all the issues of doing this in a full sim where you are trying to model the world seamlessly. Let me just chime in to agree with Curt. Some of the long-timers here will remember that one of the first things I wanted to do when I discovered FlightGear was write a modern terrain engine to replace the tile system we're currently using. Since then, I've contributed an FDM and an extension language. No terrain. I spent the spring of 2003 working on my own project full time and produce a ton of working code. Until I got to the terrain engine, which I got partially working, then burned out. No terrain. It's hard, really. It's not impossibly hard, but the distance between something that works well as a demo and something that ships well as a product is very long. As with everything, really, the key here is integration. Make it work with FlightGear so we can test. Saying here is code, can we use it? just isn't enough. It needs to be here is a patch, try it and tell me what breaks. Until we get that far, there really isn't much to argue about. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hello,
As with everything, really, the key here is integration. Make it work
with FlightGear so we can test. Saying here is code, can we use it?
just isn't enough. It needs to be here is a patch, try it and tell
me what breaks. Until we get that far, there really isn't much to
argue about.
I completely agree with you on the integration part. I think the engine
is technically adequate for its intended purposes (i.e. satellite-textured
landscapes). If you have any questions concerning the technical side, feel
free to ask. In this light, its also important to see it as an alternative,
not a replacement, for the current scenery, because each engine will have its
own set of advantages and disadvantages.
By using an abstract API, a terrain engine could be choosen at runtime.
But it will definitely take some work to abstract out the terrain engine.
The good thing is, such an abstract API would make the scenery subsystem
more modular and easier to use than in its current, tightly coupled form.
I have attached what I could imagine as a useable terrain API (modulo
conflicts with reality :-)).
regards,
Manuel
/**
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful, but
* WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
* \short Abstract class to define the API for the terrain rendering subsystem.
*
* written by Manuel Massing, (c) 2004 by Manuel Massing
*/
#ifndef TERRAIN_H
#define TERRAIN_H
#include FDM/flight.hxx
#include string
using namespace std;
class GeocCoord;
/**
* \short Abstract class which defines an API for the terrain rendering subsystem.
*
* Offers methods for:
* - rendering detail management
* - Airport management
* - collision elevation queries
*/
class Terrain {
public:
enum RenderEntity {
trTerrain = 1,// The basic landscape
trRunways = 2,// Runway structures
trRunwayLighting = 4,// Runway lighting
trStaticGroundObjects = 8,// Landmarks, buildings, trees which were placed at scenery generation time
trDynamicGroundObjects = 16// Procedurally generated ground objects, e.g. trees, buildings
};
/**
* Prepare rendering for the given viewing paramaters and the
* configured detail levels.
*/
virtual bool update(FGViewer *viewer) = 0;
// Interface it with scene graph or via a render() method?
// Returning a scene-graph node is probably the better solution,
/**
* Render the terrain using the viewer position and the given rendering flags.
* \note that rendering entities which where disabled during the update() call (i.e. entities with a detail setting of zero) will not be rendered.
*/
virtual void render(RenderEntity renderFlags) = 0;
/**
* Return a scene-graph node which
*/
//SGNode *getSceneNode(RenderEntity flags);
/**
* Set the detail level for the indicated rendering entity.
*
* Valid range is 0 (disable rendering) to the value returned by getDetailLevels(enum Renderflags),
* which corresonds to maximum detail.
*
* \param RenderEntity
* \param detailLevel The desired detail level, in the range 0 to getDetailLevels(entitiy).
*/
virtual void setDetailLevel(RenderEntity entity, const unsigned int detailLevel) = 0;
/**
* A clear text (human-readable) explanation of detail level modalities.
* e.g. getDetailLevelFeatures(trTerrain, 1) could return
* Render terrain within 32 pixels accuracy.\n
* Disable texture mapping.\n
* Disable shading.\n
*
* This is needed to offer an abstracted but descriptive representation for the user interface.
*/
virtual string getDetailLevelFeatures(RenderEntity entity, int detail_level) const = 0;
/**
* Indicates whether airport definitions can be dynamically added at runtime.
* Otherwise, the terrain implementation only supports pre-compiled airports
* (i.e. airports included at terrain-build time).
*/
virtual bool supportsDynamicAirports() const = 0;
/**
* Add specified airport.
*
* Fails if airport already exists or dynamic airports are not supported.
*
* \param ID Zero-terminated string of the airport identifier
* \param airport An instance holding all the relevant information about the structure of the airport to be added.
*
* \returns true on success, otherwise false.
*/
//virtual bool addAirport(char *ID, const Airport airport) = 0;
virtual bool
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday, 28 January 2005 22:14, Manuel Massing wrote: I completely agree with you on the integration part. I think the engine is technically adequate for its intended purposes (i.e. satellite-textured landscapes). If you have any questions concerning the technical side, feel free to ask. I would love to see an alternative terrain engine that supports satellite/aerial images. I do have a few questions though : Does the current code that you have handle texture paging? What sort of texture resolutions will it be able to scale down to? (meters/pixel) How is the mipmapping handled (if it currently uses mipmaps)? What will the maximum visual range be? Are you using any sort of texture compression like S3TC/DXTC to save space in VRAM? In this light, its also important to see it as an alternative, not a replacement, for the current scenery, because each engine will have its own set of advantages and disadvantages. Yes, I'm sure there are plenty of users who are happy with the current scenery engine and one of the advantages it has is that there is no paging of huge textures while flying. This allows for high speed flights without any pausing and can also be run on older hardware or where CPU cycles are best used elsewhere like instrument updates or FDM's. Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey scenery tiles because it couldn't build and page the textures fast enough. :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be very much appreciated. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 Jan 2005 21:21, Paul Surgeon wrote: Yes, I'm sure there are plenty of users who are happy with the current scenery engine and one of the advantages it has is that there is no paging of huge textures while flying. This allows for high speed flights without any pausing and can also be run on older hardware or where CPU cycles are best used elsewhere like instrument updates or FDM's. Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey scenery tiles because it couldn't build and page the textures fast enough. :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be very much appreciated. Paul One of the drawbacks of *photographic* scenery is manky shadows on flat buildings / bridges etc. The 'suspension of disbelief' tends to be better when the scenery is less 'realistic' but has no shadows etc to spoil the mental picture. I believe that satellite photos can be used well in certain circumstances but on the whole 'blanket coverage' can look far worse - you literally get the feeling that you are flying over a 'polaroid'. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Hello, I do have a few questions though : Does the current code that you have handle texture paging? Yes, textures and geometry are paged and decompressed asynchronously in the background (seperate thread). The engine supports image compression to save IO (and possibly bus) bandwith, e.g. JPEG and S3TC compression. The first maybe quite taxing on the CPU, so we usually only use JPEG for the finest detail level textures, which account for most of the data, and S3TC for the lower detail levels. What sort of texture resolutions will it be able to scale down to? (meters/pixel) The rendering is output sensitive, so only visible detail accounts for scene complexity. However, updates (i.e. pagingdecompressing) can be a bottleneck; if you're moving fast, you could get into trouble trying to update all the high-res textures. The easy solution is to limit texture and geometry detail as a function of speed - i.e. don't display 1 m textures at mach 5 (motion blur!). The real problem is that it's hard to get detailed textures for the whole world (and storage hungry!!). What I'd like to experiment with later on is to let a classifier run over the globally available 28.5m landsat textures, and use the resulting classifications to generate missing detail at runtime. But first things first... How is the mipmapping handled (if it currently uses mipmaps)? Well, in a way, the texture LODs emulate aspects of mipmapping. The ground texture is partitioned in a quadtree scheme, where each quadtree node holds part of the texture at constant resolution (e.g. 128x128 pixels). The root covers the whole texture domain, and children always cover their respective quarter of the parents domain. So, effectively, each parent is a downsampled version of its children. The LODs are choosen in a way which ensures that supersampling orthogonal to the viewer is limited by a factor of 2 (the factor can be higher along the viewing direction, however). Together with anistotropic filtering, this gives very good results. What will the maximum visual range be? Also depends on the available detail, resolution, permitted screen space error - hard to tell, but I think nothing to worry about. For example, I get good performance (1024x768, Duron 1GhZ, GeForce3, Mach2) without limiting visibility for a whole UTM-zone dataset (with 28.5 m textures, normal maps and SRTM3 elevation), that should be a few hundred kilometers of visual range. As stated earlier, the nearer (fast-moving) detail is more problematic than the distant scenery because of the frequent updates; for the same reason, hard turns are evil :-) hope to have answered your questions, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
The real problem is that it's hard to get detailed textures for the whole world (and storage hungry!!). What I'd like to experiment with later on is to let a classifier run over the globally available 28.5m landsat textures, and use the resulting classifications to generate missing detail at runtime. But first things first... There is a trick to create textures with a 15 m resolution based on landsat data: http://www.terrainmap.com/rm29.html BTW: Is it possible to use this classifier to create a new vector map with a larger landcover variety than Vmap0? 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 - What happened to the new terrain engine?
On Friday 28 January 2005 19:44, Curtis L. Olson wrote: Oliver C. wrote: Are there plans or better a planned release date when the missing features will get added into plib? You'll have to ask the plib people. Steve is very persnickety about this section of the code and I suspect he may not allow significant changes unless he does them himself, especially in the area of shaders. And he is another extremely busy person so who knows when that will ever happen. That sounds not so good. :( Are there alternative ways when this is taking to long like a special plib specially designed for the needs of flightgear? (in other word, a fork?) Be a bit careful here. I've seen a demo of Manuel's engine and it was extremely impressive. However, it was only for a very small area. It's unclear if he's put any thought at all into paging textures or terrain data in real time without pauses. I also don't know how he handles his coordinate system and if he suffers map maker distortion problems, or if he can maintain a seamless wgs-84 oblate ellipsoid earth? If he has all these things, then that's wonderful, he has done an impressive piece of work. I'm not trying to be critical here, I'm just pointing out that this is *very* difficult stuff. It's one thing to do a nice little demo, it's something else entirely to tackle all the issues of doing this in a full sim where you are trying to model the world seamlessly. I understand. Are there ways to follow the changes and engine integration? I assume when something is workable, it will be in CVS. Thank you for answering all my questions. 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
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] 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] 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] 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
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] 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] 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
[Flightgear-devel] Runway lighting
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. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] runway lighting
On Friday 18 October 2002 09:17 pm, David Megginson wrote: John Check writes: The last time we had KSFO with lights in there it had some problems too. I think it's worth the tradeoff but if you think it's going to break anything I can hold off. I'd prefer to put in a complete rebuild from William Riley if he has time to redo the base package. unlurk I have been busy lately (who hasn't?) but can find the time to do a base Scenery rebuild. What is the status of the lighting? Should I do a rebuild this weekend? I'll have to check the back messages as I haven't been following along as closely as I would like. :( I am in the office with the door locked and the phone being ignored so I will do some tinkering today (Saturday). Hehehe Regards, Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
William L. Riley writes: unlurk I have been busy lately (who hasn't?) but can find the time to do a base Scenery rebuild. What is the status of the lighting? Should I do a rebuild this weekend? I'll have to check the back messages as I haven't been following along as closely as I would like. :( I am in the office with the door locked and the phone being ignored so I will do some tinkering today (Saturday). Hehehe It would be wise to wait a week or two before doing a complete rebuild of the scenery, in case Curt needs to change anything, but a rebuild of w130n30 (or at least the area around KSFO) would be very welcome this weekend. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Saturday 19 October 2002 03:30 pm, [EMAIL PROTECTED] wrote: It would be wise to wait a week or two before doing a complete rebuild of the scenery, in case Curt needs to change anything, but a rebuild of w130n30 (or at least the area around KSFO) would be very welcome this weekend. I am working on the base Scenery rebuild and hope to have something tonight (CST). Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
The base scenery package was rebuilt tonight and is available for download. http://www.randdtechnologies.com/fgfs/newScenery/ The rebuild went very smoothly so there is probably some huge glaring error that I missed. ;) Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Saturday 19 October 2002 7:42 pm, William L. Riley wrote: The base scenery package was rebuilt tonight and is available for download. http://www.randdtechnologies.com/fgfs/newScenery/ The rebuild went very smoothly so there is probably some huge glaring error that I missed. ;) Wm ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Saturday 19 October 2002 7:42 pm, William L. Riley wrote: The base scenery package was rebuilt tonight and is available for download. http://www.randdtechnologies.com/fgfs/newScenery/ The rebuild went very smoothly so there is probably some huge glaring error that I missed. ;) Wm Looks good to me, but what do I know. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
Martin Spott writes: but in reality not every airport _has_ lightning. Mybe it would be appropriate to stick to the information on airport lightning that is present in the airport database, It's already there. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
John Check writes: If you want to fly this yourself, you can grab: http://www.flightgear.org/tmp/KSFO.btg.gz Does anybody have a copy or a proper link? it seems to be 404. My fault, didn't push my change out to the web server ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
Martin Spott writes: Curt, No one commented on my last runway lights message so I figured I'd send some more picts of the latest: Yesterday night it was simply too late to give appropriate comment I am _really_ amazed. In my eyes this this is the most valuable visual feature in FlightGear since I'm watching this project. Essentially the state of things is that if we regen all the airports they will all get as much lighting as I've implimented. but in reality not every airport _has_ lightning. Mybe it would be appropriate to stick to the information on airport lightning that is present in the airport database, Right, our database does have lighitngn information, and the airport generator honors it. If you fly around SFO with the new lighitng you'll see an ALSF-II approach, an SSALS, and SSALR, and a couple REIL's. Also you'll see some runways with centerlines, some without, and some runways have touchdown zone lighting. Our world (once I finishe with the other lighting schemes, and once it's regenerated) will be as close to reality as our database allows. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
Curtis L. Olson writes: Our world (once I finishe with the other lighting schemes, and once it's regenerated) will be as close to reality as our database allows. Have you patched TerraGear to eliminate runway edge lights for unlighted runways? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
David Megginson writes: Curtis L. Olson writes: Our world (once I finishe with the other lighting schemes, and once it's regenerated) will be as close to reality as our database allows. Have you patched TerraGear to eliminate runway edge lights for unlighted runways? Well, patched maybe isn't the best word, but essentially yes. Now we only generate the runway lighting schemes that we understand: ASLF-II, MALS, MALSF, MALSR, SSALS, SSALF, SSALR, REIL ... Threshold, edge, and center line lighting are seperate entries in our database and those are generated accordingly. There are still more approach lighting arrangements that need to be implimented ... Robin has a list of 20-25 in his docs. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
Curtis L. Olson [EMAIL PROTECTED] wrote : David Megginson writes: Curtis L. Olson writes: Our world (once I finishe with the other lighting schemes, and once it's regenerated) will be as close to reality as our database allows. Have you patched TerraGear to eliminate runway edge lights for unlighted runways? Well, patched maybe isn't the best word, but essentially yes. Now we only generate the runway lighting schemes that we understand: ASLF-II, MALS, MALSF, MALSR, SSALS, SSALF, SSALR, REIL ... Threshold, edge, and center line lighting are seperate entries in our database and those are generated accordingly. There are still more approach lighting arrangements that need to be implimented ... Robin has a list of 20-25 in his docs. There are airports that have intermitent, remotely switchable with onboard radio, lighting. When you arrive in the vicinity of such an airport, you push (sorry, lack of english vocabulary here) say 7 times in 5 seconds on the radio button to switch it on. It switch off automatically after 15 minutes or you can switch it off with 9 pushes. Is there description for such an arrangement in the airport database? Usually, details on this are in the Sectional Chart. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
Frederic BOUVIER writes: There are airports that have intermitent, remotely switchable with onboard radio, lighting. When you arrive in the vicinity of such an airport, you push (sorry, lack of english vocabulary here) say 7 times in 5 seconds on the radio button to switch it on. It switch off automatically after 15 minutes or you can switch it off with 9 pushes. ARCAL lighting is very common in Canada as well, and, I assume, at smaller airports in the U.S. As far as I can tell, it is not supported in the current database; you can look at docs-mini/AptNavFAQ.FlightGear.html in the FlightGear distro for details. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
John Check writes: On Friday 18 October 2002 8:35 am, Curtis L. Olson wrote: John Check writes: If you want to fly this yourself, you can grab: http://www.flightgear.org/tmp/KSFO.btg.gz Does anybody have a copy or a proper link? it seems to be 404. My fault, didn't push my change out to the web server ... Curt. Curt, What do you think about tossing this in the base package? Just wondering That's fine, although it's not elevated and has large gaps where it meets the surround terrain ... CUrt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
Curtis L. Olson writes: Yes, we have CAL and CAL-II in the database, but no ARCAL. ARCAL describes how the lights are activated, not their configuration; presumably, Calvert I and Calvert II approach lighting systems could be ARCAL, but since those are used (I think) mainly at military installations, I doubt they would be. On Canadian VNCs, airports with ARCAL lighting have an L with a box around it under the airport name. Clicking the microphone several times in fast succession turns the runway and taxiway lights on for a while (the beacon is always on). It would be a very dramatic effect to add to FlightGear. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
I would also like to add the ability to turn runway/approach lighting on/off from the instructor station (i.e. tower control). But that's step n+1 assuming I'm working on step n right now. Curt. David Megginson writes: Curtis L. Olson writes: Yes, we have CAL and CAL-II in the database, but no ARCAL. ARCAL describes how the lights are activated, not their configuration; presumably, Calvert I and Calvert II approach lighting systems could be ARCAL, but since those are used (I think) mainly at military installations, I doubt they would be. On Canadian VNCs, airports with ARCAL lighting have an L with a box around it under the airport name. Clicking the microphone several times in fast succession turns the runway and taxiway lights on for a while (the beacon is always on). It would be a very dramatic effect to add to FlightGear. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] runway lighting
John Check writes: Curt, What do you think about tossing this in the base package? Just wondering That's fine, although it's not elevated and has large gaps where it meets the surround terrain ... CUrt. John: Are you going to go ahead with this? When it gets in the base package (you do mean the develpment package?), are you going to post an announcement? I am going to try and build FGFS again with the new base package. Haven't had time to do this lately. But I want to wait for the runway stuff. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
On Friday 18 October 2002 7:13 pm, Jon Berndt wrote: John Check writes: Curt, What do you think about tossing this in the base package? Just wondering That's fine, although it's not elevated and has large gaps where it meets the surround terrain ... The last time we had KSFO with lights in there it had some problems too. I think it's worth the tradeoff but if you think it's going to break anything I can hold off. CUrt. John: Are you going to go ahead with this? When it gets in the base package (you I have to try it first. Yes, that would be the unstable (main) branch. You shouldn't need to do anything special. do mean the develpment package?), are you going to post an announcement? I Well, commits automagically generate posts to fg-cvslogs, but I'll give you a heads up. am going to try and build FGFS again with the new base package. Haven't had time to do this lately. But I want to wait for the runway stuff. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
John Check writes: The last time we had KSFO with lights in there it had some problems too. I think it's worth the tradeoff but if you think it's going to break anything I can hold off. I'd prefer to put in a complete rebuild from William Riley if he has time to redo the base package. I'm going to try building w130n30 and w080n40 myself tonight, but (for whatever reason) William's scenery always looks a little better than mine. I did a small experiment with the tile around CYOW, and the new lighting turned out extremely well, aside from two nit-picks: 1. I'm still getting a triangle with three points for each of the lights, both in 16bpp and 24bpp (usually called 32bpp). 2. The PAPI isn't functional yet, but I'm not sure that it's supposed to be. On all other points, *very* nice. If William doesn't have time, I may be able to contribute some temporary scenery; we don't want another case where the edges don't match up. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] runway lighting
No one commented on my last runway lights message so I figured I'd send some more picts of the latest: http://www.flightgear.org/tmp/rwy_lights3.jpg http://www.flightgear.org/tmp/rwy_lights4.jpg http://www.flightgear.org/tmp/rwy_lights5.jpg http://www.flightgear.org/tmp/rwy_lights6.jpg If you want to fly this yourself, you can grab: http://www.flightgear.org/tmp/KSFO.btg.gz Make sure to backup $fgbase/Scenery/w130n30/w123n37/KSFO.btg.gz and then copy this new one over top ... and make sure you have the latest flightgear cvs code. For more fun, you can try uncommenting the FG_EXPERIMENTAL_LIGHTING define in main.cxx and if you your card suppots the glPointLightEXT you can get slightly nicer points, at the expense of a large frame rate hit. Essentially the state of things is that if we regen all the airports they will all get as much lighting as I've implimented. Not all approach configurations are done. So far I have runway edge lights, touchdown zone lights, center line lights, REIL, ALSF-II, SSALS, SSALF, and SSALR. I also have VASI/PAPI correctly placed, but they don't read red/white correctly. This is enough to pretty much fully impliment KSFO minus taxiway lights. The lights are directional so it's fun to fly arouund and see them fade in and out ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lighting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *drools over keyboard* Very nice. But can you see the pole and light assemblies at daytime? :-) Thanks, David - -- If you give someone a program, you will frustrate them for a day. If you teach them how to program, you will frustrate them for a lifetime. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9r5G6ZOfFgbBAbXARAgbbAJ4lGGHZO+04RSiCz0TFY3tbF6T20gCbBkX3 Sk6gyl/37jhHFYOTFGXoIKs= =Bgbg -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Runway Lighting Questions
I've sent mail to Curt about this point already, but while I'm waiting, I thought I'd throw out the question to the list. I've patched FlightGear so that (a) runway edge lights are not visible from improbable distances (like 50km or more), and (b) runway edge lights are not visible at all while the sun is above the horizon, but haven't committed these patches yet. I'm currently applying a range limit of 12,000m (about 6nm) to the lights (the range is from the middle of each runway). Personally, I suspect that that might be far too generous, but I don't want to make the range too short for very long runways. What does everyone else think? This change is important for people using FlightGear to practice cross-country flying and navigation. The edge lights as they are right now make it far too easy to find an airport at great distances during the day. I'll commit the patches when I hear back from Curt, since the runway lighting is his baby. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Runway Lighting Questions
I'm currently applying a range limit of 12,000m (about 6nm) to the lights (the range is from the middle of each runway). Personally, I suspect that that might be far too generous, but I don't want to make the range too short for very long runways. What does everyone else think? All the edge lights I've seen so far are incredibly directional, because they burn a lot of electricity and directionality saves on your power bills. I'd estimate that HIRL is brighter than normal city lighting out to 10nm when aligned with the runway. In the transverse direction, I can barely see the lights when 0.5 nm away (i.e. on downwind) at some airports. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Runway Lighting Questions
On Sun, 7 Jul 2002, David Megginson wrote: patched FlightGear so that (a) runway edge lights are not visible from improbable distances (like 50km or more), and (b) runway edge lights are not visible at all while the sun is above the horizon, but haven't committed these patches yet. I think this (6 mi) is a bit too restrictive. Runway edge lights ARE visable from considerable distances, even during the daytime hours. (Sorry , don't have any exact distances tho). jj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
