Re: [Flightgear-devel] taxiway lights
On Monday 21 October 2002 11:14 pm, Curtis L. Olson wrote: I just added support for generating taxiway lights into terragear (with some corresponding changes in FlightGear) so I guess someone is going to have to regenerate the airports again. :-) Curt. Base package updated. http://www.randdtechnologies.com/fgfs/newScenery/ ftp://ftp.randdtechnologies.com/fgfs/baseScenery/current.tar.gz P.S. The taxiway lights are extremely dim on my setup, barely visible right at dusk/dawn and pretty much invisible after dark. Do I need to enable the experimental lighting in main.cxx? And yes, KOAK is still completely void of lights. :( Linux (2.4.19-gentoo-r9) Nvidia Geforce2 MX (driver 1.0.3123) plib,SimGear, FlightGear are recent CVS -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] taxiway lights
Curtis L. Olson wrote: I just added support for generating taxiway lights into terragear (with some corresponding changes in FlightGear) so I guess someone is going to have to regenerate the airports again. :-) How about doing the light generation at tile load time, instead of generation time? This would have big payoffs for maintenance -- someone could fix lighting configurations without regenerating the whole tile. My assumption would be that this process is pretty quick -- one hitlist computation per light -- and wouldn't impact performance noticeably. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] taxiway lights
Andy Ross writes: How about doing the light generation at tile load time, instead of generation time? This would have big payoffs for maintenance -- someone could fix lighting configurations without regenerating the whole tile. My assumption would be that this process is pretty quick -- one hitlist computation per light -- and wouldn't impact performance noticeably. Andy, I have thought about it, and there are advantages and disadvantages to both offline and runtime approaches. For now I went with the offline approach because (a) there were less technical issues to solve and (b) I was nervous about the possible runtime performance issues. There are hundreds of lights per airport and doing 100's of terrain intersections certainly would cause a noticable frame rate blip. Note that with the random ground cover objects and random ground cover lighting, we are doing a clever trick to avoid having to do any terrain intersections at all. This trick doesn't work for runway lighting. There is also a problem with doing terrain intersections on tiles that are freshly loaded, but haven't been fully pushed into the render pipeline yet. That's a technical issue we haven't solved yet, but we need to at some point. Also consider the case of an airport that lies on the corner of 4 tiles. When the first tile is requested and an airport is attached to that tile, the airport needs to be loaded. But, we would also need to somehow identify this situation and make sure the remaining tiles are also loaded so that the terrain intersections in the neighboring tiles also return valid results. Most likely if a tile intersection comes up with a void, that would trigger a tile load request for the missing void. But, we'd have to wait until that missing tile load is done, then redo the original intersection test and then keep going. This could be a substantial pause as we wait for additional tiles to load. Oh, and what if the 3 other tiles that we are suddenly forced to load, also have airports that span other tile boundaries and we are forced to load those first too. We could concievably have a nastly little cascading tile loading problem. Probably generally rare, but anyone want to take bets on whether or not it would happen someplace? This need for cascaded tile loading might also factor interestingly with our threaded tile loader ... the threaded tile loader code is something that I'd really rather not go out of my way to make more complex than it already is. Especially with threads, complexity usually equals bugs that are nearly impossible to track down. I'm doing a *lot* of wgs_84 math for positioning the lights -- things like start at point A and move 100' in the direction of the runway to arrive at point B. This also get's to be really expensive. There are probably lots of ways to optimize this and stay within a pixel or two error, but it's nice to be able to use accurate math and not have to worry about it. So there you go. A runtime approach is certainly possible, but there are quite a few significant issues that need to be considered and solved first, and the path of least resistance clearly took me down the offline route. 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] taxiway lights
William L. Riley writes: Base package updated. http://www.randdtechnologies.com/fgfs/newScenery/ ftp://ftp.randdtechnologies.com/fgfs/baseScenery/current.tar.gz P.S. The taxiway lights are extremely dim on my setup, barely visible right at dusk/dawn and pretty much invisible after dark. Do I need to enable the experimental lighting in main.cxx? That would help, but it's a big frame rate hit, probably unacceptably big. You might consider turning off all the lights in your room. There may be some monitor gamma issues. Also note that taxiway lights are most visible when you are nearly horizontal with them. If you are above them, they get nearly impossible to see. And yes, KOAK is still completely void of lights. :( Linux (2.4.19-gentoo-r9) Nvidia Geforce2 MX (driver 1.0.3123) plib,SimGear, FlightGear are recent CVS Is FlightGear recent as of yesterday/today ... never mind, it would have to be if you are seeing the taxiway lights in blue. Strange, I have no idea what's up with KOAK. When I generate it myself it works just fine. If the base package cvs get's updated, I can let you know if I see lights in your version of KOAK or not. 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] taxiway lights
On Tuesday 22 October 2002 03:32 pm, Curtis L. Olson wrote: One thing you could play with is this: Find line #493 in src/Objects/matlib.cxx tex_name = gen_taxiway_dir_light_map( 20, 20, 235, 155 ); Change the last number (155) which is the overall alpha for the light to a higher value. The number can be in the range of 0 - completely transparent to 255 - completely opaque. The larger the number (up to 255), the more visible the lights should be. You might try 200 for starters and then increase to 255. I changed the alpha up to 255 in matlib.cxx as suggested and can now see them fairly well. Are these single pixel lights? Maybe it is my Acer monitor that is the problem. ;) Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] taxiway lights
On Tue, 22 Oct 2002, William L. Riley wrote: I changed the alpha up to 255 in matlib.cxx as suggested and can now see them fairly well. Are these single pixel lights? Maybe it is my Acer monitor that is the problem. ;) If they're single pixel lights, then will FSAA cause then to be blurred out, especially if they've got a significant alpha component? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] taxiway lights
From: William L. Riley [EMAIL PROTECTED] On Tuesday 22 October 2002 03:32 pm, Curtis L. Olson wrote: One thing you could play with is this: Find line #493 in src/Objects/matlib.cxx tex_name = gen_taxiway_dir_light_map( 20, 20, 235, 155 ); Change the last number (155) which is the overall alpha for the light to a higher value. The number can be in the range of 0 - completely transparent to 255 - completely opaque. The larger the number (up to 255), the more visible the lights should be. You might try 200 for starters and then increase to 255. I changed the alpha up to 255 in matlib.cxx as suggested and can now see them fairly well. Are these single pixel lights? Maybe it is my Acer monitor that is the problem. ;) I also find all runway/taxyway light very dim when seen from close. At a distance, it is the fact that they are all close together that makes the whole correctly bright. As points have no dimension, or at least a size that is not dependant of the distance, we can hardly see a light alone, only rows. Would it be possible to add dimensions to lights, that is, make them with triangles in fill mode ? Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] taxiway lights
From: Curtis L. Olson [EMAIL PROTECTED] Frederic Bouvier writes: I also find all runway/taxyway light very dim when seen from close. At a distance, it is the fact that they are all close together that makes the whole correctly bright. As points have no dimension, or at least a size that is not dependant of the distance, we can hardly see a light alone, only rows. Would it be possible to add dimensions to lights, that is, make them with triangles in fill mode ? The correct (?) fix is to use the glPointParam extention by enabling FG_EXPERIMENTAL_LIGHTING in main.cxx This imposes a significant frame rate hit unfortunately on probably everyone's hardware. I tried FG_EXPERIMENTAL_LIGHTING without seeing a significant change. Anyway, I needed to apply this patch in order to compile with MSVC : D:\FlightGear\cvs\FlightGear\src\Maincvs -z3 -q diff -u main.cxx Index: main.cxx === RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v retrieving revision 1.32 diff -u -r1.32 main.cxx --- main.cxx21 Oct 2002 03:22:27 - 1.32 +++ main.cxx23 Oct 2002 06:06:23 - @@ -134,9 +134,16 @@ #include Scenery/tileentry.hxx -// #define FG_EXPERIMENTAL_LIGHTING +#define FG_EXPERIMENTAL_LIGHTING #ifdef FG_EXPERIMENTAL_LIGHTING # ifdef WIN32 +# ifndef GL_DISTANCE_ATTENUATION_EXT +#define GL_DISTANCE_ATTENUATION_EXT 0x8129 +# endif +# ifndef GL_POINT_SIZE_MIN_EXT +#define GL_POINT_SIZE_MIN_EXT 0x8126 +# endif + typedef void (APIENTRY * PFNGLPOINTPARAMETERFEXTPROC)(GLenum pname, GLfloat param); typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname, END=== Values are taken from extgl.h found in Clouds3D directory. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] taxiway lights
I just added support for generating taxiway lights into terragear (with some corresponding changes in FlightGear) so I guess someone is going to have to regenerate the airports again. :-) 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
