Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Sure there is. But the ladder will only work at 1024x768 with the default view direction and field of view. Andy Sorry but this is patently false and no matter how often you repeat yourself nor how colorful the language is that you use this will still be false ! The current HUD ladder works fine at all resolutions with all view directions once you accept the fact that it is a 2D Overlay instrument that is designed to have a fixed layout FWIW this is often what HUD means in simulators In aircraft simulation and training applications, it is often necessary to provide the Instructor/Operator with the pilot's view of the Head-Up Display (HUD)superimposed on the Out-The-Window scene http://www.folsom.com/Product_page/Simulation/HUD_Visual_Mixer/body_hud_visual_mixer.htm The current code was written to satisfy the requirement above What you want is the is a First Person's Pilots View of the HUD Great Idea, great addition to the codebase, glad that the existing 2D HUD overlay generator code has stuff that makes it easier for you to program one But please DO NOT BREAK the existing 2D HUD Overlay code in the process Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
IMHO What, Norman and me want is this. When you scroll your view to whatever direction or switch to whatever view, you always see the HUD as if you look forward from cockpit. It is highly usable when you look around, but still want to drive the aircraft. You are true, that you can use 2-D panel too, but in some situations is HUD usefull more. Regards, MaDr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Clickable cockpit
Agreed, I use the HUD for this purpose too. I suppose that this use is actually in lieu of a (glass) cockpit display on a second monitor. It always gives you the information you need to navigate the aircraft, regardless of the view. Richard -Original Message- From: Martin Dressler [mailto:dr;musicabona.cz] Sent: 29 October 2002 2:22 pm To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Clickable cockpit IMHO What, Norman and me want is this. When you scroll your view to whatever direction or switch to whatever view, you always see the HUD as if you look forward from cockpit. It is highly usable when you look around, but still want to drive the aircraft. You are true, that you can use 2-D panel too, but in some situations is HUD usefull more. Regards, MaDr ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Clickable cockpit
Andy wrote: The first is just a port of an old 3D HUD patch to the new view code. This pans the HUD with the view, by pasting it onto a quad fixed in front of the viewer. Let me make sure I understand this: the patch essentially makes the HUD appear as though it is in proper placement as if it were in a real (3D) cockpit, and if you move your viewing angle (via mouse?) the HUD does not sit as an overlay on the screen, but instead moves so as to stay where it would in a real (3D) world - that is, projected onto the glass part of the HUD. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Clickable cockpit
Norman Vine wrote: Andy Ross writes: Sure there is. But the ladder will only work at 1024x768 with the default view direction and field of view. The current HUD ladder works fine at all resolutions with all view directions once you accept the fact that it is a 2D Overlay instrument that is designed to have a fixed layout We're arguing from different definitions. I want the horizon line to line up along the horizon, the N degree lines to be N degrees from the horizon, the glide path indicator to lie along the right glide path, and the velocity vector to point where the aircraft is travelling. The existing HUD can only do this at one resolution, one field of view, and one aspect ratio. Since these aren't the values that I use (well, except aspect ratio -- I have a 4:3 monitor like everybody else), the existing code doesn't work for me. This isn't because I'm wrong or right, but because I want the code to do different things. I'm sorry you don't like my requirements. I honestly did try to accomodate yours. Really. 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
On Mon, 2002-10-28 at 22:05, Julian Foad wrote: - Julian Foad, Secretary, IASFGP (International Arbitration Service for Flight Gear Programmers) ^^ NICE (Neutral Integration, of Certified Extrapolations) Later, Chris ___ 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
Andy Ross writes:
OK, I *finally* got a chance this weekend to sit down and crank on
FlightGear code. It's been a while. Attached are three patches for
review. Complete files for Curt are available at:
http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz.
The first is [ bleep :-) ]
The second adds angular rate information to the FDM output properties.
I needed this to get autostabilization working on the Harrier model
(more on this soon in a post to the flightmodel list). Very
trivial.
This is added.
The biggest and coolest patch ...
Andy, very cool, almost works reliably. Definitely a huge addition to
the 3d panels, great work!
I did notice on rare occasion some areas were getting mismapped.
I.e. I couldn't click on the wing leveler, but I could click the other
autopilot buttons. Another time I was trying to switch the DME
between nav1 and nav2 and my right engine died ... looks like the
magneto switch mistakenly grabbed the click. But most of the time the
stuff works great!
... 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:
+ The list of all 3D cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another update hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
mouse press delay, and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
Anyway, try it out and see what breaks.
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)
Index: src/Cockpit/hud.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/hud.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 hud.cxx
--- src/Cockpit/hud.cxx 10 Sep 2002 01:13:59 - 1.1.1.1
+++ src/Cockpit/hud.cxx 26 Oct 2002 22:05:24 -
@@ -171,6 +171,8 @@
static instr_item * readCard ( const SGPropertyNode * node);
static instr_item * readLabel( const SGPropertyNode * node);
static instr_item * readTBI( const SGPropertyNode * node);
+static void drawHUD();
+static void fgUpdateHUDVirtual();
//$$$ end - added, Neetha, 28 Nov 2k
void fgHUDalphaInit( void );
@@ -310,6 +312,11 @@
nadir= node-getIntValue(nadir); //suma
hat = node-getIntValue(hat);
+// The factor assumes a base of 55 degrees per 640 pixels.
+// Invert to convert the compression factor to a
+// pixels-per-degree number.
+if(factor == 0) factor = 1;
+factor = (640./55.) / factor;
SG_LOG(SG_INPUT, SG_INFO, Done reading instrument name);
@@ -1038,7 +1045,12 @@
// all C++.
//
void fgUpdateHUD( void ) {
-
+
+if(1) {
+fgUpdateHUDVirtual();
+return;
+}
+
static const float normal_aspect = float(640) / float(480);
// note: aspect_ratio is Y/X
float current_aspect = 1.0f/globals-get_current_view()-get_aspect_ratio();
@@ -1053,9 +1065,78 @@
}
}
+void fgUpdateHUDVirtual()
+{
+FGViewer* view = globals-get_current_view();
+
+// Standard fgfs projection, with essentially meaningless clip
+// planes (we'll map the whole HUD plane to z=-1)
+glMatrixMode(GL_PROJECTION);
+glPushMatrix();
+glLoadIdentity();
+gluPerspective(view-get_v_fov(), 1/view-get_aspect_ratio(), 0.1, 10);
+
+glMatrixMode(GL_MODELVIEW);
+glPushMatrix();
+glLoadIdentity();
+
+// Standard fgfs view direction computation
+float lookat[3];
+lookat[0] = -sin(SG_DEGREES_TO_RADIANS *
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Curtis L. Olson wrote: Andy, very cool, almost works reliably. Definitely a huge addition to the 3d panels, great work! I did notice on rare occasion some areas were getting mismapped. I.e. I couldn't click on the wing leveler, but I could click the other autopilot buttons. Another time I was trying to switch the DME between nav1 and nav2 and my right engine died ... looks like the magneto switch mistakenly grabbed the click. But most of the time the stuff works great! Uh... dunno. Haven't seen this behavior yet. How rare? Maybe we should put in some debug logging so we can see the panel coordinates that got generated from the input screen coordinates. Were you in the process of panning or switching the view? The code works by storing the last matrix environment seen. If there was a frame or two of latency between the glutSwapBuffers() and the mouse event delivery, then I guess something like this could happen. Then again, it's awfully hard to imagine a human being hitting a mouse target within 1/20 of a second after a view change... I seem to have particular problems with the wing leveler button, you might try moving the view, then clicking, then moving the view again, etc. Other buttons / areas seem to be more reliable ... 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] Clickable cockpit
Andy Ross submitted a patch which changes the way the HUD works. Norman Vine wants the old behaviour to remain available as an option. I really shouldn't get involved in this, but ... well ... here are my views. When a developer changes a program that is used by other people, he/she needs to consider the inconvenience that change may cause, and to minimise that inconvenience as far as is compatible with the other aims. Perhaps someone has developed other software which interfaces to FlightGear and will need to be changed to accommodate these changes. For example, Andy says he has inverted the sense of the compression tag to correct it. If the only configuration files that matter are under our control then he should supply a patch to fix them and the correction will be complete. If users are likely to have their own files which would, after this patch, be broken, he should consider fixing the problem in a backward-compatible manner, e.g. by deprecating the existing tag while introducing a new one. The important point is how to judge, for each little change, whether backward compatibility is worth the effort. Airing the proposed change and listening to objections is an OK way to do this. However, when the number of people objecting is small, the objection itself appears small unless it is backed up by reasons. Norman seems to be wanting backward compatibility in general, which may indicate that he _uses_ this flight simulator more than _plays_ with it, which is great. Unfortunately it takes a lot of effort to keep backward compatibility in every respect, and so the request is just wishful thinking unless it can be narrowed down to specific items of importance. Because Norman's skill and contributions to the project are respected, other developers want to keep the features that he values while still being able to develop the software and change things that don't seem right. If no progress is made soon, I recommend that the old behaviour option be implemented, and that Andy should modify the if statement so that it can be selected at run time. That would seem to satisfy the current objection, subject to the compatibility of the HUD configuration files being satisfactory. Then a separate patch to delete the old functionality can be proposed immediately, and the discussion of that can continue without holding up development in the short term. When the maintenance of that old codes becomes a hindrance, that will be an argument for removing it. At least, in the short term, it will be useful to have the old version available while any issues with the new version are resolved. Finally, I believe V. S. Renganathan did substantial work on the HUD for use in a research project. If anyone knows whether he is still interested in it, that might also be helpful. Please let the resolution be swift and easy so that developers will not be put off trying to change anything. - Julian Foad, Secretary, IASFGP (International Arbitration Service for Flight Gear Programmers) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Julian Foad wrote: Andy Ross submitted a patch which changes the way the HUD works. Norman Vine wants the old behaviour to remain available as an option. I really shouldn't get involved in this, but ... well ... here are my views [... views snipped ...] Sounds good to me. I'm still not quite sure what the argument was about. For example, Andy says he has inverted the sense of the compression tag to correct it. Not quite. The big change was making it resolution, FOV, and aspect ratio independent. I figured that if it had to be changed anyway, I might as well invert it to mean what it says. There is no way to keep the old scaling scheme and be view-independent at the same time, sadly. 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: Not quite. The big change was making it resolution, FOV, and aspect ratio independent. I figured that if it had to be changed anyway, I might as well invert it to mean what it says. There is no way to keep the old scaling scheme and be view-independent at the same time, sadly. If this is true then there is no way we can maintain a 2D overlay, library which is what the existing HUD code is, with Andy's changes So the question is Is someone going to write a 3D HUD package, or am I going to have to rewrite a 2D overlay engine again. My guess is that whoever works on implementing a true 3D HUD would be better off starting with a new OO design much like the Panel code rather then kludging YAN hack onto the aged 2D hacks that comprise the existing 2D HUD code which BTW is no where near as bad as Andy's colorful language makes it out to be grin other-wise-he-woudn't-be-using-it'ly yr's / Norman ___ 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: There is no way to keep the old scaling scheme and be view-independent at the same time, sadly. If this is true then there is no way we can maintain a 2D overlay, library which is what the existing HUD code is, with Andy's changes Sure there is. But the ladder will only work at 1024x768 with the default view direction and field of view. That limitation is OK (I guess) for the 2D stuff, since it wasn't a problem for anyone before. But it's a show stopper for view independence, so I had to fix it. You can't seriously be arguing that replacing a magic compression factor of 12.6316 (I'm pretty sure the correct value should be 11.6363, FWIW) with 1 is a bad thing? It even works in 2D mode, so long as you are running at the right resolution. I mean, take another look and maybe re-read the thread. I still completely fail to understand what has you so upset. Everything you wanted, you have. To change the subject a little: Has anyone looked at the other two patches yet? One is trivial and would be really nice to get into the code base pronto. The other is an important feature that really requires discussion before it goes in. 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
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] 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] 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
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] 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] 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] 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
[Flightgear-devel] Clickable cockpit
OK, I *finally* got a chance this weekend to sit down and crank on
FlightGear code. It's been a while. Attached are three patches for
review. Complete files for Curt are available at:
http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz.
The first is just a port of an old 3D HUD patch to the new view code.
This pans the HUD with the view, by pasting it onto a quad fixed in
front of the viewer. It also fixes the awful, arbitrary scaling
problems the HUD code has. The old HUD only looks right when viewed
at 1024x768 and 55 degree FOV. This works the scale out magically so that it
looks right in all views. It also redefines the
compression-factor tag in the ladder to (1) mean compression
instead of expansion and (2) have non-psychopathic units (now 1
means 1 degree per degree). Fix this in your existing HUD ladder
files before reporting bugs. It's definitely a cosmetic win -- the
velocity vector points at the right thing and the horizon lines up
properly.
The second adds angular rate information to the FDM output properties.
I needed this to get autostabilization working on the Harrier model
(more on this soon in a post to the flightmodel list). Very trivial.
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:
+ The list of all 3D cockpits is stored statically in the
panelnode.cxx file. This is clumsy, and won't migrate well to a
multiple-aircraft feature. Really, there should be a per-model list
of 3D panels, but I couldn't find a clean place to put this. The
only handle you get back after parsing a model is a generic ssg
node, to which I obviously can't add panel-specific methods.
+ The aircraft model is parsed *very* early in the initialization
order. Earlier, in fact, than the static list of allowable command
bindings is built in fgInitCommands(). This is bad, as it means
that mouse bindings on the instruments can't work yet. I moved the
call to fgInitCommands, but someone should look carefully to see
that I picked the right place. There's a lot of initialization
code, and I got a little lost in there... :)
+ I added yet another update hook to the fgRenderFrame routine to
hook the updates for the 3D panels. This is only required for
mouse press delay, and it's a fairly clumsy mechanism based on
frame rate instead of real time. There appears to be delay handling
already in place in the Input stuff, and there's a discussion going
on about different mouse behavior right now. Maybe this is a good
time to unify these two (now three) approaches?
Anyway, try it out and see what breaks.
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)
Index: src/Cockpit/hud.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/hud.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 hud.cxx
--- src/Cockpit/hud.cxx 10 Sep 2002 01:13:59 - 1.1.1.1
+++ src/Cockpit/hud.cxx 26 Oct 2002 22:05:24 -
@@ -171,6 +171,8 @@
static instr_item * readCard ( const SGPropertyNode * node);
static instr_item * readLabel( const SGPropertyNode * node);
static instr_item * readTBI( const SGPropertyNode * node);
+static void drawHUD();
+static void fgUpdateHUDVirtual();
//$$$ end - added, Neetha, 28 Nov 2k
void fgHUDalphaInit( void );
@@ -310,6 +312,11 @@
nadir = node-getIntValue(nadir); //suma
hat= node-getIntValue(hat);
+// The factor assumes a base of 55 degrees per 640 pixels.
+// Invert to convert the compression factor to a
+// pixels-per-degree number.
+if(factor == 0) factor = 1;
+factor = (640./55.) / factor;
SG_LOG(SG_INPUT, SG_INFO, Done reading instrument name);
@@ -1038,7 +1045,12 @@
// all C++.
//
void fgUpdateHUD( void ) {
-
+
+if(1) {
+fgUpdateHUDVirtual();
+return;
+}
+
static const float normal_aspect = float(640) / float(480);
// note: aspect_ratio is Y/X
float current_aspect = 1.0f/globals-get_current_view()-get_aspect_ratio();
@@ -1053,9 +1065,78 @@
}
}
+void fgUpdateHUDVirtual()
+{
+FGViewer* view = globals-get_current_view();
+
+// Standard fgfs projection, with essentially meaningless clip
+// planes (we'll map the whole HUD plane to z=-1)
+glMatrixMode(GL_PROJECTION);
+glPushMatrix();
+glLoadIdentity();
+gluPerspective(view-get_v_fov(), 1/view-get_aspect_ratio(), 0.1, 10);
+
+glMatrixMode(GL_MODELVIEW);
+glPushMatrix();
+glLoadIdentity();
+
+// Standard fgfs view direction computation
+float
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: OK, I *finally* got a chance this weekend to sit down and crank on FlightGear code. It's been a while. Attached are three patches for review. Complete files for Curt are available at: http://www.plausible.org/fgfs-andy-2002Oct26.tar.gz. The first is just a port of an old 3D HUD patch to the new view code. This pans the HUD with the view, by pasting it onto a quad fixed in front of the viewer. Andy 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. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
