Re: [Flightgear-devel] building cvs on Red Hat 8.0
Thanks for posting this info below. Going to RH8.0 is probably going to be my solution to getting up and running again. With RH7.1 I am still dead in the water w/ the SkySceneLoader *sgClouds3d code (segfault ... unless someone can figure out how to have fgfs avoid that code when 3d clouds are disabled, which is the default option). Regards, Michael At 10/26/02, Jim Wilson wrote: Well this happened to be a dot O release from redhat that I actually decided to try on a computer in a batch we picked up from an off-lease reseller. Without having a lot of time to spend on it, my original goal was to go with their highly touted install routine and if it failed to work I'd clean the disk and move on. Well it worked. Amazingly enough. Their pre-done package selections (workstation or server--some others in 8.0) never do what I want so I did custom install and basically added everything except a few server items I don't need. Building Flight Gear on a fresh install of RH8.0 went quite smoothly, with basically the same issues as previous releases: 1) Even with all the package groups I had selected the glut package still didn't get installed. Then after looking a bit I noticed that the glut package isn't anywhere on the fancy add/remove package menu that pops up everytime you insert disk 1. So you'll have to install them some other way. BTW, they are on distribution Disc #3. Note that both glut-3.7-8 and glut-devel-3.7-8 need to installed. Do that and now you can build plib. 2) Red Hat doesn't include metakit, so you'll have to build the one in the src-libs directory of the SimGear project. Extract it. Change into the metakit-2.4.3/builds directory. Run the configure by typing ./unix/configure --prefix=/usr Then build and install it. After you do that you can build SimGear and then FlightGear. Best, Jim ___ 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] Clickable cockpit
Norman Vine wrote:
Your scrollable HUD is GREAT but can you make this a 'preferences'
controled option so that we can keep the older HUD as there are many
reasons for having a 'fixed' fullscreen HUD too.
Certainly this could be flipped on and off. Actually, there's a
vestigial if(1) {...} in the patch for exactly this purpose; it used
to be a test against the /sim/virtual-cockpit property. But I think
the problem is deeper.
What exactly is it that you want from the current HUD that you don't
want to be view-dependent? It's clearly not the horizon ladder or
velocity vector, as those are useless if specified only in screen
space. It's probably stuff like the frame rate counter, or maybe
airspeed and heading that you want to watch from tower view. Am I
right? The problem is, those features aren't rightfully part of a
real world heads up display. They're something else.
Right now we have one code base trying to do two things: provide a
simulation of an actual aircraft HUD, and provide useful information
to a simulator pilot in screen space. These just aren't the same
task, and the HUD suffers architecturally because of it. The biggest
pain in doing this patch was, in fact, extracting the brain damage
that results from trying to canonize 640x480 as the coordinate
system for drawing pilot symbology (I'm not kidding -- that's what it
does; the concept of angle doesn't exist in the HUD code. It gets
even worse when you note that the code is further hacked to make the
640x480 input coordinates really mean 1024x768 on the screen!).
I'd submit that we need to split this up instead of clinging to old
breakage. There is a need for a 3D view-dependent HUD that mimics
the behavior of HUDs in real aircraft. This patch is at least a
hacked-up start in that direction.
Users that need a 2D, screen space area to put simulation information
already have the existing 2D panel infrastructure to work with. The
panels can already do text output, and with a little work could be
augmented to handle alignment and other cool features. With a little
work, we could augment this to allow more than one screen-space panel
like the windows in MSFS. Picture a tiny FPS counter panel placed
in the corner of the screen, and a popup navigation bar for use from
tower mode, etc...
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] Clickable cockpit
Andy Ross writes: Norman Vine wrote: Your scrollable HUD is GREAT but can you make this a 'preferences' controled option so that we can keep the older HUD as there are many reasons for having a 'fixed' fullscreen HUD too. There is a need for a 3D view-dependent HUD that mimics the behavior of HUDs in real aircraft. This patch is at least a hacked-up start in that direction. I submit that your patch is an additional mode and should be presented as such rather then BREAKING existing behaviour as IMHO is all to often what happens when someone decides to get involved with a piece of the code. Please don't take me wrong I think your 3D HUD is a valuable contribution but there are many reasons for a fixed 2D HUD. If you find that some of the existing 2D HUD code works for your 3D HUD great otherwise please write your own modules rather then breaking the existing ones Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I've got a few minutes to spare
On Sunday 27 October 2002 12:22 am, Jon Berndt wrote: I've got a few minutes to spare this evening, so I'm going to try again to build the latest development flightgear. Questions: 1) I plan on using the latest bleeding edge flightgear sources from development CVS. Which base package do I download? 2) Does the base package from #1 (above) work with the latest simgear and plib? 3) Any issues with Cygwin and trying the above approach? Jon There is only one repository for the base package. The stable code is a branch. You shouldn't have to do anything special. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Curtis L. Olson writes: We artifically raise the lights a bit to attempt to avoid zbuffer fighting. The formula is based on the altitude above ground and the distance away ... however, it's rough and imperfect ... I'm still working on understanding the code. First, you have point_list geod_light_nodes = calc_elevations( root, light_nodes.get_node_list(), 0.5 ); That means that the base elevation for each light is already 0.5m above the runway. Does FlightGear have ssg do further elevation adjustments at runtime? 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] screen shots lights
David Megginson writes:
Curtis L. Olson writes:
We artifically raise the lights a bit to attempt to avoid zbuffer
fighting. The formula is based on the altitude above ground and the
distance away ... however, it's rough and imperfect ...
I'm still working on understanding the code. First, you have
point_list geod_light_nodes
= calc_elevations( root, light_nodes.get_node_list(), 0.5 );
That means that the base elevation for each light is already 0.5m
above the runway. Does FlightGear have ssg do further elevation
adjustments at runtime?
void FGTileEntry::prep_ssg_node(
{
if ( gnd_lights_transform ) {
..
if ( general.get_glDepthBits() 16 ) {
sgScaleVec3( lift_vec, 10.0 + agl / 100.0 + dist / 1 );
} else {
sgScaleVec3( lift_vec, 10.0 + agl / 20.0 + dist / 5000 );
}
...
if ( rwy_lights_transform ) {
...
if ( general.get_glDepthBits() 16 ) {
sgScaleVec3( lift_vec, 0.0 + agl / 500.0 + dist / 1 );
} else {
sgScaleVec3( lift_vec, 1.0 + agl / 20.0 + dist / 5000 );
}
if ( lightmaps_transform ) {
..
if ( general.get_glDepthBits() 16 ) {
sgScaleVec3( lift_vec, 0.0 + agl1 / 2000.0 + dist1 / 1 );
} else {
sgScaleVec3( lift_vec, 0.0 + agl1 / 20.0 + dist1 / 5000 );
}
...
}
HTH
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] building cvs on Red Hat 8.0
On Sun, 27 Oct 2002 00:59:29 -0500, Michael Selig [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Thanks for posting this info below. Going to RH8.0 is probably going to be my solution to getting up and running again. With RH7.1 I am still dead in the water w/ the SkySceneLoader *sgClouds3d code ..go for it. I'm upgrading all my boxes except a bandwidth throttle from -7.3 to -8.0, I fell for the new response to two tabs on a test box. (The throttle controls bandwidth for about 500 people, so it, and they remains online. ;-) ) -- ..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] screen shots lights
David Megginson writes: I'm still working on understanding the code. First, you have point_list geod_light_nodes = calc_elevations( root, light_nodes.get_node_list(), 0.5 ); That means that the base elevation for each light is already 0.5m above the runway. Does FlightGear have ssg do further elevation adjustments at runtime? Yes ... a 0.5 elevation difference just isn't enough to maintain zbuffer separation from common viewing distances and angles. This gets significantly worse on a card with a 16 bit depth buffer (i.e. voodoo-1,2.3) I believe the code to lift up the runway lights (and ground cover lights) is in tileentry.cxx:prep_ssg_node() 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] screen shots lights
David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: We artifically raise the lights a bit to attempt to avoid zbuffer fighting. The formula is based on the altitude above ground and the distance away ... however, it's rough and imperfect ... I'm still working on understanding the code. First, you have point_list geod_light_nodes = calc_elevations( root, light_nodes.get_node_list(), 0.5 ); That means that the base elevation for each light is already 0.5m above the runway. Does FlightGear have ssg do further elevation adjustments at runtime? Yes it does. It is based on the agl data. Look at about line 834 in tileentry.cxx. Note that because Yasim reports AGL at wheel level the lights are actually lower there. It seems to me that the 0.5 could be made lower (maybe a property to adjust it in some cases). To see the difference start up the c310, go to chase view and lower your view angle so that the ground is level. The green lights will pass over the wing level. Then do the same with c310-yasim, the green lights will be just about 0.5m off the ground. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: I'm still working on understanding the code. First, you have point_list geod_light_nodes = calc_elevations( root, light_nodes.get_node_list(), 0.5 ); That means that the base elevation for each light is already 0.5m above the runway. Does FlightGear have ssg do further elevation adjustments at runtime? Yes ... a 0.5 elevation difference just isn't enough to maintain zbuffer separation from common viewing distances and angles. This gets significantly worse on a card with a 16 bit depth buffer (i.e. voodoo-1,2.3) I believe the code to lift up the runway lights (and ground cover lights) is in tileentry.cxx:prep_ssg_node() Yes and in that code, subtracting 30m from the agl (and flooring it to 0) would probably work fine and look a bit better. That way the lights wouldn't start to lift until AGL exceeded 30m. Haven't got time to try it right now...the crew is waiting to leave for brunch. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Curtis L. Olson writes: Yes ... a 0.5 elevation difference just isn't enough to maintain zbuffer separation from common viewing distances and angles. This gets significantly worse on a card with a 16 bit depth buffer (i.e. voodoo-1,2.3) I believe the code to lift up the runway lights (and ground cover lights) is in tileentry.cxx:prep_ssg_node() I'll do some experimentation. On the ground right now, in a C172, the runway lights are at about eye height. 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] Clickable cockpit
Norman Vine wrote: I submit that your patch is an additional mode and should be presented as such rather then BREAKING existing behaviour as IMHO is all to often what happens when someone decides to get involved with a piece of the code. Oh dear, not again. For the record (and I really tried to make this clear): I'm not refusing to support a 2D HUD. I was asking what, exactly, your requirements are so that they can be supported in a sane and maintainable way. Trying to use HUD code to draw into screen space is a square peg in a round hole and needs to be fixed, not hidden with a preference where it will get forgotten as a booby trap for future developers. Now, what broke? You still haven't answered what it is you want, and why it needs to be part of the HUD. Seriously, name your requirement and we can try to meet it. Refuse to allow changes in functionality and all you'll do is halt development. For reference, see this fantastic diatribe by Havok Pennington on the dangers of accommodating every imaginable UI preference. It was written in the context of the Gnome 2 no crackrock policy. http://www106.pair.com/rhp/free-software-ui.html Just because your requirements are met by existing code doesn't make that code the *only* way of meeting your requirements. Be reasonable and flexible and you'll get what you want, I promise. 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] screen shots lights
David Megginson [EMAIL PROTECTED] said: Curtis L. Olson writes: Yes ... a 0.5 elevation difference just isn't enough to maintain zbuffer separation from common viewing distances and angles. This gets significantly worse on a card with a 16 bit depth buffer (i.e. voodoo-1,2.3) I believe the code to lift up the runway lights (and ground cover lights) is in tileentry.cxx:prep_ssg_node() I'll do some experimentation. On the ground right now, in a C172, the runway lights are at about eye height. It looks pretty good with this patch: RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v retrieving revision 1.9 diff -r1.9 tileentry.cxx 891c891,893 * SG_FEET_TO_METER - globals-get_scenery()-get_cur_elev(); --- * SG_FEET_TO_METER - globals-get_scenery()-get_cur_elev() - 30; if (agl 0) agl = 0; Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
'Johnny' wrote:
Now, what broke?
The 2D HUD
You still haven't answered what it is you want,
The functionality of the 2D HUD
Seriously, name your requirement
Seriously, The functionality of the existing 2D HUD
and we can try to meet it.
Thank you very much for the offer but since the requirement is
nicely met by the existing code, there is nothing 'we' need to do
The 3D HUD code patch on the other hand needs to implement
the vestigial if(1) {...} in the patch to make the HUD display
a 'properties' controlled option between the 2D and the 3D
versions or provide an alternative method of getting the existing
2D HUD displayed.
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Norman Vine wrote:
'Johnny' wrote:
Now, what broke?
The 2D HUD
You still haven't answered what it is you want,
The functionality of the 2D HUD
Seriously, name your requirement
Seriously, The functionality of the existing 2D HUD
and we can try to meet it.
Thank you very much for the offer but since the requirement is
nicely met by the existing code, there is nothing 'we' need to do
The 3D HUD code patch on the other hand needs to implement
the vestigial if(1) {...} in the patch to make the HUD display
a 'properties' controlled option between the 2D and the 3D
versions or provide an alternative method of getting the existing
2D HUD displayed.
Norman, I have the feeling this is getting to nowhere this way.
As it seems to me we (and by me I mean everybody using FlightGear, maybe
except you) a 3D HUD. At this time we don't have one, and Andy created
it. That's good.
Now we can do two things, have duplicate code by keeping the 2D HUD, or
creating the functionallity of the 2D HUD with the nee 3D HUD code. I'm
not for including two sets of code doing basically the same.
Please try to be a bit more coorporative in this, particularly because
Andy _does_ want to satisfy *your* needs!
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Erik Hofman writes: Now we can do two things, have duplicate code by keeping the 2D HUD, or creating the functionallity of the 2D HUD with the nee 3D HUD code. I'm not for including two sets of code doing basically the same. Speaking of dead code, is anyone still using the old DCS support from main.cxx? I think that it can be completely replaced with the newer 3D model animation code, but I want to make sure I'm not going to break anyone's apps before I rip it out. 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] Clickable cockpit
Norman Vine wrote:
Andy Ross wrote:
You still haven't answered what it is you want,
The functionality of the 2D HUD
Seriously, name your requirement
Seriously, The functionality of the existing 2D HUD
Norman, this isn't constructive. Here are some things I'm quite
certain you don't want:
+ A velocity vector that doesn't point where the aircraft is going
+ HUD scaling that breaks with changes of aspect ratio
+ HUD scaling that breaks with changes of resolution
+ A horizon line that doesn't lie along the horizon
Honestly, I can only think of two that you do want:
+ A text display of FPS and latitude that always appears in the same
part of the screen.
+ A navigation display available from views other than the cockpit.
Now, these are useful features (really! I agree, these are useful
features!). But, IMHO, they aren't part of a HUD, which is a
projected display intended to be part of a cockpit environment.
These are 2D screen display objects or whatnot. The second case can
be handled quite nicely by a 2D panel (take a look at the c172 mini
panel, for example). The first is already hacked in for the case of a
FPS counter, and could also be done very nicely by a panel.
The 3D HUD code patch on the other hand needs to implement the
vestigial if(1) {...} in the patch
It's already there. Like I mentioned, I didn't gratuitously change
the old functionality. Just change the 1 to something like:
if(!fgGetBool(/sim/old-2d-hud)) { ... }
But again my point: this doesn't solve anything. If you use this
compatibility feature, you'll still get a HUD that looks broken
almost all the time. If you use the 3D HUD for what it was designed
to do, you lose the 2D stuff.
You can't win with a compatibility hack. I ask again: is there
something *specific* that you want to have working? Almost certainly,
it can be done in addition to the 3D HUD and everyone will win. But
you have to be specific. If all you wanted was compatibility code,
you wouldn't be running the development version. :)
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] Clickable cockpit
Andy Ross [EMAIL PROTECTED] said: The biggest and coolest patch adds mouse sensitivity to the 3D cockpits, so we can finally work the radios. This ended up requiring significant modifications outside of the 3D cockpit code. Stuff folks will want to look at: That's great! Has anyone thought about how to do mouse click support with the 3D instruments? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Building Flight Gear with NVIDIA's GLX package
I have an NVIDIA GeForce 4 Ti4600, and I am using NVIDIA's graphics driver with their GLX implementation. I get the following error when trying to configure Flight Gear 0.8 for a build: checking for glNewList in -lGLcore... no checking for glNewList in -lGL... yes checking GL/fxmesa.h usability... no checking GL/fxmesa.h presence... no checking for GL/fxmesa.h... no checking for gluLookAt in -lGLU... yes checking for glutGetModifiers in -lglut... no checking for glutGameModeString in -lglut... no Unable to find the necessary OpenGL or GLUT libraries. See config.log for automated test details and results ... As you can see it cannot find certain functions in the OpenGL glut libraries. Are these functions proprietary to Mesa's implementation of OpenGL, or are they just missing from NVIDIA's implementation. I could put the Mesa libraries back in place, but then I would not get hardware acceleration, which of course defeats the purpose of having this high powered video card in the first place. Any help you can be in answering this would be greatly appreciated. Thanks. Andrig T. Miller ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Yeager [OT]
A little OT, but interesting: http://www.cnn.com/2002/US/West/10/26/yeager.sound.ap/index.html Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Norman, this isn't constructive. Here are some things I'm quite certain you don't want: + A velocity vector that doesn't point where the aircraft is going + HUD scaling that breaks with changes of aspect ratio + HUD scaling that breaks with changes of resolution + A horizon line that doesn't lie along the horizon Perhaps the best solution will be to fork between the actual HUD (which should be 3D) and a screen-oriented 2D overlay module that uses the same configuration code to display things like frame-rate, network-connection status, etc. The beauty of configurability is that if Norm still wants to see the HUD ladder, etc. in 2D, it should be a simple matter to whip up an XML configuration file for it. 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] Clickable cockpit
Jim Wilson writes: That's great! Has anyone thought about how to do mouse click support with the 3D instruments? Thought, yes; succeeded, no. Steve Baker is very hostile towards the idea of providing simple plib support for this kind of thing, and the only help I've got so far is look at the ppe source (it didn't help me). 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] Building Flight Gear with NVIDIA's GLX package
Andrig T. Miller [EMAIL PROTECTED] said: I have an NVIDIA GeForce 4 Ti4600, and I am using NVIDIA's graphics driver with their GLX implementation. I get the following error when trying to configure Flight Gear 0.8 for a build: checking for glNewList in -lGLcore... no checking for glNewList in -lGL... yes checking GL/fxmesa.h usability... no checking GL/fxmesa.h presence... no checking for GL/fxmesa.h... no checking for gluLookAt in -lGLU... yes checking for glutGetModifiers in -lglut... no checking for glutGameModeString in -lglut... no Unable to find the necessary OpenGL or GLUT libraries. See config.log for automated test details and results ... As you can see it cannot find certain functions in the OpenGL glut libraries. Are these functions proprietary to Mesa's implementation of OpenGL, or are they just missing from NVIDIA's implementation. I could put the Mesa libraries back in place, but then I would not get hardware acceleration, which of course defeats the purpose of having this high powered video card in the first place. Any help you can be in answering this would be greatly appreciated. Thanks. Andrig T. Miller ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Building Flight Gear with NVIDIA's GLX package
GLX and GLU are two different packages. The GLX is the X-Windows support and the GLU is the OpenGL utility library (aka glut). Are you sure that glut is installed? Note that you also need the headers so if you are installing binary rpms make sure you have glut-devel as well. Best, Jim Andrig T. Miller [EMAIL PROTECTED] said: I have an NVIDIA GeForce 4 Ti4600, and I am using NVIDIA's graphics driver with their GLX implementation. I get the following error when trying to configure Flight Gear 0.8 for a build: checking for glNewList in -lGLcore... no checking for glNewList in -lGL... yes checking GL/fxmesa.h usability... no checking GL/fxmesa.h presence... no checking for GL/fxmesa.h... no checking for gluLookAt in -lGLU... yes checking for glutGetModifiers in -lglut... no checking for glutGameModeString in -lglut... no Unable to find the necessary OpenGL or GLUT libraries. See config.log for automated test details and results ... As you can see it cannot find certain functions in the OpenGL glut libraries. Are these functions proprietary to Mesa's implementation of OpenGL, or are they just missing from NVIDIA's implementation. I could put the Mesa libraries back in place, but then I would not get hardware acceleration, which of course defeats the purpose of having this high powered video card in the first place. Any help you can be in answering this would be greatly appreciated. Thanks. Andrig T. Miller ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yeager [OT]
On Saturday 26 October 2002 8:30 pm, Frances Berndt wrote: A little OT, but interesting: http://www.cnn.com/2002/US/West/10/26/yeager.sound.ap/index.html Jon 79 y.o.? I have a mental picture of an F15 travelling at mach 1.45 with blinker on the whole time. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Yeager [OT]
John Check wrote: On Saturday 26 October 2002 8:30 pm, Jon Berndt wrote: A little OT, but interesting: http://www.cnn.com/2002/US/West/10/26/yeager.sound.ap/index.html Jon 79 y.o.? I have a mental picture of an F15 travelling at mach 1.45 with blinker on the whole time. :-D I was thinking he should have said something like: I tried to go faster but at 79 years old it was the best I could muster. - or - I wanted to fly the F-20 but my walker wouldn't fit in the cockpit. :-o Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Norman Vine wrote: Andy Ross wrote: You still haven't answered what it is you want, The functionality of the 2D HUD Seriously, name your requirement Seriously, The functionality of the existing 2D HUD Norman, this isn't constructive. Andy The code used to draw the 3D HUD is by line count 99% the same as the 2D HUD yet you do nothing but berate the 2D HUD code IMHO - This is not constructive and clouds the issue which is You have stated that you have a hook in place that could be used to make a switch as to draw the 2D or the 3D HUD hased on a property yet you apparently have no interest in using it, in stead you continue to berate the 2D HUD code Note my initial message to this thread Your scrollable HUD is GREAT but can you make this a 'preferences' controled option so that we can keep the older HUD as there are many reasons for having a 'fixed' fullscreen HUD too. This is constructive And instead of saying Sure all you have done is berate me and and the code base that you are almostly completely adopting. Please tell us why you have objections to having a 2D and a 3D HUD since obviously they are very similar and would not take much effort to implement. constructive'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] I've got a few minutes to spare
The simgear CVS retrieval still hangs. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Clickable cockpit
David Megginson writes: Speaking of dead code, is anyone still using the old DCS support from main.cxx? I think that it can be completely replaced with the newer 3D model animation code, but I want to make sure I'm not going to break anyone's apps before I rip it out. This was being used by Ranga of the Indian Aeronautical Development Agency. I know they haven't been tracking the latest code releases, but it probably would be neighborly to check with them before we axe the code. There is some other code I've been eyeing as well if we can get their all clear ... the old code to load the old ascii scenery format, some semi-duplicate runway lighting code, and a couple other things. 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] Yeager [OT]
Jon Berndt writes: I tried to go faster but at 79 years old it was the best I could muster. - or - I wanted to fly the F-20 but my walker wouldn't fit in the cockpit. Now, now. When my grandmother was 90, I could barely keep up with her on a walk. The last few years it's gotten easier, but my dad still cannot keep up with her. 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] Clickable cockpit
David Megginson writes:
Andy Ross writes:
Norman, this isn't constructive. Here are some things I'm quite
certain you don't want:
+ A velocity vector that doesn't point where the aircraft is going
see the discussion about the horizon below as to part of the problem
+ HUD scaling that breaks with changes of aspect ratio
The scaling does NOT break with respect to aspect ratio
The display is designed to maintain 'local aspect ratio'
+ HUD scaling that breaks with changes of resolution
see preceeding comment
+ A horizon line that doesn't lie along the horizon
The horizon is in the middle of the screen
which is where the 'neutral' horizon should be
Someone has added a downward component
to the default 'Look Direction' which causes this
This is deflection is I believe a property thus tunable
Perhaps the best solution will be to fork between the actual HUD
(which should be 3D) and a screen-oriented 2D overlay module that uses
the same configuration code to display things like frame-rate,
network-connection status, etc. The beauty of configurability is that
if Norm still wants to see the HUD ladder, etc. in 2D, it should be a
simple matter to whip up an XML configuration file for it.
Yes the preexisting HUD code has been optimized to be just that a
screen-oriented overlay module and IMHO we do not want to lose
this module
Fortunately there is no need to fork
Someone just has to add a property as indicated below
void fgUpdateHUD( void ) {
//if(1) { // replace me with a property
if(fgGetBool(/sim/hud/use3d) {
fgUpdateHUDVirtual();
return;
}
* aside *
I submit that in general the 'proponent of a change' that will break
'long established' fgfs behaviour should consider ways to augment
rather then preclude the previous behaviour esp. in the case where
the vast majoriity of the code of the new behaviour is still the original
code such as this case.
FYI
The 2d HUD code is MUCH quicker then the Panel code and has
almost ZERO impact on framerate and IMHO should be kept intact as
the mechanism of choice for displaying general overlay information
either on the primary screen or on an external monitor. It is very useful
when using fgfs in 'magic mode' to inspect the scenery and I would
expect it to be the HUD of choice for other things like FDM monitoring,
flight reconstruction, inspector consoles etc.
Note this in no way precludes using Andy's 3D HUD patch which BTW
should also have ~zero impact on frame rate since all the real work is
still being done by the underlying screen-oriented module which hasn't
changed
Regards
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt writes: The simgear CVS retrieval still hangs. It is a known problem that using compression with the Cygwin cvs executable will cause an apparent hang FYI What actually happens is a failure to return after the operation has finished, this is indistinguishable from a hang from the client end cvs compression is the -z option Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] I've got a few minutes to spare
Trying to build simgear I get this, too: configure.ac:355: required file `simgear/simgear_config.h.in' not found ?? Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt writes: The simgear CVS retrieval still hangs. It is a known problem that using compression with the Cygwin cvs executable will cause an apparent hang FYI What actually happens is a failure to return after the operation has finished, this is indistinguishable from a hang from the client end cvs compression is the -z option Aha. OK, I thought I had gotten rid of the -z option on the command line I use. Thanks. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt writes: Trying to build simgear I get this, too: configure.ac:355: required file `simgear/simgear_config.h.in' not found Did you run ./autogen.sh before running configure? Connections: a good friend of mine just finished King Air training and passed his check ride this past thursday. He works for the same company that operated Paul Wellstone's plane which crashed on Friday killing him, his wife, his daughter, both pilots and 3 other campain staffers. (Paul Wellstone was a MN senetor running for re-election this fall.) Anyway, my friend knew one of the pilots and had worked previously with him at Pan Am. It would be really interesting to have a King Air in flight gear. We'd need gas turbine engines/turbo props, but my buddy has all sorts of docs and schematics and stuff. I'm a horrible 3d modeller and don't know anything about the flight dynamics, but I'd be happy to impliment a full King Air electrical system if others wanted to do the other parts. :-) 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] I've got a few minutes to spare
Trying to build simgear I get this, too: configure.ac:355: required file `simgear/simgear_config.h.in' not found ?? Jon This error message is returned when running: automake -a by the way (automake (GNU automake) 1.6.1). I had used this to make all the executables for as long as I can remember. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt writes: Trying to build simgear I get this, too: configure.ac:355: required file `simgear/simgear_config.h.in' not found Did you run ./autogen.sh before running configure? Oh, $#!*. I remember this being told to me before. I do almost the same things in my script. I am bound and determined to revise this script so it works again, in light of all the changes made to the build processes. It just makes things so much easier for me. OTOH, it separates me from the real process a little too much so when things change the script breaks. Connections: a good friend of mine just finished King Air training and passed his check ride this past thursday. He works for the same company that operated Paul Wellstone's plane which crashed on Friday killing him, his wife, his daughter, both pilots and 3 other campain staffers. (Paul Wellstone was a MN senetor running for re-election this fall.) Anyway, my friend knew one of the pilots and had worked previously with him at Pan Am. I have a feeling I wouldn't have seen eye-to-eye with many of Wellstone's views (as interpreted and explained by my Minnesota relatives who just finished up a visit with us here in the warm and wet South), but that's sure a tragic thing - his family being wiped out like that. Did he have any other children? My guess is that if Mondale runs, his GOP opponent won't have a prayer. Think so? It would be really interesting to have a King Air in flight gear. I was thinking that, too. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] I've got a few minutes to spare
Did you run ./autogen.sh before running configure? Oh, $#!*. I remember this being told to me before. I do almost the same Looks like the same deal for FlightGear? All I had to do for SimGear was to add the autoheader command to my script. I suspect it is the same for FlightGear. Jon smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] I've got a few minutes to spare
Jon Berndt writes: Connections: a good friend of mine just finished King Air training and passed his check ride this past thursday. He works for the same company that operated Paul Wellstone's plane which crashed on Friday killing him, his wife, his daughter, both pilots and 3 other campain staffers. (Paul Wellstone was a MN senetor running for re-election this fall.) Anyway, my friend knew one of the pilots and had worked previously with him at Pan Am. I have a feeling I wouldn't have seen eye-to-eye with many of Wellstone's views (as interpreted and explained by my Minnesota relatives who just finished up a visit with us here in the warm and wet South), but that's sure a tragic thing - his family being wiped out like that. Did he have any other children? My guess is that if Mondale runs, his GOP opponent won't have a prayer. Think so? This is definitely a terrible tragedy. He had two additional sons and 6 grand kids. Agree or disagree with his views, he was in it for the right reasons -- not to pad his resume or his bank account, but to try his best to make a difference or go down swinging. But, beyond that, it's probably better to discuss the political aspects of all of this in a different forum. :-) It would be really interesting to have a King Air in flight gear. I was thinking that, too. For now, the C310 is probably the closest thing we have ... fgfs --offset-distance=7 --altitude=2500 --vc=120 --airport-id=KEVM --aircraft=c310u3a-3d This will start you off on the west bound approach they were attempting. From what I heard they plane crashed about 2 miles south of the normal approach path. I've also heard they crashed 2 miles away from the airport ... they were heading mostly south when they went in, so for some reason they were way off their approach path, very low. Perhaps they missed their approach and were trying to go around? So far I haven't heard any indication that they've found a mechanical problem, but there wasn't much left of the fuselage and cockpit to look at. The plane wasn't equiped with any sort of cockpit or flight data recorder. Other planes were in the air in the area before and after and no one indicated that the conditions were especially daunting. Ceilings were low (700' or so), but pilots are trained to handle that. So did one of the pilots think they saw the runway and let themselves decend too low and by the time they realized that wasn't the runway they were too low, too slow, out of whack, maybe a little ice??? Or was there some sort of mechanical issue that forced them to abort their approach, try to go around, but they never made it? My buddy who is now officially a King Air pilot was speculating on what sorts of things could catch an experienced pilot off guard ... if you have a runaway prop govener failure, it can make the plane react like the _other_ engine went bad. If you try to shut that down to quickly before figuring out what exactly is going on, you might not realize you are shutting down your good engine ... if you are already 700' agl, that doesn't leave you much room to figure out what's going on, and things go south pretty quickly up there if you get behind the curve ... all complete speculation, hopefully they will find some clues that shed light on what really happened. 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] I've got a few minutes to spare
David Megginson writes: Here is the approach they were flying (I think): https://www.americanflyers.net/ap/default.asp?t=downloadf=L\011L$100.PDF Here is a good mapping engine for the site http://www.dnr.state.mn.us/maps/landview_dhtml.html?mapsize=largezoomsize=2mapext=526604.2253058585+5243958.337905331+549193.77469 41415+5260891.662094669layers=lakes+dlgstln2+roads+gnisxpt3_ppl+none Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] I've got a few minutes to spare
Curtis L. Olson writes: So did one of the pilots think they saw the runway and let themselves decend too low and by the time they realized that wasn't the runway they were too low, too slow, out of whack, maybe a little ice??? Not if they had a serviceable DME, unless they completely lost situational awareness. 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] I've got a few minutes to spare
David Megginson writes: Curtis L. Olson writes: So did one of the pilots think they saw the runway and let themselves decend too low and by the time they realized that wasn't the runway they were too low, too slow, out of whack, maybe a little ice??? Not if they had a serviceable DME, unless they completely lost situational awareness. Of course this is all complete speculation, but I hear it is common practice that one pilot has his eyes inside the cockpit and the other watches outside. There is a VOR/DME at the airport, but no ILS. Since this is a non-precision approach, it's unlikely that you'll pop out of the clouds directly in line with the runway. Also (again this is speculation) this is up on the MN iron range so there are significant iron ore deposits around. I have no idea if that could have factored in, but it can't help if you are trying a last minute DG adjustment. So anyway, if the pilot looking out the windows *thought* he saw the airport, and they headed for it visually... No one really knows of course, and other planes flew in the area before and after the crash, so the conditions weren't unreasonable. Weather was crappy that day across the whole state, and the ceilings were close to minumums, but that should have all been within the capabilities of the aircraft and the pilots. Did they break out of the clouds and have to dodge a flock of geese? It's that time of year here where they are heading south. It's all too wierd. It seems similar to driving by an automobile accident and trying to figure out a set of circumstances that would have led up to the vehicles getting to where they were. I guess whatever happened, whether it was mechanical, or pilot error, it happened too late in the approach and too close to the ground for them to successfully recover. In that sense, weather couldn't have been helpful. It's all very sad. At the very least you hope that they are able to figure out what caused the crash so we can prevent anything like it from happening 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
RE: [Flightgear-devel] I've got a few minutes to spare
On Behalf Of Curtis L. Olson I guess whatever happened, whether it was mechanical, or pilot error, it happened too late in the approach and too close to the ground for I heard an eyewitness acct. that mentioned a severe crab prior to the crash. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Yeager [OT]
On Sunday 27 October 2002 7:03 pm, Jon Berndt wrote: John Check wrote: On Saturday 26 October 2002 8:30 pm, Jon Berndt wrote: A little OT, but interesting: http://www.cnn.com/2002/US/West/10/26/yeager.sound.ap/index.html Jon 79 y.o.? I have a mental picture of an F15 travelling at mach 1.45 with blinker on the whole time. :-D I was thinking he should have said something like: I tried to go faster but at 79 years old it was the best I could muster. - or - I wanted to fly the F-20 but my walker wouldn't fit in the cockpit. :-o Jon Well at least I won't be the -only- one burning in hell ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
