Re: [Flightgear-devel] screen shots lights
Jim Wilson wrote: Hmmm...I don't remember ever having to to look up to see lights when running the voodoo card. When you say very high, how high do you mean? It looks like about 2m to me. Is it possible that you guys are just using different aircraft? David tends to hang out in the Cub and 172 a lot, which have rather low cockpits. The jets (and especially the 747) are much higher. 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
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
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
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
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
[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] Numeric Terminology
Frederic Bouvier wrote: What do you think of that (translated from french) : Left : integral part right : mantissa Actually, in English that is ambiguous. The term mantissa is already used to refer to the scalar multiple in a number with an exponent. That is: mantissa * base ^ exponent. It will typically lie outside the range [0:1) My vote for this term would be integral part and fractional part, for what it's worth. Obviously there aren't any existing standards. :) 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] FlightGear 0.8.0 on Win98SE
Richard Bytheway wrote: We really ought to sort out the ability to disable *any* console output after initialisation on Windows... Is it maybe time to revisit the priority of most of the log messages? I mean, the vast majority of these things are debugging output for code that is mature and stable. Even most developers don't care about tile cache behavior anymore. Some stuff is still useful, like the YASim solution report and the JSBSim landing report. Other stuff is harmless, like the material loading messages which aren't very useful but at least tell you the sim isn't hung on startup. But IMHO, almost everything after the initialization pass can be pushed down to the print only when debugging level. Alternative, a really cool eye-candy suggestion would be to maintain the console log internally and display it with a popup console or somesuch, a-la Quake. :) 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] ***long*** pauses after flying a while
David Megginson wrote: How big is the hit if you simply delete a higher-level node and let plib delete all of the branches and leaves underneath automatically? Probably equivalent. The overhead is usually in all the per-chunk bookeeping, not the function calls. We could try playing games with operator new, I suppose. We know for a fact that all these objects will be deleted at the same time, so we can in theory do much better than a general purpose allocator. The apache webserver has a similar issue -- they have lots of code that needs to do allocation from disparate areas, but they know for a fact that all of this stuff will be obsolete once the current request finishes. So they have a pool API where handlers can go for memory without all the bookeeping overhead. The request just doles it out as needed and frees it all at once. Code that needs destructor functionality can register a callback that will fire before the free is called. In our situation, this should work pretty well. It might need some hacking in plib to make it work cleanly, though. Lots of work, but with real performance benefits. 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] ***long*** pauses after flying a while
David Megginson wrote: Curt's problem, though, is that his deletion code has to do a linear search in the parent for each child node to remove it; I assume that plib's internal code just iterates. Ah, never mind then. :) Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no allocator hack is going to fix that for us. I'm with David now; plib might have trouble doing constant-time deletion of children, but it certainly should handle a plain old recursive destruction just fine. Does it not? 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
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] 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] breakage
John Check wrote: Latest cvs build falls down with: pt_lights.cxx:304: `cout' undeclared (first use this function) You're using gcc 3.2 I assume? It's a namespace issue. The C++ standard library naming is stricter now. You need to use std::cout, or insert a using namespace std; above the usage. main.cxx:153: void (*glPointParameterfvEXT)(unsigned int, const GLfloat*) /usr/X11R6/include/GL/gl.h:2520: glPointParameterfvEXT(unsigned int, const GLfloat*)' OK, this one looks kinda wrong. Our code is defining its own copy of the glPointParameter function pointers, when they've already been declared as regular functions in gl.h. What's the purpose here? All of the declared extensions are supposed to be defined in the ARB glext.h header, I believe. User-level code shouldn't have to play this kind of game anymore. It's worth pointing out that I don't see this issue. I have the NVidia drivers installed, which might have differeing header behavior? 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] breakage
diff -u -w -r1.31 main.cxx
--- main.cxx17 Oct 2002 04:34:32 - 1.31
+++ main.cxx19 Oct 2002 18:38:22 -
@@ -141,16 +141,16 @@
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname,
const GLfloat *params);
- PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0;
- PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0;
+ PFNGLPOINTPARAMETERFEXTPROC gl_PointParameterfEXT = 0;
+ PFNGLPOINTPARAMETERFVEXTPROC g_lPointParameterfvEXT = 0;
#elif linux
#include GL/glx.h
typedef void (* OpenGLFuncExt)(GLenum pname, GLfloat param);
typedef void (* OpenGLFuncExtv)(GLenum pname, const GLfloat *params);
- OpenGLFuncExt glPointParameterfEXT = 0;
- OpenGLFuncExtv glPointParameterfvEXT = 0;
+ OpenGLFuncExt gl_PointParameterfEXT = 0;
+ OpenGLFuncExtv gl_PointParameterfvEXT = 0;
#endif
float default_attenuation[3] = {1.0, 0.0, 0.0};
@@ -743,8 +743,8 @@
glEnable(GL_POINT_SMOOTH);
float quadratic[3] = {1.0, 0.001, 0.001};
// makes the points fade as they move away
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
-glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
+gl_PointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
glPointSize(4.0);
}
@@ -774,7 +774,7 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
if (glutExtensionSupported(GL_EXT_point_parameters)) {
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
default_attenuation);
}
@@ -1578,14 +1578,14 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
// get the address of our OpenGL extensions
# ifdef WIN32
-glPointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
+gl_PointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
wglGetProcAddress(glPointParameterfEXT);
-glPointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
+gl_PointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
wglGetProcAddress(glPointParameterfvEXT);
# elif linux
-glPointParameterfEXT = (OpenGLFuncExt)
+gl_PointParameterfEXT = (OpenGLFuncExt)
glXGetProcAddressARB((GLubyte *)glPointParameterfEXT);
-glPointParameterfvEXT = (OpenGLFuncExtv)
+gl_PointParameterfvEXT = (OpenGLFuncExtv)
glXGetProcAddressARB((GLubyte *)glPointParameterfvEXT);
# endif
#endif
--
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] breakage
[Er, oops. The last one had the patch but not the text. Apologies!]
OK, looking more carefully, I think I see how this is supposed to
work. Because not all OpenGL implementations export the
PointParameter functions, Curt is using function pointers and the
GetProcAddress stuff.
This is fine; the only bug is that the names of the function pointers
are identical to the names of the functions. This is attractive,
because you can use the same syntax for both.
But it doesn't work across all implementations. In some, the
definition of the functions are as regular functions, not pointers.
So while the invocation syntax is the same, the assignment syntax is
not. You can't redeclare a regular function as a function pointer --
they're not compatible types.
The following patch just renames the symbol used to avoid the
collision. It seems to work for me.
Andy
diff -u -w -r1.31 main.cxx
--- main.cxx17 Oct 2002 04:34:32 - 1.31
+++ main.cxx19 Oct 2002 18:38:22 -
@@ -141,16 +141,16 @@
typedef void (APIENTRY * PFNGLPOINTPARAMETERFVEXTPROC)(GLenum pname,
const GLfloat *params);
- PFNGLPOINTPARAMETERFEXTPROC glPointParameterfEXT = 0;
- PFNGLPOINTPARAMETERFVEXTPROC glPointParameterfvEXT = 0;
+ PFNGLPOINTPARAMETERFEXTPROC gl_PointParameterfEXT = 0;
+ PFNGLPOINTPARAMETERFVEXTPROC g_lPointParameterfvEXT = 0;
#elif linux
#include GL/glx.h
typedef void (* OpenGLFuncExt)(GLenum pname, GLfloat param);
typedef void (* OpenGLFuncExtv)(GLenum pname, const GLfloat *params);
- OpenGLFuncExt glPointParameterfEXT = 0;
- OpenGLFuncExtv glPointParameterfvEXT = 0;
+ OpenGLFuncExt gl_PointParameterfEXT = 0;
+ OpenGLFuncExtv gl_PointParameterfvEXT = 0;
#endif
float default_attenuation[3] = {1.0, 0.0, 0.0};
@@ -743,8 +743,8 @@
glEnable(GL_POINT_SMOOTH);
float quadratic[3] = {1.0, 0.001, 0.001};
// makes the points fade as they move away
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
-glPointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT, quadratic);
+gl_PointParameterfEXT(GL_POINT_SIZE_MIN_EXT, 1.0);
glPointSize(4.0);
}
@@ -774,7 +774,7 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
if (glutExtensionSupported(GL_EXT_point_parameters)) {
-glPointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
+gl_PointParameterfvEXT(GL_DISTANCE_ATTENUATION_EXT,
default_attenuation);
}
@@ -1578,14 +1578,14 @@
#ifdef FG_EXPERIMENTAL_LIGHTING
// get the address of our OpenGL extensions
# ifdef WIN32
-glPointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
+gl_PointParameterfEXT = (PFNGLPOINTPARAMETERFEXTPROC)
wglGetProcAddress(glPointParameterfEXT);
-glPointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
+gl_PointParameterfvEXT = (PFNGLPOINTPARAMETERFVEXTPROC)
wglGetProcAddress(glPointParameterfvEXT);
# elif linux
-glPointParameterfEXT = (OpenGLFuncExt)
+gl_PointParameterfEXT = (OpenGLFuncExt)
glXGetProcAddressARB((GLubyte *)glPointParameterfEXT);
-glPointParameterfvEXT = (OpenGLFuncExtv)
+gl_PointParameterfvEXT = (OpenGLFuncExtv)
glXGetProcAddressARB((GLubyte *)glPointParameterfvEXT);
# endif
#endif
--
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] breakage
John Check wrote: Is this last line correct? Uh, no. :) Sorry. I don't compile on a windows box, so that part of the change was blind. Obviously, the actual names of the symbols used isn't important. You could just as easily use GL or fg, or fgfsgl or whatnot so long as it's consistent and doesn't collide with the existing OpenGL names. But the patch should have applied cleanly -- it just would have failed during compilation. Or is that what you meant? 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
[Flightgear-devel] Panel font crash
I grabbed current CVS last night for the first time in a while, and got bitten by a bug with the 3D panel support. Has anyone else noticed this? What happens is that on an aircraft with no 2D panel at all (a4, c172-3d, but oddly not the j3cub), the sim crashes at startup. The first problem was that the gcc 3.2 optimizer made a total hash out of the stack, and gdb was useless. I don't know if that's a feature or a bug... Recompiling with -O1 showed that the led_font object in panel.cxx was never initialized. This is a static object that gets created in Panel::init(). Well, init() doesn't get called for 3D panels, because it touches static state. I clearly said so in my comment. :) But since no 2D panel gets created, this is left null at runtime. The attached one-liner fixes the problem, but someone with more knowlege should probably think of a better solution. We shouldn't be initializing static state from within a member initializer. Maybe there's a need for a panel subsystem as separate from the individual FGPanel objects? A minor bug, too, is that this leaks memory. One font gets created per panel, and then dropped on the floor when the next panel is initialized. I'm not sure if it allocates an OpenGL texture object for each one or not. If it does, then this is definitely something we should fix. Andy diff -u -r1.1.1.1 panelnode.cxx --- panelnode.cxx 10 Sep 2002 01:14:08 - 1.1.1.1 +++ panelnode.cxx 18 Oct 2002 18:02:08 - @@ -14,6 +14,8 @@ // it -- those methods touch static state. _panel = fgReadPanel(props-getStringValue(path)); +_panel-init(); + // Read out the pixel-space info _xmax = _panel-getWidth(); _ymax = _panel-getHeight(); -- 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] TC ball
Curtis L. Olson wrote: it seems to be more than a simple coordinate system difference, unless JSBSim/YASim swap X/Y axes or something strange like that. Could be a bug, too. What exactly is the behavior you're seeing? The way the code in steam works is to look at the Y and Z pilot acceleration vectors and compute a down direction. Is it the direction that's wrong? * Not the same as coordinate acceleration, for the reasons discussed before. And it shouldn't use X, which is the longitudinal axis. The ball is constrained by its housing to the YZ plane. The steam.cxx code is the only place that uses these numbers, so a bug could easily have gone unnoticed. I haven't looked at the ball in a while, honestly, but I don't remember being surprised by anything looking wrong. 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] Licensing issues
Curtis L. Olson wrote: Question: for a particular source file, if a person contributed a minor patch or tweak to compile on a new platform, does that person now have a full say in the future of that source, or are they giving their changes to the author of that file to be placed under the license terms chosen by the primary author. It goes by change, not by file. They contributed a patch under an existing license, not a new one. So you can't legally change their license without removing the patch; nothing gives you the right to their work. In practice, what this means is that you need to get most of the developers on board. If someone doesn't agree, you need to be prepared to remove their code and reimplement it. You don't necessarily need to remove every 2-line patch submitted on the assumption that the author doesn't agree. It's enough to announce the license change in the appropriate forum for FlightGear development (here, of course) and expect that people interested will notice and tell you about problems. IANAL, of course. But this is the way it's worked in other projects (Wine, especially) that have gone through license changes. But under no circumstances can you relicense someone else's code over their objections. If someone makes a stink, you have to snip it out. 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] Licensing issues
Alex Perry wrote: There is a subtle distinction, which essentially means that, since you do still have the copyright, people who retrieve the code also have the right to sue you. It's even more subtle: the right to sue you doesn't go with the copyright. The copyright is a right that *you* have to restrict distribution. The right to sue for damages is someone else's, and is inherent (with lots of legislative exceptions). Basically, regardless of what you do with your copyright: if you wrote the code, it's your fault. This is why the GPL has its warranty clause, and why commercial licenses always have the limitation of liability clause. 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] TC ball
Tony Peden wrote: Well, I tried to compare the two, but got this for the yasim c172: YASim SOLUTION FAILURE: Are you sure you have current code and base package? I haven't looked at the 172 in a good while, and not much has changed. Do the other YASim aircraft work for you? 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] TC ball
Curtis L. Olson wrote: The JSBSim drives the ball in a reasonable way, as does this other FDM I'm playing with. However, the scaling is about an order of magnitude different between the two, even though they supposedly report the accels in the same units and are modeling the same aircraft. YASim seems to drive the ball yet another order of magnitude further. Hrm... yup, that sounds awfully wrong. Especially since units shouldn't matter. What the steam.cxx code is doing is taking the sideways acceleration and dividing it by the vertical acceleration to get a down direction. The units should drop out. I could be reporting accelerations in mph per year and it should still work. Could you stick some printfs in and get a feel for the numbers that are coming out? I mean, just print Ay and Az for each sim under broadly similar conditions and see if anything is obviously wrong. Unless you're doing aerobatics, Z should be very close to 32 and Y should be near zero. If this is happening in the air, it might not be the acceleration code at all, but the side-force-per-slip-angle behavior that is different. Try testing while doing constant rate turns on the ground to see if they behave the same there. 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] Licensing issues
Alex Perry wrote: I don't see a real benefit of changing FGFS from GPL to LGPL ... * The people who don't like GPL probably aren't much happier about LGPL * They (or we) can add a shared-memory tunnel in SimGear for properties * Most proprietary extensions can simply coexist as separate programs I'm inclined to agree. The only real purpose behind the LGPL is to special case the situation of GNU versions of system libraries. Applying the GPL strictly to libraries like libc or libstdc++ means that proprietary software can't be run on free operating systems, since the act of linkage makes them a derived work according to the license. That's silly, so there's a special-purpose variant of the license that allows linkage (but *only* linkage) of proprietary code. The LGPL has since become popular for library projects that are designed to become standards, or at least widely shared. Projects like plib and SDL use it for that reason -- to keep development open while encouraging use of the library by anyone. FlightGear doesn't really fall into either category, since it's a one-of-a-kind codebase that is used only by other GPLed software. It strikes me that putting, say, the scenery engine under the LGPL isn't likely to encourage anyone to use it as the standard scenery engine for anything. Users who want the code are likely going to want to hack at it for their own purposes, which the LGPL forbids. Is there a use case here, or a particular proprietary application you have in mind? It might be simpler to do a custom release to that vendor under a separate license, rather than play with the license for the whole project. The LGPL is a little problematic for most proprietary users. They aren't, contrary to common belief, allowed to use the library any way they want. They have to link expressly against the library as shipped (no cutting and pasting of code), and have to ensure that future users can relink against newer versions of the library if they want (no static linkage, essentially). 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] Airport Database Model
David Megginson wrote: Remember Knuth's (?) warnings about premature optimization, though. Amen. This blog says Knuth got it from Tony Hoare: We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. http://www.cookcomputing.com/blog/archives/84.html In that case, a simple linear search within the chunk and its neighbours is probably acceptable; for that matter, a linear search through the whole airport list wouldn't be that bad. Exactly. A typical use case might be a UI to search through all airports by name. So typing in New York would pull up Laguardia, Kennedy, etc... Users are happy to wait for 2 seconds or so for such a list. If, however, there's a reason that we'd want to redo the airport search every frame or every few frames, like we do for the navaids, then some kind of indexing will be essential. Right. But this indexing of nearby objects can be done in memory (since the set of nearby objects is already available via the tile set). There's not need for anything fancy on disk. 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] Airport Database Model
Julian Foad wrote: I thought it was the other way around: that most Linux filesystems (by which I mean ext2) and NTFS had 1K or 0.5K blocks, and that Windows FAT filesystems had big (generally 4K to 16K) blocks. Nope, 4k. The underlying disks have 512 byte blocks (all IDE and most SCSI, at least), but the OS doesn't cut things that fine. The 4k block size matches the processor page size on x86 and most other processors, so it makes things like swap and mmap'ed I/O simpler to implement. You can see this for yourself pretty easily (this is ext3; I'd be curious to see what the results are on other filesystems): # Make a scratch area mkdir foo cd foo # Make 100 empty files for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do touch $i$j done done # Note that no space is taken up by the empty files, only 4k for the # directory itself cd .. du -s foo # Now append one byte to each of them cd foo for i in *; do echo $i done # Note that the directory now contains 404k -- 4k per file cd .. du -s foo -- 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] Airport Database Model
Simon Fowler wrote: One thing to note here is that all this cache take up RAM, and will be dropped on the floor as soon as there's any memory pressure. Right, which is why I was careful to cite numbers that reflected actual disk I/O, and not cache performance. Even hitting the disk, performance is acceptable. If most machines are faster than that, it's a bug not a feature. :) Performing well under Linux with ReiserFS is a good advertisement for Linux and ReiserFS, but not so good for FlightGear if that's /all/ we perform well under. I think you have perhaps misinterpreted. My point was that a blunderingly simple file-per-airport scheme was adequate on all filesystems, not that it required fancy stuff. The reiserfs note was a fun bit of trivia about how OS authors try to accomodate stuff like this. If we work everywhere, but are blazingly fast (or take up far less space) under linux/reiserfs, I'd again consider that a feature and not a bug. I rather like the idea of the airport files being /part/ of the scenery. It certainly seems to be where they'd belong, logically speaking. [...] there've been several reports of runways and their navaids being completely out of sync with the scenery, and this seems like a good way to fix them. Right. The only complication is that there's an existing use case that requires doing fast lookup of airports by ID. My idea was to distribute files with the scenery and drop them in a single global directory. Trivially simple to implement and maintain -- users who discover airport or navaid bugs can just fix the file and post it to the mailing list; they don't need any coding experience at all. 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] Airport Database Model
Arnt Karlsen wrote: ..wee tweak: for i in $( seq 100 ) ; do touch $i done Cute. You learn something new every day. I've never noticed that utility. I have a vague memory that there is some bash syntax that does a similar thing, too. And the $(...) syntax was new for me too -- I would have used backquotes. Honestly, I'm not much of a shell junkie. This is about as elaborate as any of my shell scripts get; anything bigger gets done in perl. 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] Airport Database Model
David Megginson wrote: Alex Perry writes: Why can't we stick it into the scenery directories, but one directory up from the tiles, so we have one file per 10degx10deg of planet. That should ensure that FGFS doesn't need to load all that many files, and just having the one file in the base package will allow initial use. It's not a bad idea, except that FlightGear needs to be able to search all the airports at once to find the one the user wants to jump to. It seems to me like the airport database is only searched on two keys: location and ID. Storing an index on location is trivial, as Alex points out -- store it with the location-specific data structure that is already indexed. So all we need is an index on name. Not to be too glib, but the OS already provides a rather nice index on named objects -- the filesystem. So in Scenery/w130n30/airports.xml you will find a simple list of airport ID's: airports idKSFO/id idKOAK/id ... /airports And look up the airport data itself under Airports/KSFO.xml: airport idKSFO/id nameSan Francisco Intl./name alt.../alt lat.../lat lon.../lon runway name11/name lat.../lat lon.../lon direction.../direction length.../length width.../width /runway runway ... /runway /airport The astute will point out that not all filesystems actually store indices on filenames (ext2 and FAT among them, sadly -- NTFS and reiserfs do have indices). With only a few thousand files, this isn't likely to be a real performance problem. Nonetheless, storing them sorted into directories is possible. Use Airports/K/KSFO.xml, for example, or even Airports/K/S/F/O.xml if you really want. :) This strikes me as easy to implement and much easier to maintain than the current metakit stuff. 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] Airport Database Model
Norman wrote: [ ... indexing scheme involving spacial partitions and trees ... ] With such a scheme we should be able to access any airport and determine which airports are within some sane distance in much less then a few tenths of a second order of manitude less at least True, but performance really isn't the goal here. The existing metakit stuff performs great. It's problem is that it's essentially unmaintainable without regenerating a megabyte of data*. Replacing one complicated binary data structure with another really doesn't address that need. My point was that a really simple one-file-per-airport scheme (you basically can't get any more maintainable than that) would work with adequate performance for typical usage. The airports in the current tile set could be kept in memory easily; arbitrary airports could be looked up quickly (under the UI definition of quick) by their ID; and the set of all airports would still be trivially searchable in a linear walk (looking for a match by name, for example) for cases where that capability was needed. Andy * Well, and that it involves a 3rd party C++ library that insists on installing itself as a shared library. My guess is that metakit version skew is the single biggest FAQable problem with new developers. It's a very real, very significant barrier to people who want to run the cool new stuff in CVS. This is my peeve, anyway. -- 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] multiplayer / AI property tree - questions
David Megginson wrote: I cannot say. One thing we're not modelling yet is nosewheel shimmy: Does this really have to be modeled, per se? Until we get support for force-feedback rudder pedals and seat cushions, the only thing we can reasonably do is play a sound. That can be done already with some fancy thresholding (gating with /gear[0]/wow and groundspeed) using the existing sound mechanism. I have limited experience here, but the nosewheel shimmy I noticed in a friend's PA-180 was only a rumble. It didn't seem to effect the orientation or handling of the aircraft. 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] VASI
Jim Wilson wrote: How do they work in real life? It seems that animation shouldn't be necessary. I got to see a 2-light PAPI up close at Fishers Island*, NY once. It's an astonishingly simple device. Basically, it's a box with a bright white interior. At one end is a lens. At the other (on the focal plane of the lens) is a white card painted red on the top and white on the bottom. Along the sides of the box are flourescent light tubes. ++ Red#/\ # | | Lens ~ | | Wht~\/ +-- + ==light=== So when you look through the lens, you see a singularity image (i.e. infinite magnification) of whatever you're looking at on the back card. If you're below the centerline, you see the red side. If you're above, you see the white. The box is mounted on a pair of sturdy concrete poles, and is tilted up at the glideslope angle. Basically, Curt's approach seems exactly right. The image of the thing depends entirely on direction to the viewer. There are no moving parts at all. Andy * A really cute airport for anyone in the northeast. Fishers Island is a tiny spot off the tip of Long Island, just south of New London, CT. The demographic is similar to Martha's Vinyard or Nantucket -- a small contingent of locals and a larger group of very wealthy vacation home owners. My sister-in-law's parents were in the former group. I got there on a ferry, not an airplane. :) -- 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] STL and vectors
David Megginson wrote: Frederic Bouvier wrote: I think your are making the too rapid assumption that an iterator is a pointer to an element. Don't iterators override the '+' operator if they're not just pointers? Indeed. That's the whole genius (madness, whatever) behind the idea. Many useful algorithms work on pointers into arrays, so if you abstract that notion syntactically, then the algorithm writer can just write his quick sort as if it took pointers and the compiler will inline everything correctly at compile time. It's really very elegant. Of course, the cost of that elegance is a library that almost no one understands. Witness the length of the how do I delete an element from a vector discussion. I respect the STL, really. But in this case respect involves a healthy dose of fear. :) 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] STL and vectors
Bernie Bright wrote: Only random access iterators support the '+' operator. Fortunately std::vector and std::deque provide just such iterators. I thought there was a variant that supported incrementation but not decrementation. You don't need the full-on random access variant in this case. That's defined as supporting the '[]' operator; '+' is useful without random access (walking a linked list, for example). More fuel to the STL flames, I guess. :) 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] Internationalization
Frederic Bouvier wrote: I made a french translation but unfortunately, accented characters ( e acute or a grave for instance ) are not present in the current font. I think the problem will show up for several languages. Should we have to provide a specific accented font for languages like nordic or french ? The current font is ASCII-only. Doing an ISO 8859-1 (or -15) version would be pretty simple, although visual quality might suffer if we have to stay at 256x256. The font file format works fine at bigger sizes, but Voodoo cards don't support textures larger than this. There is a fundamental 8 bit limitation in the file format (and I think in plib too), however. Doing unicode stuff will need surgery in plib to support a fancier font description. What is needed is a list of Postscript glyph names for the high 128 characters of the font (because ps fonts don't have a fixed encoding -- the only unique way to specify a desired character is as a symbolic glyph name). I'm sure this could be looked up somewhere... 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] Internal compiler error
Richard Bytheway wrote:a As mentioned in the Sig11 FAQ (link above), ensure that all the hardware in the PC is the correct spec, and that nothing is overclocked. Try underclocking as a possible workaround. If your RAM is on more than one stick, try removing different parts of it. Oddly, that FAQ fails to mention the single best tool for detecting these problems: http://www.memtest86.com/ Get this and run it. It's a boot image, so if you don't have a Linux installation (LILO and GRUB can run it just like a kernel) or a floppy, you may have to do some gymnastics. Leave it running overnight and see what you find. You'd be amazed at the number of working machines in the world have slightly bad RAM. One of my boxes, which seems perfectly stable, gets about 1 error every 10 hours. If you see any more than that, consider replacing your memory or motherboard. 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] Help: Current Ground Elevation
Norman Vine wrote: FWIW - I really don't understand why the FDM folks haven't been using this as I wrote it several years ago so that one could get an elevation per wheel Landing gear struts compress, so there isn't a single point of intersection. Worse, they don't always point down. Even worse, the ground isn't always flat, so a plumb bob won't always tell you the right point even for a vertical landing gear strut. Elevation is the wrong metaphor for this problem. As is being discussed on the plib list, what is really needed is a generic vector intersection test. That would clobber both the mouse click picking problem and the gear strut test in a single blow. 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] [PATCH] tdfx fog
Melchior FRANZ wrote: 1 would fix my problem. BUT: 40 only breaks the fog in the scenery, while it works well for the instruments. So I suggest to let POFF_UNITS be 40 but to reset the PolygonOffset to -1 or zero after having drawn the instruments. This should also work for all other cards. (Please verify and apply!) Is this not done already? I'm pretty sure that I reset the offset at the end of panel rendering. If I didn't, then this is quite obviously a bug. 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] Night lighting revisited
Norman Vine wrote: For example the a4 behaves differently then the c172 in this respect. Discover what is different and the lighting problem should be 'illuminated'. Curtis L. Olson wrote: People who understand the opengl lighting model better than I do might notice that I haven't mentioned the specular lighting compenent, which opengl supports as a way to emulate 'reflective' surfaces. If we are seeing some strange lighting effects perhaps the models have some kind of specular component that isn't getting turned off properly at night? Good catch, both of you. All of the materials in the a4-blue.ac file have a 50% specular coefficient, the c172 file has 0. While some specular probably isn't wrong for the A-4 (the Blue Angel's used glossy paint, of course), 50% is certainly way to high. It's also used for stuff like the cockpit panel, which is clearly not specular. I think perhaps the original author misunderstood what specular means -- even the lights (which are, by definition, 100% emissive) are listed at 100% specular. I changed all the specular components to zero, and things look much saner in my copy. 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] Re: lighting
Curtis L. Olson wrote: When you say moved panel rendering into the main scene graph, do you mean [...] or do you mean the panel rendering code get's executed as a call back from some ssg node [...] ? I mean that one. :) There's a tiny FGPanelNode ssgLeaf class that wraps an FGPanel object. It sets up the matrix stack appropriately and then calls the panel renderer as normal. Does anyone know off the top of their heads if the panel code changes the OpenGL lighting or material state? If it does, then this will be a really simple fix. 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
[Flightgear-devel] Dynamic scenery notes
I got a chance to try the dynamic scenery last night (in lieu of implementing the gear bounce/damp tuning for Dave Perry -- sorry). Wow. Simply stunning. :) Abject praise out of the way, here are the nits: The cowbox is too small. At only 1m high, it's really a more appropiate size for a sheepcase. Cows (at least the big north american ones that match the texture) are 1.5-2m tall at the shoulder, and often 3m long. I doubled the size to 2x4, and found the results more satifactory. The slightly-too-large size is hidden by the sparseness of the scenery. At the other extreme the 8 story building, while scaled correctly, is too large. Buildings this large are very rare, and occur in large numbers only in downtown areas that are better handled by real static scenery. I'd suggest replacing the urban scenery object with something like a 2-3 story building, or perhaps a cluster of small buildings. Right now, you can look accross the bay from San Francisco and see a huge urban skyline stretching from Oakland to Fremont which isn't even close to what's there in real life. My reading of the code is that there is a separate ssgTransform node in front of every one of the objects. That's likely to be a performance bottleneck, if the OpenGL matrix state has to change every four vertices (most GPUs want to flush the stream when the matrix changes). Instead, why not pre-compile the scenery objects for each tile into a single vertex buffer at load time. This is really easy -- step through each object and add the appropriate offset to each model vertex as you copy it into the vertex array(s). Then you could draw them all at once with no state changes whatsoever (and even get fancy in the future with stuff like compiled vertex arrays, NV_vertex_array_range and whatnot if you like). Even better, you could get a very cheap continuous LOD by drawing a distance-dependent prefix of this vertex buffer. That is, draw only the first N objects based on your distance from the tile centroid. Writing a new ssgLeaf node type really isn't so hard -- take a look at the fgPanelNode implementation for a minimalist example. 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] Randomly-placed objects, take 2
David Megginson wrote: Norman Vine wrote: Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX drivers from NVIDIA at default startup location no HUD no Panel Latest changes~17fps your original code~32 fps no dynamic objects ~75fps Here's what I get sitting still at the default location, no panel or hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux drivers (I'm using the latest plib CVS, but I assume you are as well): no dynamic objects: ~40fps dynamic objects (latest code): ~34fps dynamic objects (old code): ~32fps I actually see numbers that are more in line with Norman's (Athlon 1800XP, Geforce 3 Ti200, 1280x1024 32bpp, current code as of last night): the ~70 fps I see without dynamic scenery at startup at SFO drops to 40 or so when I turn the dynamic object on. This effect isn't severe, but it's enough to be worrisom. Certainly the dynamic scenery is taking up a significant chunk of the current render time, which makes it a good candidate for optimization. This is something that I think we need to look at more generally: right now, FlightGear is making rather poor use of the graphics hardware on fast cards. There was a thread on plib recently that showed that the current tile renderer is rendering lots of tiny ssgLeafs instead of a single large buffer. This tickles a bad code path through ssg, which wants to render each ~10 vertex leaf from a separate vertex array (drivers don't optimize this case well -- the fix being discussed was to use plain old glVertex (!) calls, which turn out to be faster for such small objects). Almost everything we render (other than the cockpit and model animations) is static geometry. In principle, we should be able to ship this off to the card in a big chunk. In practice, though, we end up no better than 1990-era code, which sent each vertex across the bus in a separate transaction. As we start adding geometric complexity to the scene, we really should look hard about how it's done. I see some support in plib for using display lists, although it looks like it's #ifdef'd out. 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] FW: [Plib-devel] ssg vertex tables tuning
David Megginson wrote: Norman Vine writes: I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib I saw a pretty-nice boost as well, for what it's worth. GeForce2Go 32MB, Linux drivers, 1600x1200x32 LCD. I don't remember what it was, because I've been using the patched plib now for over a week, but it was at least 15-20%. I tried it too, and likewise saw a similar increase in framerate. Nonetheless, I think this is the Wrong Solution. What this patch does is test at render time whether or not the vertex array is small or not. If it is small, it renders the leaf with glVertex3f() calls instead of using the vertex arrays. Gack. Now, for plib as a library, this is a fine optimization that's probably worth including. I have no objections there. But for FlightGear as an application, the *real* performance bug is that we're generating really tiny ssgLeaf objects. Each tile is a single piece of static geometry. There's no reason that it couldn't live in just one vertex array (or maybe one per texture). Or be stored in a single display list, etc... But clearly the optimal performance solution we're looking for is not iterated glVertex() calls. :) 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] FW: [Plib-devel] ssg vertex tables tuning
Curtis L. Olson wrote: I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. The majority (I'm guessing 70%) of tiles are either rendered in their entirety or culled in their entirety. The tile would seem, to me, to be just about the right granularity for doing culling. Certainly culling on tiny 10 vertex objects is too fine-grained, no? You can DMA a *lot* of vertices across the AGP bus in the time that it takes to do that cull. If my 70% guess is correct, then doing culling at a tile level will send 15% (the remaining 30% of tiles are on average half-invisible) too many vertices to the card for each frame. Rendering out of large vertex arrays instead of doing glVertex() calls has to be worth at *least* 15%. 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] ANN: a new dimension to FlightGear
Gouthas, Themie wrote: I dont think the alpha sorting code was ever comitted, so currently I dont beleive PLIB will alpha sort. I'm not sure this is a great idea in any case. There are a *lot* of these objects, and doing an NlogN sort of them (with attendant geometry processing to get the distances, not to mention the cache effects of doing an extra sweep over all of them) every frame is likely to be awfully slow. Hacking around the issue by diddling the rendering order (and maybe double-rendering problem objects like nearby clouds) sounds like the best idea to me. We could also investigate the use of destination alpha, which is available and fast on high end hardware these days. 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] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
Victoria Welch wrote: No jstest or jscal here and I have yet to track them down for something other than SuSE or Debian (or a tarball that has be be compiled into the kernel...) These are userspace test programs, not the kernel driver. They really should have been installed with your distribution. On my Red Hat 7.[23] boxes, they are in the joystick package. Definitely get these and try them first -- this is the best way to tell whether the problem lies in the hardware, driver, or plib/FlightGear. 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] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
Jim Wilson wrote: Was in sound card hell myself a few nights ago, so I can relate. Finally decided my time was worth something and went out to buy an sblive You weren't by any chance trying to make the built-in sound on a KT333 motherboard work, were you? I got bit by exactly this problem. The answer turns out to be that the VIA 8233A south bridge dropped a feature from the 8233 used by the kernel driver (but, because it looks like a newer/compatible version, Red Hat detects and installs the original driver anyway). The newest ALSA pre-release drivers have support. I just installed them in OSS-compatibility mode, and things worked great. The sound quality is surprisingly high for an on-motherboard card. Also, if you do have one of these motherboards, definitely install a 2.4.19-rc1 kernel. The stock 2.4.18 code doesn't recognize the IDE DMA hardware (not VIA's fault this time -- the Linux IDE driver is just conservative about what hardware it *knows* is bug-free) and falls back to PIO mode for disk access. My machine would lock up for significant fractions of a second while doing big disk transfers. 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] New textures
Erik Hofman wrote: Today I've sent some new textures to David (which he hopefully will commit somewhere in the next weeks). But the result is such that I want to let you know about it: Wow! This is magnificent. I've always hated the city texture (too yellow, too nondescript, maybe the scale was wrong?), but was too shy to criticise it for lack of ability to make a better one. :) I looked really hard, and couldn't find the texture seams. How did you manage to get this to tile so well? Where is the photo from, btw? Amazing, truly. 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.xml questions and suggestions
Dave Perry wrote: I have continued to work with the dc3.xml for yasim and some of the numbers in the original file seem inconsistent with the 3D model. Here are my questions: The model and YASim description don't agree exactly. The biggest difference is (I think) the location of the origin. YASim puts it at the tip of the nose, whereas the model uses a nominal c.g. instead. This can be fixed by adding offsets to all the YASim coordinates. I did this for a copy of the A-4 (that, er, I haven't checked in), and it made the model animations much better. What I did for the A-4 was pull it up in ac3d, find the coordinates of the nose (note that the axis conventions are different), and subtract those values from all the coordinates in the YASim file with a perl script. 1. Shouldn't the z value for the wing be -0.95 as the z for the wing is for the root mid cord. This is a low wing. This matches the tank and the engines better also. This looks like a typo. Uh, yup. That looks pretty wrong. I'll fix this tonight; I think I still have the sheet of paper with all of my original 3-view measurements. :) 2. The z value for the tail wheel, z=-1.5, seems to leave the tail off the ground at rest in the 3D model with compression=0.2. I have tried increasing the compression to 0.3 to 0.5 or increasing z to -1.0. I don't think the tail wheel compressed very much at all -- just the compression of the tires. My original 20cm value was almost certainly too high already (I made it so for numerics reasons -- very short compressions lead to correspondingly high spring constants, which increase the likelihood of the tail bouncing unphysically due to aliasing interactions with the 120 Hz integration interval. I figured that no one would notice an extra 20cm of squish in the tail on hard landings.). The best thing to tune is almost certainly the tail position. But only do this once the coordinate origins match. Then the over-the-nose visibility is terrible. In a real dc3 it was not so great until the tail came up in the takeoff roll. Visibility issues really need to be addressed using a 3D panel, which the DC-3 doesn't have yet. Right now, the panel lives at the same place on the screen regardless of what the resting orientation of the aircraft is. The Right Thing is to figure out a position for the panel inside the aircraft's coordinate frame, and fix the panel there. This then begs for a 3D-modeled cockpit environment, though, to avoid the panel floating in space effect. :) 3. Is there a way to add damping or make the stiffness of the compression for the main gear? It is very easy to get an oscillation the feels like a pre-bounce while accellerating on the mains or while rolling out from a wheel landing. Um, no, although there's no good reason for this. The spring constant is currently computed automatically as sufficient to support a landing at 3x the vertical velocity of a normal 3 degree approach. The damping is sufficient to critically damp a normal landing. This works surprisingly well for most aircraft, so I never added the ability to tune these parameters. You're the first one to really worry about ground handling in such detail. How would spring and damp attributes on the gear tag sound? These would be unitless numbers, so spring=2 would indicate a spring constant twice as high as the normally computed one, etc... 4. Does yasim report an actual Center of Gravity? I know that it checks to see if the approach config can be achieve with trim. This would tell me if I was going overboard with the ballast. There's a C.G. line at the bottom of the solution report. I believe it's for the approach configuration. Thanks for all your work. I'll try to get you an origin-consistent model ready tonight, with support for the gear spring tuning. 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] MP what data to send
Frederic Bouvier wrote: And what happens with deltas and positions when you will lose UDP packets ? How will you restore the correct position or orientation ? Perhaps, from time to time, it will be good to send absolute positions to resynch. Yes, this is a requirement. Sending unreliable deltas requires that there be a reliable transport for the value that the deltas are computed from. That was the idea behind the zone suggestion I made. The zone coordinate change packet would be sent rarely, and would require and ACK from the client and retransmition on failure. Blindly relying on the packets to arrive correctly and in-order is not an option*. Andy * Except on a local network. On a single physical network, the ethernet standards handle retransmission on collision for you, so packet loss at the IP level can be ignored. I'm not sure if this is true for ethernet derivatives like WiFi, though. -- 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] MP what data to send
Christian Mayer wrote: I don't know if zipped packages help much for the kind of data you are sending. You can only compress redundant information Amen. He speaks the truth. But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. + Orientation can be very crude -- the eye has trouble telling degree differences less than 5 degrees or so. That means that the whole orientation can fit in something like 11 bits with creative packing (consider quantizing a 4D sphere of 2048 quaternion points and picking an 11 bit encoding for them). With a little extra work, you can transmit a zone as above, to get constant orientations (approach AoA's, for example, that the eye could tell are wrong if it looked carefully) exactly right. + Likewise, velocity needn't be terribly accurate so long as it is retransmitted regularly. No more than +/- 5 knots or so is fine for updating the position display. If you need more accuracy for ATC purposes or whatnot, that can be done with a different packet much less often. + Rotation rate, linear acceleration and rotational acceleration can be skipped entirely. These values are useful only to an FDM, or perhaps to a cockpit interface. Simply display them using a time-interpolation of the values you already have. The eye won't be able to see the errors unless the update rate is very slow. + If you really want to be macho, you could investigate fixed huffman encodings for the different values. Position changes are more likely to be horizontal than vertical. Typical velocities are very likely to be near the nominal cruise speed of the aircraft. Upright orientations are more common than inverted ones, etc... This could probably get you another few bits per value, on average. But usually this isn't worth it. It optimizes the common case, but often makes the interesting cases (say, a dogfight) perform worse. Most users are going to want better performance in the interesting situations. Most of this probably isn't worth it. But it's kinda fun stuff to think about if you really need to pack those bits 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] [OT] concave mirrors
Curtis L. Olson wrote: My initial speculation is that the position of my eye is an important factor that isn't addressed by the simple theory, but from the simple theory, I don't see how that could be possible. One nit is that the simple theory only works for small mirrors (large curvature radius to diameter ratio) and for reflections that are close to the axis of the mirror. Large mirrors really need to be paraboloids and not spheres, and off-axis images will experience distortion (the focal plane is only flat in its middle). But these aren't issues here, and wouldn't explain what you saw. If I move my eye point away from the mirror and watch myself, I seem to hit the singularity at 40 which is the center of curvature, not the focal point. Yes, I've verified that the radius is indeed 40 and is most definitely not 80. This sounds right. At 40, your eye is in the center of the mirror. It is seeing its own reflection in every direction, which looks like a singularity. You should also see a singularity at 20, but that's a little different: At the focal point, your eye's reflection should be discernable, but everything else in the world will appear to be coming from all directions. If you didn't see one at 20 at all, then I'm confused too. :) Remember that your eye and the background are separate objects at separate distances. Objects at different distances have different focal planes (especially when those distances are already on the order of the focal length). Only objects that are infinitely far away will converge exactly at the focal point of the mirror. The mirror is not a pinhole camera. 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] x++ The World's First XML-Based ProgrammingLanguage
Jonathan Polley wrote: Jon Berndt wrote: Just because something *can* be done doesn't mean it *should* be! Actually, I was going to say that it was another solution in search of a problem. I honestly thought it was a joke, but the website looks serious enough to believe. Good grief. But it's not the first -- XSLT is a full XML-based programming language, thankfully tailored to a much smaller problem area. And XSLT is still a horrific monster, IMHO. I still remain dumbfounded at the number of otherwise bright people in this world that believe that needlessly gluing together two useful technologies results in improvement. What happened to encapsulation? It's not just for programs anymore. :) 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] How to draw lines?
Martin Dressler wrote: I wan to draw lines in instruments layer. I made a new subclass of FGInstrumentLayer and in draw method I do glDisable ( GL_TEXTURE_2D ); glBegin(GL_LINES); glVertex2f(-100,0); glVertex2f(100,0); glEnd(); but it doesn't draw anything. But when I draw something with GL_POLYGON it draw fine. What I should to change, please? Is this on the 3D panel or 2D? In 3D, the texture layers are drawn with GL_POLYGON_OFFSET, which by default does not apply to lines. For reasons having to do with a metaphor collision (lines are thick in screenspace, while polygons aren't) lines don't work well with glPolygonOffset() -- you have to play with the factor argument. Try using glVertex3f() and specifying a Z coordinate of about 0.01 or so; that might work. But are you actually sure you want to be drawing lines? Lines are not the natural medium for 3D hardware -- they don't antialias well (if at all), don't have an easy way to associate their size with the world around them, and don't behave nicely under changes of perspective. Almost always, you'll get better results by using a 1D texture to draw your lines. Picture a 4x1 GL_LUMINANCE_ALPHA texture that looks like this: 0 0 0 255 255 0 0 0 Set your line color with glColor, and draw the line in world-space coordinates as a thicker (4x as wide as the intended line) quad modulated by the texture. Now, the line will be nicely antialiased, will look correct when viewed at funny angles, and will be less likely to excercise slow paths and funny behavior in the OpenGL driver. You'll send about twice as many vertices to the driver, but that's not likely to be significant when compared with the terrain complexity. 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] GS needle sensitivity.
Curtis L. Olson wrote: I had someone recently comment that they thought the glide slope needle was too sensitive in FG. Can anyone comment on this? I think the glideslope needle is too sensitive in FG. :) I don't have any harder evidence either, but I'll throw in my 2¢ anyway. I've been practicing constant AoA landings in the A-4 over the last week or so (getting really good at them now, gonna have to code up arrestor wires pretty soon...), and using the ILS receiver to train my eyes to recognize the right glideslope. It's definitely very touchy, even 2-3 miles out. My sense is that maximum deflection of our instrument is only a small fraction of a degree, when it should* be something more like 1° or so. Andy * Where should means what other simulators seem to do and not what real equipment does. -- 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
[Flightgear-devel] A-4 manual
I've been doing really well recently with my A-4 landings, so I wrote up a putative Flight Operations Manual to record the stuff I've learned: http://www.plausible.org/a4-ops/ Obviously, I've never actually trained with the Navy, so lots of this is guesswork based on data points I've picked up from research and/or experience with the flight model. So it's not necessarily something you'd want to hand to a real pilot, but it should help to get FlightGear geeks up to speed on this stuff. If folks like it, it would be nice to put it up on the flightgear.org site. A set of operational manuals for all of our core models would be a really good thing to have. I need to write up something similar for the Harrier, which is even harder to land. :) 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-yasim model
Dave Perry wrote: Attched find an xml file dc3.xml that includes edits that allow accelleration on the main gear and relativly easy wheel landings. With these changes, I can leave the tail wheel unlocked for take-off and landings. Very cool. I'll try it as soon as I get home. 3. I moved the main gear back to 6.9 (from 6.02). This had a very big effect and enables getting the tail up and accelerating on the mains. Without this, no matter what I did, by the time the tail came up, I had already set up the porpoise. Same on wheel landings. This is the only one I worry about. While the other tunables inherently involve some guesswork, the position of the wheels is, er, Physical Truth. :) While it's entirely possible that I mismeasured the location on the 3-view I was looking at, this is the sort of thing that in principle can be made exactly correct. It shouldn't require tuning. There's also the issue of synchronicity with the 3D model -- we want the position of the wheels in the FDM to match what the user sees on the screen. Instead, what you might try is to move the c.g. forward by the same 88 cm by adding ballast tags. What these do is to place the specified amount of the aircraft's empty weight at the location, instead of allocating it to the wing and fuselage elements. The DC-3 doesn't have any, but most of the tricycle models do -- they tend to tip over backwards using the default weighting; tail draggers have a much larger tripod to sit on. 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] Jitterbug pinpointed
Norman Vine wrote: Following is IMHO a good explanation as to why having the camera a node in the scene-graph is not 'necessarily' a 'good idea' Which is a good point in theory. Their basic idea is that the scene graph specifies data, and you interpret that data via a camera. These are two well-defined and separate areas, and should be kept separate in code. The problem is that this leads naturally to precision problems exactly like our jitter -- you can't just push transforms onto the matrix stack willy nilly (in this case, moving ~1.0e+07 cockpit-pixels away and coming back) and expect things to work nicely. These are finite computers, and they have finite precision. Sure, it's cleaner in principle to have all the scene data separated from the camera data, but until we have arbitrary-precision GPUs these two halves need to coordinate so they don't step on each others toes. 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] FlightGear precautionary landing
Curtis L. Olson wrote: But to your other point, I agree that we should start looking into failure modes. This is one big un-addressed issue. I could make up a list of interesting failure modes if anyone was interested. This could actually be done with minimal C++ code. Picture a failure manager that walks a property tree under /failures. For each child, it reads a mtbf-sec property and sets the working boolean with a random probability that corresponds to the failure rate. This is maybe a few tens of lines of C++. So each failure system then sets something like /failures/static-pressure/mtbf to 10 in an initialization file. And the relevant system (the ASI and altimeter, in this case) just checks the value of /failures/static-pressure/working. Most of this can be done using the existing property conditions as-is. A few failure modes (engine failures, maybe) might require FDM intervention, but most are just of the turn off the gadget form. 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] Jitterbug pinpointed
Curtis L. Olson wrote: I haven't been following this thread as closely as I should have been, but there should be no reason why we'd need to have the camera in the scene graph. I think we just need to be smarter about how we structure the transforms. That was my original suggestion: put the camera origin at the viewpoint, and insert one ssgTransform node on top of the terrain that moves it to the tile centroid, and another above the model that moves it to the model origin. The camera business came up because I suggested that this sort of mistake is very easy to make with the camera living outside of the scene graph. The proof: Jim (no slouch as a 3D programmer) didn't realize that the bug still applied in cockpit mode, even though the model was in its own scene graph. The fact that the camera lives separately from the graph is, IMHO, a mistake. But it's tangential to the bug. There's nothing magical about having multiple scene graphs vs. one scene graph, in the end you still get basically the same set of opengl primitives. True, but the more special rules there are (e.g. cameras aren't the same thing as ssgTransform nodes), the less obvious the set of OpenGL primitives that will be generated is. No one would ever think to do the following in OpenGL: Move +1000m Draw the Terrain (~100m from the viewpoint) Move -1000m Draw the Cockpit (~0.1m from the viewpoint) But that's exactly what happened to us. It happened because the two move lines are not implemented the same way -- the first happens in ssgSetCamera, the second is an ssgTransform node at the top of the model scene graph. The right solution (ignoring orientation, which is fine as-is) is this: Move 0m in the camera Move +1000m Draw the terrain Move ~1m to the aircraft origin Draw the cockpit 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] Jitterbug pinpointed
Norman Vine wrote: I guess I wrongly assumed that everyone would read this as just add the appropriate offset to move the camera to the origin :-) Unless I'm still not understanding you, I think you misunderstand the issue. Just adding an offset to the camera is what's already being done, and it runs into precision problems. The trick is to make sure that the camera is *never* moved to the scenery centroid before rendering the model. Once that 1000m transformation is on the stack, it's too late -- you can't recover precision you've already lost. 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] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote: Thanks for the info. I'd be reluctant to put together an Input/Joysticks/Saitek/X45.xml file that I couldn't actually test. If you have a chance to hobble one together some time, I'll be very grateful. I was afraid you'd say that. :) Here is an X45.xml file that I've verified to work on my stick. I've removed all the hacks, leaving (hopefully) something that is generically useful. 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) ?xml version=1.0? !-- Only a few auxiliary stick controls have been mapped here: + Rocker switch: Rudder + Top rotary dial: Mixture + Bottom rotary dial: Prop Advance + Top stick hat: Elevator Aileron trim + Bottom stick hat:View direction + Top throttle hat:Flaps Rudder trim + Stick button A:Gear toggle Axis Numbers: 0 Roll (positive == right) 1 Pitch (positive == down/back/nose-up) 2 top rotary dial on the throttle (positive == CCW) 3 Rocker switch (rudder control) on the throttle (positive == right) 4 Throttle (positive == back/down/idle) 5 Bottom rotary dial on the throttle (positive == CW) 6 Lower right hat horizontal axis (positive == right) 7 Lower right hat vertical axis (positive == down) Button Numbers: 0 Trigger 1 Stick top A switch 2 Stick top B switch 3 Stick top launch/fire switch 4 Throttle D switch 5 Throttle mouse switch (tiny black thumb button) 6 Stick pinkie switch 7 Stick front C switch 8 -+left position (M1) 9 +- Throttle mode 3-way switch: middle position (M2) 10 -+right position (M3) 11 -+left position 12 +- Throttle Aux 3-way switch: middle position 13 -+right position 14 Upper left hat in up position 15 Upper left hat in right position 16 Upper left hat in down position 17 Upper left hat in left position 18 Throttle forefinger hat in up/back position 19 Throttle forefinger hat in right position 20 Throttle forefinger hat in down/forward position 21 Throttle forefinger hat in left position 22 Throttle thumb hat in up position 23 Throttle thumb hat in right position 24 Throttle thumb hat in down position 25 Throttle thumb hat in left position -- PropertyList nameSaitek Saitek X45/name axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/aileron/property squared type=booltrue/squared /binding /axis axis n=1 descElevator/desc binding commandproperty-scale/command property/controls/elevator/property factor type=double-1.0/factor squared type=booltrue/squared /binding /axis axis n=3 descRudder/desc binding commandproperty-scale/command property/controls/rudder/property /binding /axis axis n=4 descThrottle/desc binding commandproperty-scale/command property/controls/throttle[0]/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/throttle[1]/property offset type=double-1.0/offset factor type=double-0.5/factor /binding /axis axis n=2 descMixture/desc binding commandproperty-scale/command property/controls/mixture[0]/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/mixture[1]/property offset type=double-1.0/offset factor type=double-0.5/factor /binding /axis axis n=5 descPropeller Advance/desc binding commandproperty-scale/command property/controls/propeller-pitch[0]/property /binding binding commandproperty-scale/command property/controls/propeller-pitch[1]/property /binding /axis !-- View Direction Hat -- axis n=6 descView Direction/desc low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double1.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double-1.0/step /binding /high /axis axis n=7 descView Elevation/desc low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property step type=double1.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property step type=double-1.0/step /binding /high /axis !-- The trigger operates the brakes -- button n=0 descBrakes/desc binding commandproperty-assign/command
Re: [Flightgear-devel] dc3 effectiveness=nnn for both hstab andvstab
Arnt Karlsen wrote: ..one idea; try make the effectiveness'es a function of the propwash, or thrust initially, and from each engine. May help to get a feel for it, I'm not that sure this is the _right_ way to model it. Negative thrust (say on decent/approach, does not need negative prop pitch, only negative prop blade aoa) also has an impact on the tail surfaces. My current thinking, actually, isn't to treat propellers specially at all. Every surface (propeller, jet, wing, whatever) generates an aerodynamic force, and every surface has a characteristic size. You can use, with a little heuristic handwaving, to determine a downstream wash field for each surface. Basically, how much air at ambient density must be flowing through a tube the size of the surface to create that force? Then you get all sorts of nifty effects for free: + Propwash and jetwash, of course. + Asymmetric stalls when slipping, because the fuselage masks one wing. + Loss of tail authority in T-tail aircraft during stall. The hard part here is deciding what the wash field should look like. It should spread out gradually along some vector between the global velocity and the perturbed velocity, but which? Dunno. There is also a potential performance issue, since the extra calculations will go as O(N^2) in the number of surfaces; I think this isn't likely to be significant in practice, though. 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] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote: Please send me your bindings for your own device. Under Linux, you can find the device name with a command like. This is a great feature. Very cool. Here are button and axis assignments for my Saitek X-45 under Linux. My actually joystick.xml file is in a terribly hacked state, and probably not useful to anyone. :) Note weirdnesses: The first hat acts like a normal hat under linux -- it maps to two axis values. The other three hats look like buttons to the HID driver. Contrary to documentation, all four hats are fully 8-way capable (this is a good thing, obviously). The axes are in a bizarre order -- nothing at all like a normal joystick. The coordinate convention for the two rotary dials are different (this actually isn't so strange, they are both positive==forward as your fingers interpret them). Name: Saitek Saitek X45 Axes: 0 Roll (positive == right) 1 Pitch (positive == down/back/nose-up) 2 top rotary dial on the throttle (positive == CCW) 3 Rocker switch (rudder control) on the throttle (positive == right) 4 Throttle (positive == back/down/idle) 5 Bottom rotary dial on the throttle (positive == CW) 6 Lower right hat horizontal axis (positive == right) 7 Lower right hat vertical axis (positive == down) Buttons: 0 Trigger 1 Stick top A switch 2 Stick top B switch 3 Stick top launch/fire switch 4 Throttle D switch 5 Throttle mouse switch (tiny black thumb button) 6 Stick pinkie switch 7 Stick front C switch 8 -+left position (M1) 9 +- Throttle mode 3-way switch: middle position (M2) 10 -+right position (M3) 11 -+left position 12 +- Throttle Aux 3-way switch: middle position 13 -+right position 14 Upper left hat in up position 15 Upper left hat in right position 16 Upper left hat in down position 17 Upper left hat in left position 18 Throttle forefinger hat in up/back position 19 Throttle forefinger hat in right position 20 Throttle forefinger hat in down/forward position 21 Throttle forefinger hat in left position 22 Throttle thumb hat in up position 23 Throttle thumb hat in right position 24 Throttle thumb hat in down position 25 Throttle thumb hat in left position -- 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] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controlscontrols.cxx,1.21,1.22 controls.hxx,1.21,1.22
Arnt Karlsen wrote: ..(during the Falklands War, the Britts tested refuelling of Harriers and Sea Harriers, from ships, in-hover refuelling, believe I saw this in Air Progress magazine in the mid 80'ies.) I think what you're remembering is the Sky Hook gadget that was developed but never installed on Royal Navy vessels. It was actually a full-service landing system, not just a refuelling boom. The idea was that the Harrier would come to a stable hover alongside the boat, and then be grabbed from above by the hook. It would then (carefully!) decrease thrust until it was just hanging there, and then be lowered onto the deck like cargo. I can't imagine this was very popular with the pilots. Imagine sweating during the (already very difficult) hover as some 19 year old sailor swats at you with a giant crane. :) 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] Re: crashes at tile borders revisited
Jim Wilson wrote: When I get some time I'll run further tests and maybe come up with a patch to avoid this sort of glitch. It would be helpful if someone happened to know why this gap happens in the scenery data sometimes. I'm sure Curt can talk in more detail, but my guess is that this is going to be very hard to avoid* in the general case. Maybe the best way to do this is to apply some meta-intelligence about the structure of the data. Rather than finding a purely geometic intersection with any polygons that may (or may not!) be there, test each tile individually (with a little guard band around the edge to prevent misses) and select exactly one intersection. [* It's really the same issue as the jitter -- at the scales covered by the terrain tiles, the floats in the vertex coordinates are only accurate to within a few millimeters. Even perfect math will result in cracks. The only way to avoid is would be to find all the duplicated vertices accross tile boundaries and force them to be precicely equal at load-time, which sounds like a pain to me. You can't force them to be precicely equal at generation time because each tile has its own coordinate origin and the equality test needs to happen after they're placed into the same coordinates.] Right now I'm in the middle of moving my own stuff to a new machine with a newer distro, so be a little patient please :-) Heh, join the club; I just bought a new machine too. BTW Anyone have any RH 7.2 suggestions (other than formatting and installing debian)? Any hope for the 2.96 compiler? OT so respond off list. I've been building with the default compiler on 7.2 and 7.3 with no difficulties at all. I think the 2.96 issues were all hammered out during patches to the 7.0 distribution. 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] FDR playback broken?
Major A wrote: has anyone recently used the FDR? I've just recorded a couple of flights with the a4-yasim, and whenever I try to play back the recording, fgfs dies with a segfault. dumb-question We have a FDR feature with playback??? /dumb-question 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] Re: crashes at tile borders revisited
Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. I tried this with a few aircraft, and they all seem to see the same bump. Sticking a printf in YASim's update method (or actually uncommenting one that someone else added, heh) I see the terrain elevation leap by about 2 meters as you cross the tile boundary. Now, 2m doesn't sound like a lot to worry about, but clearly the terrain rendering isn't showing anything near a 2 meter difference, so the problem isn't with the scenery data itself. If there's a bug in the collision detection, it's possible that it has higher magnitudes elsewhere. I have to go back to work now, but maybe this will help someone else track down the issue. 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 effectiveness=nnn for both hstab andvstab
This is great stuff; apologies for forgetting to respond yesterday. :) Dave Perry wrote: I was able to get good control (vtab effectiveness) and early tail up (htab effectiveness) with both values at 2.25. It was easier with both values at 2.5. I then shot a number of touch-n-goes using wheel landings. It still seems that it is very easy to over control in pitch while trying to stay on the mains. One effect that you may be missing is prop wash effects. During the takeoff roll in the real aircraft, the tail surfaces will be much more effective due to back blast from the propellers. YASim doesn't model this, so in order to get good controllability during takeoff you are probably having to increase the effectiveness more than is strictly correct. This makes the whole tail surface, including elevator and rudder authority, more effective and you get the pitch sensitivity that you mention. You could try to treat this by tuning down the flap effectiveness of the elevator (or increasing that of the rudder and turning down the overall effectiveness). Inter-surface wash effects are on a list of stuff that would be cool to implement (they get you asymmetric stall effects too, which would be nice to have modeled). I've been spending most of my time recently with the jet models, which don't really need them. Taildraggers do, though, so maybe I should give it some thought. For normal full stop landings, it is best to lock the tail wheel and do a full stall landing, brake, get rid of the flaps, and then unlock the tailwheel to turn off the active. I've found that to be true with the YASim model as well, although some articles at douglas-dc3.com indicate that normal practice was to never do a three point landing and instead plant the mains as early as possible. As you mention, the YASim model makes that difficult. If you get the model to a place where you're happy with it, would you be willing to post it so we can try it out and get it into the archive? I'm no expert on tail draggers, so I haven't done as much testing on this model as it needs. David is the only one who has spent significant time with it, I think. 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] Jitterbug pinpointed
Jim Wilson wrote: I can see what you are saying...but the aircraft (in the cockpit view) is actually a different scene graph. But it's under the same camera (oddly, ssg puts the global camera outside the graph, when it's logically the top-level node of the graph), and has the same double-transform problem; it just doesn't happen to use the terrain frame for anything. Really I've got to get more into ssg to understand how all this works better. For some reason I seem to have an easier time understanding the lower level opengl stuff now than plib (which probably sounds backwards). I have the same trouble. You can debug OpenGL transformations by looking at code and inspecting the matrices via printf where you know the problem is. With plib, you have to stare at a scene graph dump. These are really useful, by the way -- just call the print() method on the top level node. The only significant problems are that it's 10 megabytes of dump, mostly of tiles that aren't interesting; and that most of our nodes don't have names -- I added a bunch of setName() calls to the ssg nodes to tell where I was. My first concern would be about the overhead of transforming the terrain each frame (lots and lots of vertices). You don't transform the vertices in memory -- just push an extra matrix on the stack and OpenGL will combine them for you. The extra performance cost is almost exactly zero (one matrix multiplication per frame). If it can be done, I think my earlier suggestion of rendering the Cockpit with no position offsets might work. Can't we render everything else and then lastly set the camera to the pilot's nose Sure thing. That's basically the same idea, but it works only for the cockpit. If you fix the double-transform stuff in general, the outside view will stop jittering too. 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] Jitterbug pinpointed
Norman Vine wrote: To experiment I believe all you should have todo is change the value for 'center' in prep_ssg_nodes( vis, up, center ); in tilemngr.cxx to reflect the 'offset' you want. No, that won't work unless you can guarantee that the offset value will always be within ~100m of the viewpoint. The problem isn't that the offset exists, it's that it's being pushed onto the matrix stack twice -- once to draw the terrain, and once to undo it to draw the aircraft model. The model must be drawn with its own viewpoint-to-origin translation, and shouldn't care about the terrain's origin. The terrain translation is too big, and causes FPU/GPU precision problems at scales the aircraft model cares about. 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-yasim - observations from a tail-draggerpilot
Dave Perry wrote: 1. If the tail wheel is not locked, I find it much easier to take off after removing the coupling of the rudder with the brakes for both main gear from the dc3.xml. I'd be happy to junk this; David always hated it anyway. It was basically a hack to fix a problem I didn't understand properly anyway. :) 2. It seems to me that the dc3 always leaves the ground before I can raise the tail (even with full down elavator). This is not what a real tail dragger does. This is also really good to know -- if you want to try experimenting, try modifying the tail effectiveness. In the hstab tag, there can be an effectiveness=nnn attribute that multiplies the force generated by that surface. This is basically a guess right now, I find that for many of the jets, a value of 2 or so works well. In general, smaller surfaces generate more force per area, but there's no hard rule (too many other effects get in the way, like airfoil differences and wash effects). I think the DC-3 is still using the default effectiveness of 1, but that's only because it flew adequately when I tried it. I don't have any real world experience to compare against. Let me play with it tonight and see if I can get something that mimicks what you describe. 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
[Flightgear-devel] Jitterbug pinpointed
I spent some time over the weekend struggling with the jitterbug (sorry, couldn't resist). I haven't fixed it, but I have pinpointed the issue. In essence: yes, it's a precision problem; but no, Jim's calculations aren't the problem. The problem is actually the organization of the scene graph. Right now, it looks basically like this: Camera (move to terrain origin, orient to terrain/global frame) | +-- Terrain | +-- Transform (bring origin back to near viewpoint, orient to model frame) | +-- Aircraft Model That is, the top-level camera matrix includes a 1000m or so translation to the local tile centroid. This translation thus has to be undone by the aircraft model matrix in order to move the origin back to the region near the viewpoint. But this is exactly the problem -- in 32 bit float precision, two 1000m translations are only accurate to a few millimeters. Not good enough. Even if the number that generated the matrices were perfect, we'd still be seeing the jitter. And the simplest solution -- use doubles -- isn't even an option here because the math is happening inside OpenGL. Consumer graphics cards don't even *have* double precision GPUs. What I'd suggest, which still takes some surgery, is to reorganize the scene graph to remove the double-translation. Something like this, which pushes the tile centroid translation down into the terrain branch, should work well: Camera (orientation only, no position change) | +-- Transform (move to terrain origin) || |+-- Terrain | +-- Transform (move to model origin, orient to model frame) | +-- Aircraft Model I got started trying to figure out how to do this, but got a little lost. Jim, you know this code a lot better than I do, how hard would that be to do? 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] JavaScript!
David Megginson wrote: So, Andy, here's your challenge -- you wrote YASim to prove how small and simple an FDM could be; how about showing us how small and simple a JavaScript implementation can be? I'm sure FlightGear isn't the only project that would benefit. Yikes, don't tempt me. You heard Curt -- I'd get it written, it would be small and tight and everyone would love it, and then I'd spend the next 10 years turning it into the huge monster that every other scripting language becomes. In place of the Dark Lord, you would set up a King; beautiful and terrible. All would love it and despair. Or something, anyway. I pass the test. :) Or not -- I'll admit that I've thought about writing a scripting language in the past. But it's not a simple project. Or rather, it can be a simple project if you're willing to do Scheme. If you want to do a parser for a nicer syntax and have built-in support for concepts like modules and OOP, it takes more work. 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] Re: 3d Panel problem
Jim Wilson wrote: Andy Ross wrote: But I also goofed and checked in some of my private changes. The eyepoint is slightly higher, allowing the pilot to look straight down the nose as I believe is true for the real aircraft (it radically improves visibility at high AoA's). You probably haven't noticed but I've been inching it up just for that reason :-) However, studying quite a few photos, it's amazing that pilots can see anything other than straight ahead through that target window, even at low AoAs. I keep thinking there has to be an error there...but the photos all show the pilot's helmut is at about the right height and the panel in about the right place. Been using the helmut as a guid for placing the eye. Maybe we're interpreting the photos differently? From the ones I've seen, the location of the pilots eye traces a straight line over the panel cover and straight down the nose at about 16° or so. The top of the oval windscreen is almost directly in front of the eyepoint. This allows for an approach at 13.5° AoA with some room to spare looking over the nose. I'm pretty sure that's about right. It certainly feels correct. Of course, a real pilot would be able to physically move his head by a few inches. If he sits with his helmet against the rest, he will obviously have less visibility. I'm assuming his neck is in approach configuration, tilted slightly forward for best over-the-nose viewing. 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] Re: 3d Panel problem
Jim Wilson wrote: One thing I'm wondering is if we can do away with the background texture in the 3-D panel. Do we need it or can the backplane always be part of the model? Not sure if this would fix the problem with the 3-D model/instrument or not. There's no real need for the panel to have a background in a 3D environment. It makes more sense, IMHO, for the background texture to be part of the model geometry. I think that right now the background (multi-)texture is required, but that'll be easy to fix. 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
[Flightgear-devel] New font / updated patch
FlightGear folks: I just checked in a nice Helvetica.txf into the base
package. Before you can use this, you need two things. The first is
a trivial patch to gui.cxx that allows for setting the default font
via properties (while leaving the original default in place). In
src/GUI/gui.cxx, line 995, replace this:
fntpath.append( typewriter.txf );
With this:
fntpath.append(fgGetString(/sim/font, typewriter.txf));
The second thing you need is a patched plib. There is a patch
attached to the current plib CVS that fixes a bug that this font file
needs. If you don't apply it, you will see the new font rendered with
far too much space between characters.
Plib folks: this patch supersedes the one I sent yesterday. My first
one missed a spot. The calculation of string width needs to use the
new width metrics too, otherwise the strings themselves will print
acceptably, but be laid out with too much space.
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/fnt/fnt.cxx
===
RCS file: /cvsroot/plib/plib/src/fnt/fnt.cxx,v
retrieving revision 1.7
diff -u -r1.7 fnt.cxx
--- src/fnt/fnt.cxx 12 Dec 2001 23:49:36 - 1.7
+++ src/fnt/fnt.cxx 29 Jun 2002 06:05:33 -
@@ -102,14 +102,14 @@
curpos[2] ) ;
glEnd () ;
- float ww = ( gap + ( fixed_pitch ? width : v_right[cc] ) ) * pointsize ;
+ float ww = ( gap + ( fixed_pitch ? width : widths[cc] ) ) * pointsize ;
curpos[0] += ww ;
return ww ;
}
-void fntTexFont::setGlyph ( char c,
+void fntTexFont::setGlyph ( char c, float wid,
float tex_left, float tex_right,
float tex_bot , float tex_top ,
float vtx_left, float vtx_right,
@@ -119,6 +119,8 @@
exists[cc] = FNT_TRUE ;
+ widths[cc] = wid;
+
t_left[cc] = tex_left ; t_right[cc] = tex_right ;
t_bot [cc] = tex_bot ; t_top [cc] = tex_top ;
@@ -127,7 +129,7 @@
}
-int fntTexFont::getGlyph ( char c,
+int fntTexFont::getGlyph ( char c, float* wid,
float *tex_left, float *tex_right,
float *tex_bot , float *tex_top ,
float *vtx_left, float *vtx_right,
@@ -137,6 +139,8 @@
if ( ! exists[cc] ) return FNT_FALSE ;
+ if ( wid != NULL ) *wid = widths [cc] ;
+
if ( tex_left != NULL ) *tex_left = t_left [cc] ;
if ( tex_right != NULL ) *tex_right = t_right[cc] ;
if ( tex_bot != NULL ) *tex_bot = t_bot [cc] ;
@@ -209,7 +213,7 @@
if ( b v_pos + v_bot [cc] ) b = v_pos + v_bot [cc] ;
if ( t v_pos + v_top [cc] ) t = v_pos + v_top [cc] ;
-h_pos += gap + ( fixed_pitch ? width : v_right[cc] ) ;
+h_pos += gap + ( fixed_pitch ? width : widths[cc] ) ;
}
if ( left != NULL ) *left = l * pointsize ;
Index: src/fnt/fnt.h
===
RCS file: /cvsroot/plib/plib/src/fnt/fnt.h,v
retrieving revision 1.5
diff -u -r1.5 fnt.h
--- src/fnt/fnt.h 7 Nov 2001 23:51:09 - 1.5
+++ src/fnt/fnt.h 29 Jun 2002 06:05:33 -
@@ -90,6 +90,10 @@
v_bot==0.0 and v_top==1.0.
*/
+ /* Nominal baseline widths */
+
+ float widths [ FNTMAX_CHAR ] ;
+
/* Texture coordinates */
float t_top [ FNTMAX_CHAR ] ; /* Topedge of each character [0..1] */
@@ -171,19 +175,19 @@
float getGap () const { return gap ; }
- void setGlyph ( char c,
+ void setGlyph ( char c, float wid,
float tex_left, float tex_right,
float tex_bot , float tex_top ,
float vtx_left, float vtx_right,
float vtx_bot , float vtx_top ) ;
- int getGlyph ( char c,
+ int getGlyph ( char c, float* wid,
float *tex_left = NULL, float *tex_right = NULL,
float *tex_bot = NULL, float *tex_top = NULL,
float *vtx_left = NULL, float *vtx_right = NULL,
float *vtx_bot = NULL, float *vtx_top = NULL) ;
- int hasGlyph ( char c ) { return getGlyph ( c ) ; }
+ int hasGlyph ( char c ) { return exists[ c ] ; }
void getBBox ( const char *s, float pointsize, float italic,
float *left, float *right,
Index: src/fnt/fntTXF.cxx
===
RCS file: /cvsroot/plib/plib/src/fnt/fntTXF.cxx,v
retrieving revision 1.14
diff -u -r1.14 fntTXF.cxx
--- src/fnt/fntTXF.cxx 21 Apr 2002 03:53:15 - 1.14
+++ src/fnt/fntTXF.cxx 29 Jun 2002 06:05:34 -
@@ -246,6 +246,7 @@
glyph . y = _fnt_readShort () ;
setGlyph ( (char) glyph.ch,
+ (float) glyph.step / (float) max_height,
(float) glyph.x / (float) w + xstep,
(float)( glyph.x
Re: [Flightgear-devel] jitters testing
Jim Wilson wrote: Andy Ross said: If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. No it would not. The scenery is too far away. Further pixels require bigger values to shift. Distance makes a huge difference. That's true for position jitter, but not for orientation. But even if it's position, the jitter should still cause a change in position of the scenery, not the cockpit. Remember that the cockpit *is* the aircraft -- no matter what the position is, it is always nailed down to the pilot's viewpoint position by definition. But the scenery is always perfectly fine, even the runway right next to the aircraft (not much farther than the cockpit) is rock solid. Really, I don't see any other options -- whatever is causing the jitter is inside the model's scene graph, and not under the scenery. Since the FDM output goes into both, you have to rule it out (or you can put printf's in the update routines and verify that inter-frame distances are never more than 0.1mm or so). 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] jitters testing
Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: On that point, I've tried your patch and it works, but the YASim FDM is then (inexplicably) frozen. Is it working for anyone else? This is a bug that seems to be related to some sort of memory corruption. I've seen it off and on over the last couple of weeks when applying various updates. I saw it once, but unfortunately didn't track it far enough. It's since stopped happening to me. David, if you're getting this repeatably, would you mind tracing the bad values in gdb with a watchpoint? That is, figure out where the bad value comes from, set a watch point at its address* (e.g. watch *((int*)variable)) and re-run the program? If it turns out to be set via another garbage value, then set a watch point there, etc... Ultimately you should get to obviously incorrect code, like a variable that never gets set at all. This is tedious, but reasonably algorithmic. I wish I'd looked harder when it hit me last week; I saw the buffer overflow and just assumed that the garbage was normal behavior. Andy * Not the variable itself -- the address only. I've seen gdb get confused and miss watchpoint changes when watching variable names; maybe it's misoptimizing something? This doesn't help if the address changes across reruns, but in my experience that's actually pretty rare. The bad values are usually already bad during initialization, and initialization is a deterministric process. -- 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] JavaScript!
David Megginson wrote: Erik Hofman writes: -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz What does everyone else think? I dunno. That's awfully big. JavaScript isn't a terribly big language though, so it's possible that this includes a whole bunch of stuff (browser/DOM hooks, test suites, example code) that's not useful to us and could be eliminated. Where can we find it? Is this the Mozilla interpreter? The KDE one? Somebody elses? 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] JavaScript!
Curtis L. Olson wrote: I would argue that if we do embed a script interpreter it should be really small, tight, and light weight. Amen. :) It's possible that the source for the actual interpreter is much smaller than the full package, though. JavaScript implementations are likely to be aimed at browsers, and the browser environment is a notoriously fat interface. It's a pity that there aren't any good, small, tight scripting languages left. Lots of languages *start* small and tight, but rapidly expand. Python did this -- version 1 was small and tight, version 2 is a monster. Perl is about to do it for the Nth time. I tremble in fear everytime Larry releases another apocalypse. Perl 6 is just out of control at this point. There are (duck) scheme variants like guile that are still small, though. Also, there's Lua. Lua is very small and very tight (only a few tens of kilobytes of code). It's also very odd, with strange syntax for stuff that the rest of the world has standardized on long ago. 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
[Flightgear-devel] Jitter found?
Jim Wilson wrote: Setting all the view offsets to 0 I was able to prove that the position/rotation matrices generated on the model and the camera are numerically identical. Here's a sample from the dump: Oooh, but they're not! Take a really close look at the two position vectors (the last row): 5064.624023 590.030945 -1211.297729 1.00 5064.621582 590.031433 -1211.296509 1.00 These are the same up to 6 significant figures, but they differ in the next. If I'm correct that the units are meters, this corresponds to a difference in millimeters. In this case, my figuring gives a distance bewteen these two points of 2.77mm. In the A-4 cockpit, the panel is about 1m away. So 2.77mm subtends an arc of .00277 radians, or 0.16 degrees. There are 1024 pixels across the 55 degree FOV, so the error between those positions is 2.9 pixels. Bingo! There's our jitter. Basically, Curt was right that this is a plain old precision problem. We're right at the limit of a float here. A float has 23 bits of mantissa, so the minimum error for the vector magnitudes above is 5000*2^-23 = 0.6mm. Every calculation you do on the number will increase the error bounds by a third of a millimeter. Do ten FPU ops on a given number (i.e. two matrix multiplications), and you get the 3mm error above. I can see there options to fix this: + Rescale the tiles such that they cover a smaller area that can be represented by a float (very hard). + Rework the viewing/model code such that the final matrices in the two scene graph branches are not merely generated by the same code, but are in fact *exactly* the same values. That is, synchronize the error so the two agree. (rather hard) + Do all the position computations in double precision. Only the position is a problem -- if you separate out the orientation into a float matrix separate from the double-valued position vector and combine them at the end, that should be fine. Doing all the math in double precision would probably be easier still, although the conversion to/from the float-value OpenGL matrices is likely to be clumsy. 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] Jitter found?
Jim Wilson wrote: Those are from two different iterations. I was just proving that the viewer and model were running on the same data, as it had been suggested they were not earlier. The pairs within a single iteration match (this is the same data I posted earlier): Yes, but even between iterations, the FPU error introduces a random 3mm value to the positions you are using. It doesn't matter whether the FDM is right or wrong -- even the tiniest different in input values will result in a 3mm jitter. If the FDM says that the position is different by 4.44E-16 meters (the minimum delta value in a double for a position value of 1m), the output will randomly get moved up to 3mm. Also, not offense intended, but you still seem to be missing the core point: the cockpit is locked down to the aircraft position by definition. No change in position, of any magnitude whatsoever, should produce any detectable change in the cockpit pixels on the screen. Consider a FGLyingBastard FDM that gives you random values: if it moves to the left by 3mm, the cockpit will still be in front of the viewer. If it moves to the right by 7m, the cockpit will still be in front of the viewer. If it warps to Kuala Lampur, ditto. The moon? Yup. Anywhere in the representable universe you try to put the aircraft, the cockpit should still be in front of the viewer. But it's not (quite), it's jittering around. 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] jitters testing
David Megginson wrote: Speaking of taunting, do you have any ideas about the problem I mentioned earlier -- that no text shows up on the radios in your new 3D panel patch? It's the only thing stopping me from committing it. None yet, I need to get home and try it. Nothing looks suspicious; I thought perhaps plib was overriding the glPolygonOffset that I'm using, but it doesn't seem to be. 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] jitters testing
Curtis L. Olson wrote: I should mention before we get too far that glPolygonOffset is not always consistantly implimented across cards/drivers. Is that really true anymore? I know it used to be true ~5 years ago in the era of QuakeGL, but today things are really quite stable. The glPolygonOffset mechanism is the basis for doing multipass rendering, and multipass is pervasive. Are there really any platforms today (that can run FlightGear acceptably) that don't have a solid PolygonOffset implementation? 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
[Flightgear-devel] Antialiased GLUT fonts
[Cross-posted to the plib list, as this isn't entirely FlightGear specific. Dunno if that list allows posts from non-subscribers or not.] The recent discussion about fonts got me interested in actually trying something, so I put together a perl utility that generates an antialiased Glut .txf font from any font that can be rendered in Postscript. It's worked out really well, so I generated .txf files for 33 standard postscript fonts (no Symbol or Dingbats, since those don't have ASCII encodings) and put them up with previewable images at: http://www.plausible.org/glut-fonts/ [Note: please be gentle with my cable modem and don't wget the whole page -- that's 2M of data or so and it will hose my 128kbps upload cap. Just look at the images and grab a few fonts that you intend to use. Or if you must grab everything at least mirror it somewhere. :)] I'm really happy with them. Things that make them better than existing fonts: + They are complete. Each one has glyphs rendered for every printable ASCII character. No more property confusion from different strings rendering identically due to missing glyphs. This alone is enough to make them worth the price of admission. :) + There is no reason in principle that other encodings (Latin-1, for example) couldn't be used instead. I was too lazy to look up the postscript glyph name to character ID mapping. The layout code doesn't care how many glyphs there are. + They are rendered and antialiased from vector descriptions, instead of being pixel-for-pixel copies of X11 screen fonts. So they look a lot better under most conditions (at very small sizes the difference is negligible as mipmapping does the antialiasing for you). + They have more space around the glyphs. Mark's program packed the glyphs too tightly togther; at small sizes, you could see bleeding in the textures from nearby characters. + They make better use of space in general. The characters are drawn as large as practical for simple layout code (i.e., I scale them up, but don't do any gymnastics like recursive packing or non-rectangular layout). So you get more font for your texture byte. Most of the existing plib fonts use only about half of the available texture space. + They're professional fonts. I don't know where typewriter.txf came from, but it's awfully ugly. I replaced it with the antialiased Helvetica, and things look *so* much nicer. The specific fonts used are the freely available URW fonts distributed with Ghostscript (and every Linux distribution), in case anyone is worried about the legality of redistributing font images. Stuff that isn't ideal: + They're stored as 8 bit gray scale images instead of bitmaps, which means that the files are significantly larger. The texture memory footprint is the same, however. + There's a bug in plib. The .txf format allows you to specify a logical step size (distance to the start of the next character) for each character, but plib ignores it. Instead, it uses the *physical* width of the character's bounding box, which isn't the same thing. Due to integer rounding errors at pixel boundaries, this means that some characters in some fonts get clipped at their edges because I can't pad the box size horizontally (I do pad it vertically). It also means that italic fonts (whose bounding boxes slant and thus pack together more tightly than their widths would indicate) tend to render badly in plib in general. I'll see about getting a patch to the plib folks for this. For most of the fonts, it's a minor issue. Anyway, try them out and have fun. Just copy Helvetica.txf on top of typewriter.txf in the Fonts directory of your base package. I won't check this change in because of naming -- Helvetica isn't monospaced, and shouldn't be called typewriter. The right thing to do would be to propertize/unhardcode the default font in the GUI code. The perl/postscript code is available too, if anyone wants to try generating their own font files. Be warned that it's a classic duct tape job, which expects to run on a reasonably recent Linux distribution and find ghostscript and 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] Re: [Plib-devel] Antialiased GLUT fonts #2
Sebastian Ude wrote: What you generated are neither GLUT bitmap nor GLUT stroke fonts (the only place where you usually find *these* fonts is the GLUT sourcecode !), but TXF fonts / textured fonts / font textures. These fonts have hardly anything to do with *GLUT*. Clearly I'm ignorant of the history here. My memory is that Mark Kilgard wrote this library and distributed it along with glut, from which it got picked up by plib et. al. I guess I did (vaguely) know that glut bitmap fonts were a different animal, but I just assumed that all of these formats had been rolled into the default glut distribution. My apologies. Call 'em what you want. :) 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
[Flightgear-devel] Re: Antialiased GLUT fonts
OK, the attached patch adds character width support to the fnt
library, allowing it to handle glyphs whose logical width (distance
along the baseline to the next character) differs from their physical
width. Characters like the slash have this property, as do many
italic glyphs.
The current antialiased fonts need it because, unlike the bitmap-based
.txf fonts, the character glyphs in the texture are not exactly pixel
aligned. Thus, I need to pad the texture box containing a glyph
with whitespace to be sure that the entire glyph is contained in the
textured quad. But that padding changes the physical width of the
glyph, which means that horizontal padding can't be used without
changing the spacing of the characters -- in effect, I have to choose
between potentially chopping off parts of a character or achieving the
correct character spacing as designed in the font.
Anyway, it seems to work. One thing to worry about (and for which I
did not test) is the effect this patch will have on older fonts. The
code now interprets a value (step), which it used to ignore. If
older fonts don't set this correctly, they will be misrendered by
plib. I did a spot check of the fonts distributed with FlightGear,
and they look OK. Hopefully all fonts generated by Mark's tool will
be equally fine.
I've generated a new set of font files with proper padding and put
them back up on my web site (http://plausible.org/glut-fonts -- no, I
didn't change the URL to remove the reference to glut). These look
much nicer after the patch -- no chopped characters, and proper font
metrics for all.
FlightGear folks: how do you want to handle this? We can [1] use the
new fonts, which won't render well (very W I D E spacing) in unpatched
versions of plib, [2] use a slightly hacked new-style font that chops
off a few characters but renders with appropriate spacing in all
versions of plib, or [3] wait for a new plib release before making a
decision. Since we're currently tracking plib CVS pretty closely
anyway (the AC3D shading issue), I'd argue for #1. We can always
provide a property-based fallback to typewriter.txf for releases.
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/fnt/fnt.cxx
===
RCS file: /cvsroot/plib/plib/src/fnt/fnt.cxx,v
retrieving revision 1.7
diff -u -r1.7 fnt.cxx
--- src/fnt/fnt.cxx 12 Dec 2001 23:49:36 - 1.7
+++ src/fnt/fnt.cxx 28 Jun 2002 03:14:11 -
@@ -102,14 +102,14 @@
curpos[2] ) ;
glEnd () ;
- float ww = ( gap + ( fixed_pitch ? width : v_right[cc] ) ) * pointsize ;
+ float ww = ( gap + ( fixed_pitch ? width : widths[cc] ) ) * pointsize ;
curpos[0] += ww ;
return ww ;
}
-void fntTexFont::setGlyph ( char c,
+void fntTexFont::setGlyph ( char c, float wid,
float tex_left, float tex_right,
float tex_bot , float tex_top ,
float vtx_left, float vtx_right,
@@ -119,6 +119,8 @@
exists[cc] = FNT_TRUE ;
+ widths[cc] = wid;
+
t_left[cc] = tex_left ; t_right[cc] = tex_right ;
t_bot [cc] = tex_bot ; t_top [cc] = tex_top ;
@@ -127,7 +129,7 @@
}
-int fntTexFont::getGlyph ( char c,
+int fntTexFont::getGlyph ( char c, float* wid,
float *tex_left, float *tex_right,
float *tex_bot , float *tex_top ,
float *vtx_left, float *vtx_right,
@@ -136,6 +138,8 @@
unsigned int cc = (unsigned char) c ;
if ( ! exists[cc] ) return FNT_FALSE ;
+
+ if ( wid != NULL ) *wid = widths [cc] ;
if ( tex_left != NULL ) *tex_left = t_left [cc] ;
if ( tex_right != NULL ) *tex_right = t_right[cc] ;
Index: src/fnt/fnt.h
===
RCS file: /cvsroot/plib/plib/src/fnt/fnt.h,v
retrieving revision 1.5
diff -u -r1.5 fnt.h
--- src/fnt/fnt.h 7 Nov 2001 23:51:09 - 1.5
+++ src/fnt/fnt.h 28 Jun 2002 03:14:11 -
@@ -90,6 +90,10 @@
v_bot==0.0 and v_top==1.0.
*/
+ /* Nominal baseline widths */
+
+ float widths [ FNTMAX_CHAR ] ;
+
/* Texture coordinates */
float t_top [ FNTMAX_CHAR ] ; /* Topedge of each character [0..1] */
@@ -171,19 +175,19 @@
float getGap () const { return gap ; }
- void setGlyph ( char c,
+ void setGlyph ( char c, float wid,
float tex_left, float tex_right,
float tex_bot , float tex_top ,
float vtx_left, float vtx_right,
float vtx_bot , float vtx_top ) ;
- int getGlyph ( char c,
+ int getGlyph ( char c, float* wid,
float *tex_left = NULL, float *tex_right = NULL,
float *tex_bot = NULL, float *tex_top = NULL,
float *vtx_left
Re: [Flightgear-devel] Re: [Plib-devel] Antialiased GLUT fonts #2
Steve Baker wrote: Can we add this tool into PLIB in the 'tools' area? It would be a marvelous addition. All yours. As I pointed out, though, it's definitely a tool of the duct tape and fishing line variety. :) It expects to find a ghostscript interpreter and ImageMagick's mogrify program on the command line, takes a .afm font metrics file as its sole argument, and expects that the font therein is accessible to ghostscript. Basically, it should work out of the box on most linux distributions, and nowhere else without a lot of work. If you have a TrueType font that you want to generate: export GS_FONTPATH=wherever the font is ttf2afm yourfont.ttf whatever.afm font.pl whatever.afm Wait for a while (at 16x downsampling, this takes 1-2 minutes on my Athlon 1800+), and the .txf file will appear in the current directory. It will have the Postscript language name of the font. 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] jitters testing
Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. Conversely, in tower view, the scenery should stay put while the aircraft jitters. But it doesn't, the aircraft geometry jitters here too. So the problem somewhere in the model's scene graph; there really aren't any other places it could hide that I can think of. Could you give us a quick rundown of exactly which matrices or ssgTransforms get added to the scene graph and where they come from? I started tracing this out but got distracted by the glut font stuff (different discussion entirely). :) 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] jitters testing
Curtis L. Olson wrote: It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. Actually, the whole cockpit is jittering. The ball just has more high-frequency information to catch your eye. The panel doesn't (er, didn't) jitter because it's drawn via an entirely different code path that doesn't look at aircraft orientation at all -- only viewing offsets. If you apply my current 3D panel code, you'll see the whole cockpit assembly wiggle in exactly the same way. 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] New panel code
David Megginson wrote: 1. Can you post a copy of your modified base-package files (a4-yasim-set.xml and a4-blue.xml)? The -set files don't require any significant changes -- just remove the panel entries and that's it. The model files for the A-4 and 172 are attached. All they needed is a panel entry like the one I posted. 2. Are you willing to do the 3D C172 file? I don't want to put your patches in CVS if they'll kill the current 3D cockpit for the 172; OK, attached. I just lifted some rough coordinates from AC3D's demo program and twiddled a bit to get it to look more or less OK. It's not polished, but it'll do. The mag compass is partly obscured by geometry -- it should really move into its own panel somewhere else, or be modeled in full 3D. Also, the background texture doesn't quite match the geometry it's drawn on. But it's there, it works, and it's drawn *behind* the yoke. :) One thing is wrong, though: Something is drawing the 2D panel, even though I removed the entries from the -set.xml file. I'm flummoxed on this one. It's not part of my code changes, as it's there regardless of whether the 3D panel exists or not. It doesn't happen on the A-4; is it possible that something has hard-coded the 172's panel somewhere? 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) ?xml version=1.0? PropertyList pathc172-dpm.ac/path !-- 3D Panel -- panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path bottom-left x-m-0.12/x-m y-m-0.64/y-m z-m-0.36/z-m /bottom-left bottom-right x-m-0.12/x-m y-m 0.64/y-m z-m-0.36/z-m /bottom-right top-left x-m-0.17/x-m y-m-0.64/y-m z-m 0.06/z-m /top-left /panel !-- LOD for the model as a whole -- animation typerange/type min-m0/min-m max-m1/max-m /animation !-- LOD for specific objects -- animation typerange/type object-nameCabin/object-name object-nameSeat.1/object-name object-nameSeat.2/object-name object-nameSeat.3/object-name object-nameSeat.4/object-name min-m0/min-m max-m50/max-m /animation animation typerange/type object-nameYoke.1/object-name object-nameYoke.2/object-name object-namePedal.1/object-name object-namePedal.2/object-name object-namePedal.3/object-name object-namePedal.4/object-name object-nameThrottle/object-name object-nameMixture/object-name object-nameCompass/object-name object-namePedestal/object-name min-m0/min-m max-m3/max-m /animation !-- Object movements -- animation typeselect/type object-namePropeller/object-name condition less-than property/engines/engine[0]/rpm/property value1500/value /less-than /condition /animation animation typeselect/type object-namePropeller.2/object-name condition greater-than property/engines/engine[0]/rpm/property value1000/value /greater-than /condition /animation animation typetranslate/type object-nameThrottle/object-name property/controls/throttle[0]/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typetranslate/type object-nameMixture/object-name property/controls/mixture[0]/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typetranslate/type object-nameYoke.1/object-name property/controls/elevator/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typerotate/type object-nameYoke.1/object-name property/controls/aileron/property factor-45.0/factor axis x1.0/x y0.0/y z0.0/z /axis center x-m0/x-m y-m-.26/y-m z-m-.29/z-m /center /animation animation typetranslate/type object-nameYoke.2/object-name property/controls/elevator/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typerotate/type object-nameYoke.2/object-name property/controls/aileron/property factor-45.0/factor axis x1.0/x y0.0/y z0.0/z /axis center x-m0/x-m y-m.27/y-m z-m-.29/z-m /center /animation animation typetranslate/type object-namePedal.1/object-name object-namePedal.3/object-name property/controls/rudder/property factor0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typerotate/type object-namePedal.1/object-name object-namePedal.3/object-name property/controls/brakes[0]/property factor-15/factor axis x0.0/x y1.0/y z0.0/z /axis center x-m-0.1/x-m y-m0/y-m z-m-0.9/z-m /center /animation animation typetranslate/type object-namePedal.2/object-name object-namePedal.4/object-name property/controls/rudder/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation
Re: [Flightgear-devel] Glut font format
Norman Vine wrote: I think that you will find that inorder to get 'high quality' fonts one needs to use a vector based font directly. The only problem in doing this is that the polygon count goes up considerably. Have you tried the antialiased fonts in KDE, WinXP or recent versions of Gtk+? They look *fantastic*, and are generated with exactly the method I propose -- a very high resolution bitmap is generated and then downsampled into a grayscale image that is alpha composited onto the screen. The plib TXF loader already does the second part, there simply aren't any tools to do the rendering and downsampling. 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] Buffer overflow in auto_gui.cxx
Jim Wilson wrote: Hmmm...I wonder if this relates to some of the effects I've seen recently with the delta time and fdms. If you could put up a separate patch for this (before the massive checkin :-)), I'd like to run some tests to confirm. BTW, thanks for tracking this down. This is what I did last night. It works for the bug I was seeing, but I didn't go through the code looking for other printf's that might blow up with the same values. The hard-coded 8 should be unified with the static definition of SliderText, of course. As Norman and I pointed out, though, a better solution would probably be to sanify the values before use if possible. Sometimes, if they come from arbitrary user input, you can't and have to resort to buffer size checking with snprintf and the like. But since these are angles, it should be possible. Andy RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Autopilot/auto_gui.cxx,v retrieving revision 1.29 diff -u -r1.29 auto_gui.cxx --- auto_gui.cxx26 Mar 2002 01:38:11 - 1.29 +++ auto_gui.cxx24 Jun 2002 17:04:59 - @@ -510,7 +510,7 @@ APAdjustHS0- setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS0- setCallback ( maxroll_adj ) ; - sprintf( SliderText[ 0 ], %05.2f, globals-get_autopilot()-get_MaxRoll() ); + snprintf( SliderText[ 0 ], 8, %05.2f, globals-get_autopilot()-get_MaxRoll() ); APAdjustMaxRollTitle = new puText ( slider_title_x, slider_y ) ; APAdjustMaxRollTitle- setDefaultValue ( MaxRoll ) ; APAdjustMaxRollTitle- getDefaultValue ( s ) ; @@ -527,7 +527,7 @@ APAdjustHS1- setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS1- setCallback ( rollout_adj ) ; - sprintf( SliderText[ 1 ], %05.2f, globals-get_autopilot()-get_RollOut() ); + snprintf( SliderText[ 1 ], 8, %05.2f, globals-get_autopilot()-get_RollOut() ); APAdjustRollOutTitle = new puText ( slider_title_x, slider_y ) ; APAdjustRollOutTitle- setDefaultValue ( AdjustRollOut ) ; APAdjustRollOutTitle- getDefaultValue ( s ) ; @@ -544,7 +544,7 @@ APAdjustHS2- setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS2- setCallback ( rolloutsmooth_adj ) ; - sprintf( SliderText[ 2 ], %5.2f, + snprintf( SliderText[ 2 ], 8, %5.2f, globals-get_autopilot()-get_RollOutSmooth() ); APAdjustRollOutSmoothTitle = new puText ( slider_title_x, slider_y ) ; APAdjustRollOutSmoothTitle- setDefaultValue ( RollOutSmooth ) ; @@ -562,7 +562,7 @@ APAdjustHS3- setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS3- setCallback ( maxaileron_adj ) ; - sprintf( SliderText[ 3 ], %05.2f, + snprintf( SliderText[ 3 ], 8, %05.2f, globals-get_autopilot()-get_MaxAileron() ); APAdjustMaxAileronTitle = new puText ( slider_title_x, slider_y ) ; APAdjustMaxAileronTitle- setDefaultValue ( MaxAileron ) ; -- 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
[Flightgear-devel] New panel code
OK, as promised, I have the fixed 3D panel support ready for testing (http://plausible.org/andy/vpanel-20020624.tar.gz). Changes include: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the panel draws on top of yoke bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. So grab the source and unpack it into your FlightGear source directory. The first thing you will notice is that the old virtual cockpits aren't virtual anymore. You will need to put them into the aircraft model file. This is the syntax I added to the a4-blue.xml model files to get a panel that matches Jim's current work (I haven't done any of the other planes yet): panel pathAircraft/a4/a4-panel.xml/path bottom-left x-m-3.21/x-m y-m-0.24/y-m z-m 0.44/z-m /bottom-left bottom-right x-m-3.21/x-m y-m 0.24/y-m z-m 0.44/z-m /bottom-right top-left x-m-3.21/x-m y-m-0.24/y-m z-m 0.69/z-m /top-left /panel That is, you tell the model to include a given 2D panel file, and map it to the quadrilateral defined by the three points. The nominal size of the panel is still specified in the panel XML file, as the w and h properties; these values are used for the mapping. Note that the coordinates are plib or JSBSim coordinates, and *not* the numbers you find in the .ac file. The plib AC3D loader swaps the Y and -Z axes at load time. We should probably pick one convention (the view offsets use yet another, as does YASim) and make everything conform. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now jitter in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. 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] Capturing warnings
Jonathan Polley wrote: I cannot redirect stderr via 'command 2 file' on my Mac, so the easy solution was out. I did find that the following command works: Rubbish. Sure you can. You just have to run a real shell. :) Basically, this is a long-standing misfeature of csh, which never existed in the original bourne shell and which happily has never been emulated. There is no syntax for redirecting stderr any differently from stdout. Bill Joy apparently never needed it, and no one else (over 20 years!) ever bothered to add it. I have no idea -- none whatsoever -- why Unix vendors insist on shipping this dinosaur as the default shell when there are *so* many better options available as free software. I guess Apple decided not to buck the trend and try to fix the command line they were trying so hard to hide. :) Seriously, I'd be shocked beyond measure if bash didn't build and install just fine on OS X. Use it, it's vastly better than csh. 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] Glut font format
Norman Vine wrote:
Here's Mark's example of the command used to generate the sorority.txf
file: Just change the Font name and the 'glist' to be what you want
gentexfont \
-fn '-sgi-sorority-medium-r-normal--40-*-*-*-p-*--ascii' \
Right, but this only gets you a copy of the X11 bitmap font, which is
ugly and aliased. My original point was that with only a little work,
you could use ghostscript/FreeType to render a very high (16x)
resolution bitmap of each character and downsample to get a very
nicely antialiased texture to use with the font. Which would be
great, except for the fact that there are no tools available to do
this, nor documentation to write such tools.
Mark's program generates bitmapped textures from X11 bitmapped fonts.
So, because the X11 bitmap fonts are ugly as sin, the existing plib
fonts leave a lot to be desired*. But there's nothing in the software
engine that requires that -- it's just a tools issue.
All that being said, I did look through the source code a bit and
think I've puzzled out the format. Attached is a perl script that
parses a .txf font, prints the metrics information to stdout, and
generates a .pgm file containing the texture. (Actually, I got the
texture order wrong, so the image is flipped vertically).
I'll see if I can leverage this into some prettier fonts at some point
in the future.
Andy
* There are some other problems, too. Mark leaves almost no padding
between the characters in the bitmap, so mipmapping causes the
characters to bleed or run together when displayed at small
sizes. And some of the metrics are funny -- witness the alignment
of the characters in the button labels of the property picker, for
example.
--
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)
#!/usr/bin/perl -w
use strict;
my $file = shift or die;
open TXF, $file or die;
sub getbyte { my $val; read TXF, $val, 1 or die; return ord $val; }
sub getshort { my $val; read TXF, $val, 2 or die; return unpack v, $val; }
sub getint { my $val; read TXF, $val, 4 or die; return unpack V, $val; }
my $ENDIAN = 0x12345678;
my $magic = sprintf 0x%8.8x, getint();
my $endian = sprintf 0x%8.8x, getint();
my $format = getint();
my $texwid = getint();
my $texhgt = getint();
my $linehgt = getint();
my $unk = getint();
my $nglyph = getint();
printf Magic $magic Endian $endian Format $format\n, $magic, $endian;
print Texture: ${texwid}x$texhgt Line: $linehgt Glyphs: $nglyph Unk: $unk\n;
die Bad magic number ($magic) if $magic ne 0x667874ff;
die Bad endianness tag ($endian) if $endian ne 0x12345678;
for(my $i=0; $i$nglyph; $i++) {
print Glyph $i\n;
printchar: , getshort(), \n;
print width: , getbyte(), \n;
print height: , getbyte(), \n;
print X: , getbyte(), \n;
print Y: , getbyte(), \n;
printstep: , getbyte(), \n;
print unk: , getbyte(), \n;
printxoff: , getshort(), \n;
printyoff: , getshort(), \n;
}
$file =~ s/\.txf$/.pgm/;
open PGM, $file or die;
print PGM P2\n$texwid $texhgt\n255\n;
if($format == 0) {
for(my $i=0; $i($texwid*$texhgt); $i++) { print PGM getbyte(), ; }
} else {
for(my $i=0; $i($texwid*$texhgt/8); $i++) {
my $byte = getbyte();
for(my $j=0; $j8; $j++) {
print PGM ($byte (1$j)) ? 255 : 0 ;
}
}
}
Re: [Flightgear-devel] A-4C attitude indicator
This looks fantastic. I think this may be the first working gyro ball in a PC simulator cockpit. At least, I haven't seen one anywhere else. :) On question, unrelated to the ball actually, is exactly what we're trying to simulate. You seem to be aiming at an A-4C cockpit, but the aero model is for an A-4E which has a bigger engine. The 3D model claims to be a C, but it's dolled up in Blue Angels paint, and they flew the A-4F. To nit further: the slats are down, but the Blue Angels planes had their slats bolted shut*. And the refueling probe is the cranked shape that wasn't introduced until the A-4M. :) Maybe this is more detail than we should worry about. A foolish consistency being the hobgoblin of little minds and all that, but we should probably just pick something to aim for. My vote, so long as the blue paint is on the thing, is to model the A-4F. I'm cool with the C, though. The difference to the YASim file is basically engine thrust and performance numbers; pretty simple. * For safety. The A-4 had automatic slats that were retracted by aerodynamic force -- they dropped automatically at low airspeeds and high AoA's. On the ground, they just hung open. This was a great idea for maintenance purposes, but left open the possibility that they might get stuck and deploy asymmetrically. That's a recoverable situation normally, but not when there's another plane a few feet under or above your wing tip. :) 1) The flags. There are four of them in the photos I've seen but so far I haven't found any information on which is which. One has the word Off on it, and I assume that it means the entire assembly is unpowered. I'm clueless here. Obvious warning flags for the instrument would be the same as for a normal AI or HSI -- vacuum failure (or maybe electrical failure or low gyro RPM), lack of radio signal (VOR/TACAN/LOC/GS). 2) The calibration of the turn-rate indicator is just a wild guess. If anyone knows how it should respond please let me know. My book has some shots that show the turn indicator marked with 4 minute markings to the left and right of the top of the display, perhaps 30-40 degrees apart. A four minute turn corresponds to 1.5 degrees per second. Dunno why they picked four minutes instead of two. 3) The GS indicator is not enabled yet. Also note that there is an aircraft sillohette behind the cross hairs. I'm not sure how to animate it (maybe it stays with the gs arrow)? This one's easy -- leave it out. The A-4F was the first version to have an ILS receiver. This was around 1965 or so, which probably corresponded to the initial installation of ILS equipment at Navy installations and on carriers. For late model aircraft, the horizontal bar probably also doubled as a flight director indicator. 4) The size of this thing is somewhat difficult to judge from the photos, but comparing it to other items on the panel, my guess is the ball is about 4 in diameter and the outer bezel is about 5 or 6. It looks bigger in the one A4-C cockpit photo that I have, but I believe that the A4-C panel is narrower than later models. I'm pretty sure it's the same size -- there were no significant changes (other than to the radome in the nose) to the forward fuselage during the Skyhawk's lifespan. I know they used the same ejection seat until the marines replaced it in their A-4Ms. AFAIK the A4-C is the first in the A4 series to have this all attitude instrument. I think that's right. I have a cockpit photo of one of the original A4D's delivered in 1956, and it shows a WWII-looking flat card gyro. 5) The X15 (see http://www.sierrafoot.org/x-15/panel_large.jpg ) used what appears to be the exact same instrument (with the exception of the glide slope scale in this diagram). I've seen a photo of an AV-8A cockpit with the ball, too. I agree, we need to decide on placement for these things. Anywhere is fine with me. 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
[Flightgear-devel] Buffer overflow in auto_gui.cxx
I got bitten by some static data corruption problems while working on
the panel stuff this afternoon (which I have almost working, by the
way -- expect a big code drop tomorrow morning). I tracked it down to
a buffer overflow in auto_gui.cxx. In the string formatting code for
the labels, there are some sprintf calls that look like this:
sprintf(buffer, %05.2f, value);
Where the buffer is a static variable with a length of 8. It turned
out that one of the values was a huge garbage value -- something like
1e223.
This code looked correct to me, with the field width being less than
8. But it turns out that that C standard allows for the buffer to
overflow anyway. What happens is that the exponential form of the
number can't fit for whatever reason, so the glibc sprintf tries to
print it in (gack!) decimal. You can verify this with the following
tiny program:
int main() { printf(%05.2f\n, 1.1235e223); }
...which gives the following output on my machine:
11234993833496141165207167137504629455791386815894971093998449766224059134612227306117948559764428592704563810063396445147361721349723249504875046156126872109285397930933011042616316938278030005998645453598490624.00
Needless to say, the static data area wasn't happy with 200+ bytes of
overflow. :)
In my copy, I fixed this with snprintf, but something nags at me that
this isn't portable to some platform we care about. We could mock up
a slow version that did an unchecked sprintf into some very large
buffer and copied the result out. Probably a better idea is to sanify
the input values so they can't have such unprintable values.
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] AC3D file format travails
Jim Wilson wrote: This looks a lot better. Just checked in a start on some adjustments to the cockpit geometry and a bezel for the attitude ball. How sure are you that the ball is supposed to be 6 in diameter? It looks to be about 4 in every picture I've seen (but those can be deceptive). I'm not at all certain, honestly. It occurs to me that I might be fooled by the tiny size of the A-4 panel into thinking it's larger than it is. The current model is actually only 7cm/2.75 in diameter, though, which is almost certainly too small. Or maybe there's a scaling factor coming in from somewhere else? I looked at the aircraft model in AC3D and decided that the units were in meters, but maybe something else is applying scaling? 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
