[Flightgear-devel] Landing lights lobes (some thoughts)
Hi guys! runway lights are really impressive! so there is some minor thing todo: landing lights but here is huge problem - multitexturing Steve don't want to include in plib some patches to make multitexturing and he wait for OpenGL2.0 with shaders so we have to implement it our own way. Do someone work in this direction? Curtis, do you plan to include landing lights in flightgear or there are some major work to do? What's your position on this feature. Will we wait plib with multitexturing or make it own way? I think we should use landing lights with only runway/taxiway textures because if we use it with all textures there will be huge frame rate hit Also I'll be very appreciate if someone give me a link with landing lights pics. Thanx in advance Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing lights lobes (some thoughts)
Roman Grigoriev wrote: Hi guys! runway lights are really impressive! so there is some minor thing todo: landing lights but here is huge problem - multitexturing Steve don't want to include in plib some patches to make multitexturing and he wait for OpenGL2.0 with shaders so we have to implement it our own way. Do someone work in this direction? Curtis, do you plan to include landing lights in flightgear or there are some major work to do? What's your position on this feature. Will we wait plib with multitexturing or make it own way? I think we should use landing lights with only runway/taxiway textures because if we use it with all textures there will be huge frame rate hit Also I'll be very appreciate if someone give me a link with landing lights pics. You mean something like this: http://www.flightgear.org/tmp/rwy_lights3.jpg Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Mon, 21 Oct 2002 21:03:18 -0400, <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Andy Ross writes: > > > > An excellent point -- I wonder how they do it, then? On the > > > ground, they can obviously line up with something well known, and > > > in VFR, they can line up two landmarks on the map, but how to > > > update the DG in IFR? > > > > As Alex points out, if you have three receivers (and synchronize > > them to use the same satellite set) you can get the location for > > each point of a triangle and figure out the orientation for that. > > Right, but I'm not asking how people could do it but how they actually > do. I doubt that most pilots in the north have 3-GPS in-flight setups > right now. ..standard is "one antenna for vfr type flight", position is accurate within a 300ft diameter by 450 ft tall "error egg" with cold war type crypto turned on, egg shrinks to 35?ft by 50?ft on turning off the crypto (random noise vector) signal. The "error egg" shrinks further when additional observations are added to the equation set, such as altimeter, DG, GS etc readings, exact position of antenna(s) and other sensors on airframe, in relation to its datum origo. Differential GPS may add one or more ground station "satellite" observations to the equation set, the early work tried to calculate and nullify the random noise vector, and instead added (athmosphaerically bent) signal path leg errors. ..AFAIK, the average aviator "up north" uses cheap shelf ware gps units "to back up" his nav work. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing lights lobes (some thoughts)
- Original Message - From: "Erik Hofman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 1:34 PM Subject: Re: [Flightgear-devel] Landing lights lobes (some thoughts) > Roman Grigoriev wrote: > > Hi guys! > > runway lights are really impressive! > > so there is some minor thing todo: landing lights > > but here is huge problem - multitexturing > > Steve don't want to include in plib some patches to make multitexturing and > > he wait for OpenGL2.0 with shaders > > so we have to implement it our own way. > > Do someone work in this direction? > > Curtis, do you plan to include landing lights in flightgear or there are > > some major work to do? > > What's your position on this feature. > > Will we wait plib with multitexturing or make it own way? > > I think we should use landing lights with only runway/taxiway textures > > because if we use it with all textures there will be huge frame rate hit > > Also I'll be very appreciate if someone give me a link with landing lights > > pics. > > You mean something like this: > http://www.flightgear.org/tmp/rwy_lights3.jpg > Nope Erik I mean not runway lights but aircraft landing lights. > Erik > > > ___ > 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] Landing lights lobes (some thoughts)
Roman Grigoriev writes: > Hi guys! > runway lights are really impressive! > so there is some minor thing todo: landing lights > but here is huge problem - multitexturing > Steve don't want to include in plib some patches to make multitexturing and > he wait for OpenGL2.0 with shaders > so we have to implement it our own way. > Do someone work in this direction? > Curtis, do you plan to include landing lights in flightgear or there are > some major work to do? > What's your position on this feature. > Will we wait plib with multitexturing or make it own way? > I think we should use landing lights with only runway/taxiway textures > because if we use it with all textures there will be huge frame rate hit > Also I'll be very appreciate if someone give me a link with landing lights > pics. I don't really have a plan for how to do this at the moment. 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] DC-3
Doug Pomerenke writes: > Do you have any plans on introducing a damage model? It's hard to say. Some day we'll probably want to be able to simulate damage in the flight model, and we may want to give some visual indication of that as well (such as a separated aileron or a blown tire). I don't now if it will ever be a priority to be able to show bullet holes in the wing or an explosion when a plane crashes, but that will depend on the interests and skills of the developers who contribute in the future. 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] Landing lights lobes (some thoughts)
Roman Grigoriev writes: > so there is some minor thing todo: landing lights > but here is huge problem - multitexturing Another alternative might be actually to include an OpenGL light source in spot mode. An yes, we do need landing lights to work with fields, etc. as well. Some day, we might even have a taxi model for water so that we can model seaplanes realistically. 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] Reparsing cmd lines
John Wojnaroski writes: > Appears the command line is being reparsed. This results is the program > failing when a TCP socket is requested for the native-ctrls channel as the > server is created on the first pass and on the next pass trying to create > and bind a "second" server at the same port# fails. Oops -- I was wondering if reparsing the command line would break anything. The right fix is to have the TCP module read properties and open its socket *after* the command line is parsed, so that the command-line parsing is side-effect free (there may be other side-effects as well). 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] DC-3
[EMAIL PROTECTED] writes: > It's hard to say. Some day we'll probably want to be able to simulate > damage in the flight model, and we may want to give some visual > indication of that as well (such as a separated aileron or a blown > tire). I don't now if it will ever be a priority to be able to show > bullet holes in the wing or an explosion when a plane crashes, but > that will depend on the interests and skills of the developers who > contribute in the future. This is just a WAG, but based on other sims I've flown, they probably just do simple things like scale lift with the amount of wing left, or add weight/reduce lift for icing or maybe force a pitch/aileron/rudder trim offset. Just a few little things can make flying the plane challenging enough so that the pilot won't notice if their plane is actually behaving *exactly* like their tail was shot off. More important for us are things like engine failure modeling and some sort of plausible icing model, as well as all the various internal systems failures. Maybe someone needs to come up with CombatFDM or JSBSimJr. or something like that which would impliment more arcade-ish "fun" flight dynamics. 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] Reparsing cmd lines
[EMAIL PROTECTED] writes: > John Wojnaroski writes: > > > Appears the command line is being reparsed. This results is the program > > failing when a TCP socket is requested for the native-ctrls channel as the > > server is created on the first pass and on the next pass trying to create > > and bind a "second" server at the same port# fails. > > Oops -- I was wondering if reparsing the command line would break > anything. > > The right fix is to have the TCP module read properties and open its > socket *after* the command line is parsed, so that the command-line > parsing is side-effect free (there may be other side-effects as well). David, That may ultimately be what we need to do, but remind me why we need to parse the command line options twice? 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
[Flightgear-devel] SimGear and clouds3d complie problems
Hi All, I'm having a few problems compiling the latest SimGear from the CVS tree (0.3). Its barfing on multiple definitions and parse errors (from undefined typedef's) in extgl.h (conflicting with definitions in gl.h). Ive been searching and nothing seems to fit the problems I'm seeing. The errors start like this and roll on and on: gcc -DHAVE_CONFIG_H -I. -I. -I../../../simgear -I../../.. -I/usr/X11R6/incl ude -g -O2 -D_REENTRANT -Wl,--allow-multiple-definition -c `test -f 'extgl.c' || ec ho './'`extgl.c In file included from extgl.c:85: extgl.h:1665: warning: `GL_MODELVIEW1_ARB' redefined /usr/X11R6/include/GL/glext.h:241: warning: this is the location of the previous definition In file included from extgl.c:85: extgl.h:357: `glBlendColor' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:1648: previous declaration of `glBlendColor' extgl.h:358: `glBlendEquation' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:1645: previous declaration of `glBlendEquation' extgl.h:359: `glDrawRangeElements' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:1590: previous declaration of `glDrawRangeElements' extgl.h:360: `glColorTable' redeclared as different kind of symbol /usr/X11R6/include/GL/gl.h:1617: previous declaration of `glColorTable' ..etc Its bascially hosed. Now the fact someone else hasnt seen this problem says to me I've got something screwey, but I've been lookign at it off and on for a week or more and just cannot find it. If anyone has any ideas pls let me know. I'm using cygwin and gcc-2.95 with Mesa 3.4 Thanks, Bevan Anderson.. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Reparsing cmd lines
Curtis L. Olson writes: > That may ultimately be what we need to do, but remind me why we need > to parse the command line options twice? It's an init-order work-around to make the --aircraft option work as expected. 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] 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] Landing lights lobes (some thoughts)
David Megginson wrote: > Roman Grigoriev writes: > > so there is some minor thing todo: landing lights > > but here is huge problem - multitexturing > > Another alternative might be actually to include an OpenGL light > source in spot mode. Spotlights, and OpenGL lights in general, only work at vertices. The tesselation of the scenery tiles is so coarse that this would essentially be a no-op. None of the tile vertices would fall inside the landing lights. That is, until one stochastically passes through it and the ground in front of the aircraft lights up like a bomb flash. :) I think Roman's suggestion is the right one -- you would generate the light pattern as a texture and apply it projectively as the second texture pass on "nearby" tiles. This really wouldn't be so hard, I suspect. Multitexture on modern hardware is essentially free. The mechanism would be to write a ssg node class to represent a tile. If the tile is "far" from all such lights, then draw as normal. If it is in the near field for some light (remembering that not all lights are going to be attached to the pilot's aircraft!), then set up the texture state appropriately and draw by hand. Not trivial, but not difficult either. I wrote a ssg node for wrapping 2D panels, and it worked pretty cleanly. 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] Landing lights lobes (some thoughts)
Andy Ross writes: > Spotlights, and OpenGL lights in general, only work at vertices. Is there an opengl extension that would allow the spot light to work per pixel rather than per vertex? It seems like I've heard of something, but I haven't investigated myself. > I think Roman's suggestion is the right one -- you would generate the > light pattern as a texture and apply it projectively as the second > texture pass on "nearby" tiles. This really wouldn't be so hard, I > suspect. Multitexture on modern hardware is essentially free. This would be interesting, especially since you could fake the lense patterns of the lights. Using a spot light (even if it worked as you'd hope) would almost be a little too perfect. We'd also need to draw the light beam near the aircraft in foggy conditions. Would love to see a 747 dropping out of the soup from the tower view with it's lights blazing through the fog. That probably wouldn't be too hard to do, and could even be done as an animation as part of the model. 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 12:18 pm, Curtis L. Olson wrote: > 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. The experimental lighting cuts my frame rate down to 12 (from 60ish) but doesn't improve the taxiway lights. Here is a screenshot. http://www.randdtechnologies.com/tmp/taxiway_lights.jpg They are all but invisible even with low room lighting. Am I the only one not seeing them well? Maybe it is just a gamma issue with my setup. The other airport lights are very nice, however. 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 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
[Flightgear-devel] KOAK lighting
I have updated my base Scenery package to include lights at KOAK. Putting the KOAK airport info from default.apt into a separate file and generating it by itself seems to work, as Curt said. I will be regenerating more of the US airports soon and hope to catch an error or something that will help explain why certain airports (maybe just KOAK?) don't get working lights. Wm http://www.randdtechnologies.com/fgfs/newScenery/ -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KOAK lighting
William L. Riley writes: > I have updated my base Scenery package to include lights at KOAK. Putting the > KOAK airport info from default.apt into a separate file and generating it by > itself seems to work, as Curt said. I will be regenerating more of the US > airports soon and hope to catch an error or something that will help explain > why certain airports (maybe just KOAK?) don't get working lights. I had lights at KOAK from your base package update today. Did you cvs update your FlightGear code since this afternoon? 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
[Flightgear-devel] Pannel illumination gone on DC3
I updated plib, simgear, and FlightGear sources, and well as fgfsbase from cvs Sunday and recompiled all source. I noticed that the dc3 pannel is black at night except for the radio lcds. I just updated via cvs both fgfsbase and FlightGear source and recompiled and the dc3 pannel is still unlit at night. Are others seeing this? I will check the yasim c172 (2d pannel) to see if it is also dark. - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] dc3 pannel lights
The c172-yasim pannel is lit at night, so this seems to be a change to the dc3 only. - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 pannel lights
On Tuesday 22 October 2002 10:11 pm, Dave Perry wrote: > The c172-yasim pannel is lit at night, so this seems to be a change to > the dc3 only. > - Dave What it is is that when electrical system modeling was added it affected planes for which no electrical system was added. I went through and added the markup to include the electrical.xml from the default 172 to all the variants, but never did the non Cessna planes. I don't recall any replies to my asking about using that as a default for the rest of the fleet. > > > ___ > 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] DC-3
On Tue, 2002-10-22 at 08:50, Curtis L. Olson wrote: > [EMAIL PROTECTED] writes: > > It's hard to say. Some day we'll probably want to be able to simulate > > damage in the flight model, and we may want to give some visual > > indication of that as well (such as a separated aileron or a blown > > tire). I don't now if it will ever be a priority to be able to show > > bullet holes in the wing or an explosion when a plane crashes, but > > that will depend on the interests and skills of the developers who > > contribute in the future. > > This is just a WAG, but based on other sims I've flown, they probably > just do simple things like scale lift with the amount of wing left, or > add weight/reduce lift for icing or maybe force a pitch/aileron/rudder > trim offset. Just a few little things can make flying the plane > challenging enough so that the pilot won't notice if their plane is > actually behaving *exactly* like their tail was shot off. > > More important for us are things like engine failure modeling and some > sort of plausible icing model, as well as all the various internal > systems failures. > > Maybe someone needs to come up with CombatFDM or JSBSimJr. or > something like that which would impliment more arcade-ish "fun" flight > dynamics. > > Curt. > -- My intention is for the damage model to have an effect on the FDM that will be as realistic as possible. Initially it would address conditions that could occur to all aircraft, hard landings, shear applied to the landing gear, high g forces. These effects would somehow work their way to the flight model and alter it's characteristics. I just realized that engine failures and icing are also damage, in the sense that they alter the flight model characteristics. I'm beginning to see some relationships here that map over to OOAD, mainly abstractness and inheritance, quit well. I'd like to do the combat stuff, but a well designed system would first cover the general cases, then get more specialized. Since this is closely related the the FDM, perhaps this topic should probably move over to the [EMAIL PROTECTED] list. Doug ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 pannel lights
John Check wrote: > What it is is that when electrical system modeling was added it > affected planes for which no electrical system was added. I went > through and added the markup to include the electrical.xml from the > default 172 to all the variants, but never did the non Cessna planes. Shouldn't the sane choice for the defaults be the opposite? The instruments work unless the electrical system tells them that they are disabled? Otherwise every all new panel work will either be useless at night or require hacking in a nonsensical simulation. The A-4 has the same symptom, for example. Certainly we don't want a Cessna electrical system, no? 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] dc3 pannel lights
On Wednesday 23 October 2002 12:44 am, Andy Ross wrote: > John Check wrote: > > What it is is that when electrical system modeling was added it > > affected planes for which no electrical system was added. I went > > through and added the markup to include the electrical.xml from the > > default 172 to all the variants, but never did the non Cessna planes. > > Shouldn't the sane choice for the defaults be the opposite? The > instruments work unless the electrical system tells them that they are > disabled? Otherwise every all new panel work will either be useless > at night or require hacking in a nonsensical simulation. The A-4 has > the same symptom, for example. Certainly we don't want a Cessna > electrical system, no? > > Andy Well, Ideally, no, but like anything else, unless we have some documentation to work from, getting it right isn't likely. I don't know what doco is available. My feeling is that that we should at least have the battery and/or alternator connected to a main buss, which is simpler than what the 172 has. All we need is for a generic_electrical.xml to be loaded when one isn't specified. I have no problems with making it a requirement to add one to the markup for a plane, but I'm sure others may feel differently. I have no idea how this was handled prior. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Networked Sound / Networked Input
Manuel Bessler writes: > > PS: anyone using OpenGC under unix ? > After fixing some capitalization Issues, I got the 0.3 CVS version > compiled (using cmake) 2 weeks ago. However it does not work > w/ flightgear. Looking at the source I could see why: the fgfs stuff > is just left out at some places. > ATM neither the FlightGear or OpenGC work out of the box. Just looked at the OpenGC source and see your point. Have no idea who did that, but it shuts down the network interface. Changes to the FG socket code in May "broke" the control channel from the OpenGC FMS to FlightGear. Disappointed that my queries to the author of the change have gone unanswered. Guess that is one of the pitfalls of open-source development. Bottom line - neither program will work without some modifications and tailoring. My cockpit sim is currently running with customized versions of the latest CVS copies of FG and OpenGC with Debian Linux connected over a LAN. If you're interested, be happy to send along info, tips, and fixes to get things running. Regards John W. ___ 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\Main>cvs -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 -// #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
