Re: [Flightgear-devel] Flightgear first impression
Jim Wilson writes: > > We have a lot to thank Bill Gates for, including the way he > (especially) and others got under Richard Stallman's (and others) > skin with their shrink-wrap revolution. We owe Bill a debt of > gratitude for making sure that open source became a popular idea, > even for windows users and developers. :-D Hmm -- as I recall, it was AT&T and Sun that got under Stallman's skin, especially when AT&T started requiring a license for the Unix code. Microsoft was barely on the radar screen then, any more than, say, Nintendo is today for computer researchers. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ancient 'ascii' scenery format
Curtis L. Olson writes: > Is anyone still using this ancient file format? Does anyone have any > objections to ending support in flightgear for it? I think that PPE has support for the old ASCII format but not the new binary one. Other than that, chuck it. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear first impression
Jim Wilson writes: > Yes, originally, that's correct. Something to do with AT&T and a > printer driver, I think. I was just speaking of Bill...since back > in those days the profile for Stallman's project was lower > too. That is to mean lower than after the mid eighties, when > desktop/workstation unix emerged, not to mention later with linux. > The "and others" are significant. If it wasn't for Bill, linux > probably would not be where it is today. Maybe, but I'd give the two Andys more credit than Bill. In the early 90's, Andy Tannenbaum was uncooperative enough that Linus decided to fork Linux rather than providing i386 patches to Linux (I was on the Minix list at the time); by the late 90's, Andy Grove's Intel made cheap desktop hardware powerful enough to provide a reasonable alternative to painfully overpriced servers from Sun, IBM, and (once upon a time) DEC. Strife with Microsoft gets Linux its press, but they're not really in competition -- you'd have to be nuts to try to build something like Google using WinNT or Win2K (heck, even Microsoft knows not to use Windows for HotMail), and you'd have to be almost as crazy to try to convince a big company to switch to Linux on the desktop. Microsoft may be lusting after the server market with its bigger margins, but they're not smart enough to get much of it above the workgroup level; Linux advocates may be lusting after the desktop with its high visibility and coolness factor, but it's probably too late to grab it, even if they weren't all bogged down into the KDE vs. Gnome wars. It's Sun and IBM that Linux is hurting, much more effectively than Microsoft ever could; IBM is trying an if-we-can't-beat-them-join-them campaign, but that doesn't change the fact that cheap Intel hardware running Linux in a cluster beats the stuffing out of any big iron from Sun or IBM by a couple of orders of magnitude (both in cost and performance). Google is a famous public example of this fact, but there are several private examples I've been involved with that are even more dramatic. It does Fortune 50 companies no good to make public noise about how important Linux is to their operations (they still need goodwill from the commercial vendors), but trust me, it's mission critical to at least one I've been involved with, and it's not Microsoft who's losing the sales. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cessna 310 Model
Andy Ross writes: > It's not exporting any properties. :) > > I was lazy when I did the new XML files, and only did property exports > for the aircraft that I could test visually. All that's necessary is > to clone the tags from the DC-3, which should be > identical in all ways. I'll get a new one put together soon, if you > don't want to do it yourself. I did it today. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plane above the runway
Andy Ross writes: > > Another thing that might be helpful is if the FDM's would report the > > amount of each gear compression to FlightGear so that could be > > animated (and hopefully keep the tires above the ground.) > > No problems there. YASim now reports this number in > /gear/gears[n]/compression-norm (should be an OK choice, according to > our rapidly evolving property conventions). The remaining problems > are only bookkeeping. We need to make exactly certain that the FDM > and the model agree on the placement of the gear and their direction > of compression. Interesting -- I won't promise to integrate this into the 3D models this week, but it should show up eventually. How far should this go? For variable-pitch props, we could something like /engines/engine[n]/prop-pitch-norm and you could see where the governor is keeping the blades and whether they're feathered. That wouldn't be hard to do from JSBSim (which actually knows the pitch angle), but it might be trickier from YASim. I'm worried about how far this will all lead, though. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Plane above the runway
Martin Dressler writes: > I hope you mean this as a joke. I'm not sure. It's no more extreme than animating the elevator trim tabs, which people _have_ asked for; in fact, the prop blade pitch is more visible than the trim-tab position, and could have some useful educational and debugging value. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] view code. was Virtual Cockpit!
Martin Dressler writes: > Thera are a lot of strange things in view code. It is initialized > here and there. There is also problem with lat,lon positions. The > code is too oriented towards FDM position not to viewer > position. It's not problem with current view modes, but it could be > problem with tower (or ground :) view. I agree -- it's a pretty serious mess (but it was useful having it up to now). I'm also planning to do some work on the view code, so let's make sure we don't end up duplicating each-others' work -- send in your changes frequently rather than saving them all up, and I'll do the same. Instead of rewriting from scratch, I'm thinking of trying to reorganize what we have first. Norm Vine did some of the work on the view code, and he knows an awful lot more than I do about how to write and optimize all the matrix and coordinate transforms. > > > > pilot > > > chase > > 25 > > > > chase > > 100 > > > > ground > >5 >3 >2 > > > > That looks good -- a single, configurable view manager would be better than a few ad-hoc, hard-coded ones. You'll need to be able to specify a few more parameters (i.e. draw the 3D model, look towards the plane, reverse view direction [for external], etc.). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Mainmain.cxx,1.245,1.246
Alex Perry writes: > Putting the clip plane at 0.1 is an easy way to stop me doing demos of FGFS. > I don't _have_ a machine with better than 16 bit depth buffering, and the > notebook that I do most of the demos with cannot of course be upgraded. I understand. How does everything look with the change, before I put it back? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Andy Ross writes: > Or just turn the depth buffer off for the cockpit and sort the > geometry; for most cockpit layouts, this should be pretty feasible. > It won't work if the cockpit has moving parts (yokes or whatnot) that > obscure other pieces. I don't think this is an easy option, at least not with a true 3D model wrapped around the viewer. We'll have to find a more robust solution. To start, I can make the depth buffer 0.1 only when the interior model view is enabled, so no one loses without it; old hardware probably won't do well with the interior view anyway. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Scenery Strangeness
Paul Deppe writes: > With the latest CVS (1400 EST 3/5/2002) on my Cygwin/Win2k system the > textures in mountainous areas seem to "walk" across the ground and appear > and disappear in a very strange manner. I am wondering if anyone else sees > this problem. Mea culpa -- it's from changing the near clip plane to get 3D interior views working. I'm fixing it now (the problem doesn't show up on newer hardware, like the GeForce2). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scenery Strangeness
Paul Deppe writes: > No problem, thanks for verifying this. As far as the hardware goes, though, > the problem did show up on my GeForce2 Go 32MB (in a four-month-old Dell > 8100 laptop). Strange -- I didn't see it with a GeForce2 Go 32MB in a Dell 8000. Oh well. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main main.cxx,1.245,1.246
Jim Wilson writes: > Ummm...why not clear the z-buffer and use a seperate scene graph? Note that > there are *lots* of people using pre-geforce generation hardware. Probably > more than not. Time -- I don't know if I'll have time to figure all that out this week. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] c310u3a
Jim Wilson writes: > Oops forgot the screenshot: > http://www.spiderbark.com/fgfs/bluecanoe-takeoff.png Yes, it's a beauty. I've already sent private e-mail to John and Curt suggesting that we make it the default, at least until my 3D model is textured and better developed. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Changes in raw_ctrls.hxx
John Wojnaroski writes: > Just updated local CVS. Note that some changes where made to > raw_ctrls.hxx. There is a problem trying to get the various > platforms to agree on how sizeof() computes the number of bytes in > a data structure. I think this is a good argument for using an ASCII protocol rather than a binary one. Unless you're moving a lot of data (i.e. vertices for scenery or a 3D model), the extra overhead probably isn't noticable, and all big/little-endian and other problems disappear. For controls, all of the data should still fit in a single packet in ASCII. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] UIUC planes below runway
John Check writes: > I noticed that the UIUC planes are buried under the runway > at startup. Is anybody else seeing this? Console output looks like > this: > FGLaRCsim::set_Altitude: 1.14496 > (*) Current Altitude = -1.87 < -1.85 forcing to 1.15 > FGLaRCsim::set_Altitude: 1.14503 > (*) Current Altitude = -2.09 < -1.85 forcing to 1.15 > FGLaRCsim::set_Altitude: 1.14519 > > Any Ideas? It probably has something to do with the UIUC gear code. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
John Wojnaroski writes: > > I also think that I know *too much* about the details of the aero > > and that pilots who don't have an in-depth understanding of aero > > engineering can oftentimes give better feedback than those who > > do. > > > Careful there, are you saying pilots who don't have aero > engineering backgrounds can give better feedback than pilots who > have aero backgrounds?? Or pilots don't have a in-depth > understanding of aero?? The only surviving manuscript of Beowulf was damaged in the Cotton library fire in 1731, and some parts of it are now unreadable or have actually crumbled away. Fortunately, before the fire there were two transcripts made. The first was made by a copyist who did not understand Old English at all and wasn't familiar with the Insular script: he made lots of stupid errors, but he also tended to preserve unusual words and spellings from the original. The second was made by someone familiar with Old English: he didn't make too many stupid, obvious mistakes, but he also tended unconsciously to replace rare words or spellings with more common ones. The same problem exists in any field -- when people know what to expect, they tend to find what they're expecting. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim Brennan jjb - writes: > The "photorealistic" instruments in some simulators are good to have, but > (IMHO) not as importaint as proper flight modeling. > > I personally see NO need for the nice views of the airplane, and its > moving parts as seen from other airplanes except if one is flying > formation or shooting at the airplane. ... or replaying a finished flight to study it, or watching a student's progress in external view on a second monitor, or watching the propeller from inside the airplane. More importantly, I think that soon we won't be making the same distinction between internal and external view -- we might even use the same 3D model for both. In that case, the same animation code that spins the propeller can move the yoke, throttle levers, rudder pedals, etc. (I imagine that needles on gauges will still be done with rotating textures). > While this is nice to have for some limited purpose, it adds > nothing to the realism of the simulator from the perspective of the > person flying the sim. No, but it might be useful for the instructor to watch, or for the student during a replay of a failed flight. > These efforts could better be used in improving the flight models, and > the functionality of the sim to interface to other sims and external > programs and more realistic views (such as those for KSJC). It's not a zero-sum game. The people who are good at flight models (Jon, Tony, Andy, etc.) are already spending pretty-much all their time on flight modelling; contributions to other areas from other people aren't taking away from that. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rationalizing view
As far as I can figure out, there are only three situations we need to deal with in the viewer code: 1. Looking away from a known position. 2. Looking towards a known position from a known distance and angle(s). 3. Looking from one known position towards another. An example of (1) is the view from inside the aircraft; an example of (2) is a chase view; and an example of (3) is a tower view. The view manager class should take care of setting up viewers appropriately for different situations. In every case, we want to be able to specify offsets for all six degrees of freedom. I think that it makes sense to put all of this in a single, configurable viewer class, rather than having separater viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that duplicate most of each-others' code. The main required output is the VIEW matrix to pass to ssgSetCamera, but several parts of FlightGear need vectors and matrices that are byproducts of calculating VIEW as well (such as the world-up vector); it would be nice to minimize these dependencies as far as possible. All of the views can still be managed by the view-manager class (a proper subsystem), but we should try to remove all hard-coded dependencies from the rest of the FlightGear codebase. For example, the scenery code doesn't need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera. Comments? Volunteers? I think that the easiest solution is probably a clean rewrite, but paying close attention to how Norm used the matrices and vectors in the original. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Wolfram Kuss writes:
> IMHO the decision for a 3D cockpit is not a decision for bad
> legibility. Worse than a pure 2D cockpit, hand optimized for the
> resolution, yes, but not bad.
The optimization is the key. FLY! uses a 2D cockpit (at least, FLY! 1
does), and the panel is blurry and hard to read on my 1600x1200 LCD
because it's optimized for 1024x768.
> In a 3D cockpit, this can be chosen via FoV. Actually, when I start a
> plane and click all the things in the cockpit, I reduce FoV a bit
> ("zoom in", "move my nose closer to the panel"). OTOH, when I land, I
> zoom out very much to see the horizon left and right to judge my angle
> etc.
With typical user-level technology, we might end up configuring things
like this: in her left hand, the user holds the joystick or yoke to
control the plane (possibly assisted by rudder pedals); in her right
hand, she holds the mouse to control the view direction and zoom
level. Fancier users can buy things they strap on their heads to
control the view, but my family would laugh at me if I did that (I
don't even have the nerve to buy a yoke).
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Michael Selig writes: > With respect to the chase view (2), three potential options come to mind: These are excellent suggestions, but I think that we'll want them to end up in the view manager (or elsewhere) rather than in the viewer proper. As long as we tell the viewer, for each frame, what its reference point, orientation, offsets, etc. are, it doesn't need to know whether we're modelling a control tower, chase view, etc. Eventually we might even control some of the views through external scripting. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim Wilson writes: > Fly! uses a 3D cockpit. They use 2D for most of the > instrumentation, switches and knobs, and 3D models for the things > that really need it like levers. I have no experience with FLY2K or FLY2, so I cannot comment on those, but FLY1 definitely uses a 2D cockpit. Granted that there might be a couple of small, animated 3D objects, but the panel is a flat picture projected in its own coordinates that slides in the X/Y axes independently of the outside scene -- that's exactly the definition of a 2D panel. Unlike FlightGear, FLY1 limits the viewing direction to fixed viewpoints and has a separate 2D picture to project for each one. The pictures are beautiful, but there is nothing 3D about it. > More than likely the legability problem is your LCD at 1600x1200 > ;-) No, it's a 1600x1200 LCD trying to do 1024x768. Unlike CRTs, LCDs have a fixed number of pixels, so they have to double or leave out individual pixels when changing resolutions. The picture is clearer in some ways when I change FLY! to 800x600, but now I've lost 75% of my resolution. Again, I cannot comment on later FLY! versions, except that when I go to window mode (and lose 3D acceleration), the panel becomes clear. > In any case we'd be doing great to come up with something as nice > and usable as the Fly! cockpits. Artistically, I agree -- they're beautifully rendered and pay a lot of attention to detail. From a modelling perspective, however, they're years out of date, and I think we should aim a lot higher than fixed 2D renditions. Try the Battle of Britain demo to see what a 3D cockpit is like, and you won't want to go back. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Jim Wilson writes: > At first look this doesn't seem all that bad. The hardest part is > going to be cleaning up the hard coded bits out there. Here are most of the required outputs, from an analysis I did earlier: - the VIEW matrix, a matrix containing the transformations to put the view in the correct position and orientation (as as the argument to ssgSetCamera) - the UP matrix, rotation matrix to the current notion of up (opposite of gravity) - the current absolute view position in fgfs coordinates - the current view position in fgfs coordinates, relative to the scenery center - the world-up vector - the surface-east vector - the surface-south vector All of the others are byproducts of the VIEW calculation, used for convenience by various bits of the code. > The routines basically all produce > the same thing with different methods which helps. Right now what I need to > do is map out all the calculations that are being applied and will come up > with a proposal to post here. But it should be too bad once I get my head > around the whole thing. Basically what I'm going to look at is modularizing > the calculation for each matrix component (camera, center, up) so that new > methods like some of what Michael described can be easily added. Yes, I've been playing with some of that myself. You'll see that I've already moved some of the common code into the temporary FGViewPoint class -- it gets as far as calculating the absolute and relative view position and the world-up vector. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim Brennan jjb - writes: > OK, I'll grant you the validity of those two points. > > > the propeller from inside the airplane. > > > but not that one ! To start a DC-3 engine, I read that you count 12 blades before you release the starter. I'm not sure whether, in an engine-out on a twin, you're supposed to try to get visual confirmation of which prop is spinning more slowly. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: first experimental 3-D cockpit
Consider this pre-alpha -- I glued together a bunch of existing stuff to mock up a sort-of functional 3D cockpit for the Cessna 172. You can try it out with fgfs --aircraft=c172-3d There are some important caveats: 1. Clicking on the instruments doesn't work (waiting for a fix from Andy). 2. The instruments rotate with the 3D cockpit but they don't tilt with it (also waiting for a fix from Andy) -- that means that you can move the mouse sideways, but try not to move it up or down unless you want to see the magic floating gauges. 3. The orientation is incorrect when the view is not straight forward and the plane is not flying level (waiting for a fix from me, but I don't understand matrix math well enough) -- that means that when you look out the side window during a climb or turn, the model will not be tilted correctly. 4. The 3D interior is fairly ugly right now. 5. This isn't *really* how we'll want to code it -- we'll want to draw the gauges in the same scene graph as the 3D model (it's all just a kludge right now). Still, there is enough here to give a feel for what it will be like flying FlightGear with a proper 3-D cockpit. I recommend using it with the joystick in your left hand and the mouse, in view-mode, in your right hand -- that way, you can look any way you want quickly while you're flying. That doesn't work for people like me with two-handed gamepad controllers, but that's life. People with rudder pedals will be very happy with their purchases now. A lot of the credit for this (the good parts) goes to Andy Ross for making the virtual-panel patches. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Tony Peden writes: > In a twin, you'll definitely know which engine is out without > looking. I've read several accident reports where the wrong engine was feathered and shut down. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ANN: first experimental 3-D cockpit
David Megginson writes:
> 3. The orientation is incorrect when the view is not straight forward
> and the plane is not flying level (waiting for a fix from me, but I
> don't understand matrix math well enough) -- that means that when you
> look out the side window during a climb or turn, the model will not be
> tilted correctly.
Further to this point, could someone who understands matrix math take
a look at src/Main/model.cxx, in the update() method? Where I have
if (view_number == 0) {
// FIXME: orientation is not applied
// correctly when view is not forward
sgMakeRotMat4( sgROT, -pilot_view->get_view_offset()
* SGD_RADIANS_TO_DEGREES, pilot_view->get_world_up() );
sgPreMultMat4( sgTRANS, sgROT );
}
I'm trying to keep the model from following the view around.
Obviously, I have to do some rotations in other planes as well, but
I'm not quite sure how to do it.
Thanks, and all the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes:
> I have some experience with Tkinter. but my GUIs tend to be a bit
> "functional" (OK, ugly), and I will be learning XML at the same
> time. Any, and all, help will be greatly appreciated.
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have
you), you're most of the way there.
Think of an XML document as a single toplevel LISP list containing any
number of nested sublists. The top-level list and every sublist are
called 'elements' in XML, and each starts with and ends with
, where NAME represents the name of the element. So, what you
might represent in LISP as
('person ('name "David Megginson") ('citizenship "Canadian"))
you can represent in XML as
David Megginson
Canadian
An element name must begin with an alpha or '_', and may contain only
alphabetic characters (actually, most Unicode ones, including Chinese,
Arabic, etc.), numerals, '_', '-', or '.'. Technically, they can also
include ':', but that can cause conflicts and should be avoided.
The text inside an element can contain pretty-much all printing
characters, but '&' and '<' (and sometimes '>') must be escaped, like
this:
& = &
< = <
> = >
So in XML text, for "a < b && c > d", you'd have
a < b && c > d
It's a bit ugly, but it works.
Comments in XML start with ; they may not contain
the string "--" in-between.
You can attach variables, called 'attributes', to each element by
putting a name=value pair in the start tag, like this:
http://www.flightgear.org/";>FlightGear
The attribute name is "href" (follows the same rules as element
names), and the value is "http://www.flightgear.org/";. The value must
always be quoted with "..." or '..', and in addition to the special
character escapes I mentioned above, you can also use the following:
' '
" "
To encode
He said "it's best to buy AT&T"
in an attribute value, you'd do something like
or
How elements and attributes are interpreted is almost entirely up to
the application -- XML says how to encode data, but not what the data
means or how it should be processed. In the property manager, we've
decided to treat the XML document like a file system: the root element
("PropertyList") is the filesystem root, and everything else is a
subdirectory or a file (leaf data).
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jim Wilson writes: > Hehe. Yep. Didn't notice that one. Actually I don't know why > that would be in the preferences.xml. Anyone know why that isn't > in the panel or at least aircraft-set xmls? A cleanup and reorg is long overdue; same for keyboard mappings. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Wolfram Kuss writes: > The XML files get IMVHO more and more confusing. I think that it would be more accurate to say that FlightGear is getting more sophisticated -- there's more to learn if you want to customize things, but that's only because there's so much more that you can customize. The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, since it allows some common structure and reusable code among all the formats. Imagine if we had one file format for preferences, a different one for panels (say, with fixed-length fields), a different one for saving a flight (perhaps a binary format), another one for sound configuration (perhaps an INI file), a different one for top-level aircraft configuration (perhaps CSV), yet another one for configuring 3D models (perhaps embedded data strings in the 3D files themselves), etc. etc. > I saw that for example the spelling of z-offset changed twice and I > was told to use a third spelling. Also, it is not clear to me, what > the different xmls are for (what does -dpm, -set etc mean? "set" as > in set options? Don't all xmls set options?) and whether you can > use all properties in all XMLs and whether you can use all on the > command line. Yes, we're still in early days with some of this. Again, these are config files for totally different purposes, and the fact that they all use XML is simply a convenience for programmers and customizers. Here are some of the conventions that we've come up with so far, partly ad-hoc (all paths relative to $FG_ROOT): preferences.xml- the top-level default preferences joysticks.xml - default joystick bindings, included by preferences.xml keyboard.xml - default keyboard bindings, included by preferences.xml Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in preferences.xml (and joystick/keyboard.xml) As far as I can recall, these are the *only* files in the base package that affect FlightGear's main property tree. Other files use the property-file format for convenience to populate various data structures, but they do not touch the main tree and are not accessible through the property browser or through the command-line --prop: option; it's just a coincidence that they also use the property-list format: materials.xml - define the materials (textures, colour, lighting) for use in the scenery HUDS/**/*.xml - configuration files to define the various heads-up displays Aircraft/*/*-sound.xml - configuration files to define sounds played for various aircraft Aircraft/*/Panels/*-panel.xml - configuration files to define 2D panels for various aircraft. Aircraft/*/Instruments/*.xml - configuration files for individual instruments included by the 2D panels. Aircraft/Instruments/*.xml - ditto We also use some XML-based formats that do not (yet?) follow the property-list conventions, including the following: Aircraft/*/*.xml- JSBSim aero model config files Aircraft/Aircraft-yasim/*.xml - YASim aero model config files Engine/*.xml- JSBSim engine and thruster config files > So, a UI that showed you what you can do would be very nice. Agreed. Since the property-list format is used by most of the config files, it will be a relatively easy job to write a generic browser for all of those formats (like the property browser inside FlightGear). Then all you need is a simple schema format (which can also be property-list-based) to say what is and isn't allowed in each format, and the UI will be dynamically reconfigurable. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] keyboard.xml
Richard Bytheway writes: > I was having a fiddle with keyboard.xml to support a UK keyboard, and > discovered that the characters £ and ¬ (which are shift-3 and shift- to left of 1>) break the XML parser. Is this intentional? By default 8-bit XML files use Unicode UTF-8 encoding. That's the same as ASCII up to 127, but then it uses 2-, 3-, and 4-byte escape sequences to model over 60,000 more characters. For your problem, there are a couple of solutions. The easiest one might be just to declare the encoding you're using, such as ISO 8859-1 (Latin 1): This is *not* guaranteed to be portable to all XML parsers -- some might not support 8859-1 (though most do). It will also screw anyone who wants to bind, say, Han characters from a Chinese keyboard. Another alternative is to use character entities, similar to \0nnn sequences in C strings. The Sterling character is (I think) 163 in both Latin 1 and Unicode, so you can use Here is a £ sign. and when the XML document is displayed or processed, you should see Here is a £ sign. I don't remember what the value for Euro is. The final, and most elegant solution, is to configure your text or XML editor to load and save in UTF-8 format. I think you can do that with Emacs+Mule, though I haven't tried it. Note that most control characters cannot be included in XML documents at all, even with character references, no matter what the encoding. It's OK to include tab, space, newline, and carriage return, but ^L (for example) will always cause a parsing error. > Also, in the grand re-organisation of the XML files that appears to be > planned, do we need to consider a better way to handle non-US keyboard > layouts? UK is not too different, only the punctuation is rearranged, > but other european layouts move the letters around as well. What we need to do is have FlightGear read a local config file in a user directory after reading the defaults from $FG_ROOT. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Cameron Moore writes: > [ Why doesn't Tarzan have a beard? ] Jane, n'est-ce pas? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Martin Dressler writes: > There are some diferents how the viewer is initialized and from > where it take new position. Your viewpoint could be static or > change position or (and) up vector in some dependency on FDM or > maybe time. Right, but none of that's the viewer's concern. As long as something (probably the view manager) tells each viewer every frame what the location(s), orientation(s), and offset(s) are, the viewer doesn't have to know anything else -- it can calculate all of its matrices and vectors from that. > IMHO the view also should control if panel, hud or virtual cockpit > is used. and if it preserve state if you switch to another view > and then return back. I disagree -- the view code gets *very* hard to understand very easily. If that information is tracked, it should be tracked externally (the view manager, again?) and not in the viewer code itself. The viewer code has to do some very complicated matrix and vector math, and if we have any hope of being able to maintain the code in the future, we need to keep it as simple as possible. The best arrangement I can think of is isolating all of the actual view transformation code in the viewer class, and all of the FlightGear-related stuff in the view manager class. That way, person A who knows nothing about matrix math can design new views, etc., and person B who knows little about the rest of FlightGear, properties, etc. can optimize the matrix math, etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Wolfram Kuss writes: > BTW, in your list you forgot the *-dpm.xml files, which are of most > interest to me and which are currently the only ones that I really use > :-). With the little time I currently have, I am glad if I manage to > have a nice 3D model at the correct place in fgfs. Ah, yes -- a file with the same name as a 3D model and the XML extension is a wrapper file for the 3D model containing animation and placement information. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: Property Logging
FlightGear now has the ability to produce multiple logs, each recording the value of user-selected properties at a user-defined interval. Details are available in docs-mini/README.logging; Here's a simple example that logs the rudder and aileron positions to steering.csv every second or so: steering.csv 1000 Rudder /controls/rudder Ailerons /controls/aileron Here's some sample output: Time,Rudder,Ailerons 6522,0.00,0.00 7668,-0.00,0.00 8702,-0.00,0.00 9705,-0.00,0.00 10784,-0.00,0.00 11792,-0.00,0.00 12808,-0.00,-0.21 13826,-0.00,-0.344000 14881,-0.00,-0.066000 15901,-0.00,-0.806000 16943,-0.00,-0.936000 17965,-0.00,-0.534000 19013,-0.00,-0.294000 20044,-0.00,0.27 21090,-0.00,-1.00 22097,-0.00,-0.168000 All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Compile failure of latest CVS
D Luff writes: > Cygwin compile of latest CVS fails in logger.cxx, complaining that > an integer constant is out of range in line 101: > > last_time_ms(-99L) Apologies -- I'll shrink that. I *think* it's in range for a signed 64-bit integer, but I'm too lazy to check. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
Jon S Berndt writes: > I like this new capability. I ought to be able to plot the > logged data out of the box with my simplot program. As for > some other formats, I wonder if someone might provide a > couple of perl scripts to do conversions rather than place > that burden on FlightGear. It's easy enough to make the delimiter user-selectable; beyond that, I agree that we shouldn't make the logger complicated. In particular, I'm not escaping any delimiters that appear in property values, to avoid too much processing overhead (and because I'm lazy). JSBSim and YASim may choose to expose more of their internals though the property tree now, so that they can be logged (especially YASim, which doesn't already have its own logging feature). I think that the internals should be partitioned by FDM, since each FDM does things its own way; for example, JSBSim could use /fdm/jsbsim/ and YASim could use /fdm/yasim/ as roots, then use whatever properties and formats they want; for example, JSBSim might expose coefficients, while YASim has none to expose. No negotiation require -- do your own things, guys. Perhaps later we might think of common properties for very common stuff like forces and moments. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hack for Virtual cockpit problem
Jim Wilson writes: > This seems to pretty much correct the problem. Part of the problem > is that rotations are occuring at the firewall (model origin) which > seems a little un-natural inside the cockpit. The rest of the > problem is I am just learning how this stuff works (I know I've > been saying this for a couple months now...but hey I'm slow :-)). Thanks -- the internal cockpit view seems much better. Now the ball's in Andy's court to patch up the virtual panel code (and de-quat the mouse code), and we're flying! All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hack for Virtual cockpit problem
Jim Wilson writes: > It's still a little weird with a steep roll angle. Found an > article on quarternions. It seems that they can be used to solve > the problem of the rotation being off center. Actually what we need to know is the center of gravity (CG) for each plane, or maybe the aero reference point -- I'm not sure which. The FDMs already know this: if they could publish the offset, in meters, from each plane's the reference point, we could use that to get the center point for all rotations. For example, as you mentioned earlier, the reference point for a Cessna 172 is on the floor right by the firewall (i.e. behind the rudder pedals). The centre of gravity, according to the JSBSim config file, is 41.0 inches back and 36.5 inches up from that. We could hardcode it for each model, but I think getting the value from the FDM is better: the CG can move around, depending on how the plane is loaded, and eventually the FDMs will model that movement. For example, if I've been draining all my fuel from the left wing tank so that it's empty and the right wing tank is full, my CG is no longer going to be right on the Y-axis. FDM guys? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine writes: > David Megginson writes: > > >(and de-quat the mouse code) > > exactly the kind of response that led me to coin the phrase > > "MAYDAY MAYDAY FlightGear has been hijacked" Actually, that was Andy's idea, but I do agree with it entirely. I'm not saying to de-quat FlightGear, just to get the code out of the mouse routines and into the viewer, where it belongs. We need to be able to rotate the view with the keyboard or joystick (for example) as well as the mouse, and that's impractical if some of the code is hardwired to one input device and cannot be reused. I don't much care if the new viewer code ends up using quaternions or regular matrices, as long as it works. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine writes: > Well the Mouse code certainly could but let's leave that alone > as I REALLY don't want the Mouse reading properties :-) Not read them, but set them. It wouldn't much matter if the mouse code called globals->get_current_view()->set_orientation_offsets(r, p, h); or view_roll_node->setDoubleValue(r); view_pitch_node->setDoubleValue(p); view_heading_node->setDoubleValue(h); as long as the values ended up back in the viewer *and* the property tree somehow. In either case, though, I think that we need to throw out our current view_offset and view_tilt (the latter is my own evil creation) and replace them with full 6-DOF view offsets: - x (meters) - y (meters) - z (meters) - roll (degrees) - pitch (degrees) - heading (degrees) These would allow the view to move around inside and outside the 3D model in any way -- for example, the pilot could sit higher or lower in the seat, walk back through the cabin, or stick her head out the window to see where she's taxiing in a taildragger. On a separate note, some day we'll get around to making the mouse bindings user-configurable, like the joystick and keyboard bindings. I have received many e-mails asking why we haven't done that already. When that happens, properties are going to be hard to avoid. > Good enough to get you and many others hooked on FGFS :-) Absolutely. It works well and efficiently, and has served the project very, very well; the only problem is that we cannot easily extend it as FlightGear becomes more sophisticated. We all owe Norm an enormous debt of gratitude for getting all this stuff working in the program's early days, or there would have been no program for us to work on now. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine writes: > Well the Mouse code certainly could but let's leave that alone > as I REALLY don't want the Mouse reading properties :-) Not read them, but set them. It wouldn't much matter if the mouse code called globals->get_current_view()->set_orientation_offsets(r, p, h); or view_roll_node->setDoubleValue(r); view_pitch_node->setDoubleValue(p); view_heading_node->setDoubleValue(h); as long as the values ended up back in the viewer *and* the property tree somehow. In either case, though, I think that we need to throw out our current view_offset and view_tilt (the latter is my own evil creation) and replace them with full 6-DOF view offsets: - x (meters) - y (meters) - z (meters) - roll (degrees) - pitch (degrees) - heading (degrees) These would allow the view to move around inside and outside the 3D model in any way -- for example, the pilot could sit higher or lower in the seat, walk back through the cabin, or stick her head out the window to see where she's taxiing in a taildragger. On a separate note, some day we'll get around to making the mouse bindings user-configurable, like the joystick and keyboard bindings. I have received many e-mails asking why we haven't done that already. When that happens, properties are going to be hard to avoid. > Good enough to get you and many others hooked on FGFS :-) Absolutely. It works well and efficiently, and has served the project very, very well; the only problem is that we cannot easily extend it as FlightGear becomes more sophisticated. We all owe Norm an enormous debt of gratitude for getting all this stuff working in the program's early days, or there would have been no program for us to work on now. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Douglas DC-3 Dakota
Danie Heath writes: > I work part-time at the South African Air Force Museum, and, seeing > as we operate two DC-3's, I can get you any information you need. > Tell me what you need, and I can get it. Thank you again for the offer. Here's my own wish list: 1. Aerodynamic coefficients You probably won't be able to find these anywhere, unless your airforce once did wind-tunnel tests on a DC-3/Dakota, but these are what JSBSim needs to model a DC-3 correctly. There will be a lot of numbers or tables with headings like CLo, CLa, CDo, etc. (or maybe CX*). I saw a story that someone once requested this data from Douglas, and an old engineer at Douglas replied that the DC-3 was invented before aerodynamic coefficients were (I doubt it, but it makes a good story all the same). 2. Raw flight data It is also possible that someone has collected in-flight data from a Dakota, and we might be able to use that to calculate some of the coefficients: for example, there might be tables of the engine power required to maintain altitude at different angles of attack, or the climb or descent rate at different power settings and altitudes, etc. 3. The DC-3 Pilot Operating Handbook In an ideal world, a PDF of the whole POH would be very useful to everyone working on the DC-3, but in reality, copies of the power tables alone would make a big difference to our modelling efforts. 4. Wright Cyclone Engine Data Any engine performance or maintenance data for the Wright Cyclone (or whatever the later DC-3 engine was) would of course be very helpful. 5. Interior and exterior 3-views I have some low-res 3-views of the DC-3, but any more detailed drawings would be helpful, especially for the 3-D model. Detailed drawings of the cockpit and control panel would be great for the panel designers. 6. Pictures Lots of digital pictures of details, especially the cockpit interior, would be very nice. 7. Any unexpected surprises You'll probably find things we didn't even think of; please let us know. In addition to all of the dry archival work, you are more than welcome to load my DC-3 3-D model into Blender or another modeller and fix it up, especially if you have access to any real DC-3s/Dakotas for comparison -- let me know if you'd like the latest version. Thank you again, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Simplifying the Property Code
After a year and a half (really!), it's becoming clear how people are and are not using the property code, and I think that a big simplification is in order. As far as I can tell, nearly everyone either (a) leaves the property values in the tree, or (b) ties them to object methods I made the property manager flexible enough that you could provide any back-end retrieval by implementing, and provided default SGRawValue implementations for internal values, variable pointers, static functions, and object methods. I think that I'm the only one using variable pointers (panel.cxx) static functions (fg_props.cxx), and no one else has ever created a new SGRawValue type, so I obviously overdesigned the code a bit. If I remove SGRawValue completely and leave only internal values and tied object methods, the property code will become simpler and will lose a couple of levels of indirection. This will matter if the C++ code ever runs slower than the framerate (i.e. if 200fps video cards become common). Comments? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine writes: > > globals->get_current_view()->set_orientation_offsets(r, p, h); > > > >or > > > > view_roll_node->setDoubleValue(r); > > view_pitch_node->setDoubleValue(p); > > view_heading_node->setDoubleValue(h);> > > Here is where I say you are WAY over enamoured with your 'properties' It might help, then, if you ignore the second example and concentrate on the first: image that we did not have properties at all in FlightGear. The issue is code design -- the view code needs to be fully decoupled from the input code (whether keyboard, mouse, joystick, network, or some other source) so that we can reuse it cleanly, which we cannot do right now. As long as some of the view calculation is performed inside the mouse code, that code will have to be duplicated for other input methods that can change the view code. Even more seriously, it will be difficult for other subsystems (such as the 3D model) to determine exactly how the view has changed. > IMHO Since the properties can read/set a matrix directly all that > is needed are these values stored in a 'globally available place' > so that the property manager and its ilk can access them when they > want to. But the internal vector math operators can operate > unhindered by reading the values directly. We're not talking about internal vector math, we're talking about how input values get from the mouse to the view code -- that's fundamentally an interface problem, not a mathematical one. Andy, Jim, and I have all suggested that we need a generic interface to represent the view orientation offsets, and that all input should go through that interface. We want to be able to say that the user has requested something like roll offset is 5 degrees heading offset is 10 degrees pitch offset is 0 degrees and have that work the same way, no matter where the numbers are coming from. The mouse code can use the mouse position to calculate the user-requested offsets then pass them on to the viewer code, and the viewer code can use matrices or quaternions internally for its calculations. > Also I believe that all of the what was Viewer_RPH ie the World Positioning > code without any 'eye' or other 'local orientations applied' should be moved > out of FlightGear and into SimGear making this distinction even clearer. Yes, there's a lot that we should move out into SimGear. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine writes: > However I STRONGLY suggest that the first pass is written in > 'pseudo code' and posted to the Net somewhere for Review and > Comment before anything is actually implemented. > > A Wiki would be ideal for this kind of thing :-) CVS is good for this kind of thing as well. If Jim is having trouble writing the code and needs some help or guidance, of course he is welcome to post pseudo-code, but with CVS, it's normally better just to check in the changes -- that way everyone can review them and test them. If they don't work, we can just roll them back out again (as we have a few times in the last couple of months). We might be approaching a point that we'll need separate stable and development CVS branches. The stable branch should have bug-fixes only, while the development branch can have bleeding-edge new code for people to try out and review. The question is whether Curt's willing to put up with the extra headache of maintaining two branches, and whether people are willing to submit two sets of any bug-fix patches (I'd guess yes for the latter, at least). Of course, that also implies keeping two branches of the base package. Ouch. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Jim Wilson writes: > What I was volunteering for was something less ambitious. > Basically just merging the pilot and lookat viewers, looking at the > outputs and combining the ones that are essentially the same kinds > of values, and mostly preserving how things work now. I think that's an excellent start. The pilot and look-at viewers contain a very large amount of code repetition, and a merger would give us a good starting point either for later cleanups or for a later rewrite. Another good strategy would be to remove every getter and setter from viewer.hxx that's not currently used so that we know what we actually have to support. I'll look forward to seeing the patch. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Douglas DC-3 Dakota
John Check writes: > It doesn't have everything you need but incase you haven't seen it: > http:www.douglasdc3.com Yes, it's an excellent source for photos and low-res technical drawings. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinates fact check
Andy Ross writes: > The scenery center is set out of the main loop, and looks to me > like it can be easily replaced with the eyepoint with no loss of > function. This has two nice side effects: the view matrix > generation is no longer dependant on data stored in scenery tiles, > and the code to calculate the scenery center for each tile can > simply go away. That sounds like an excellent idea. Are there any hidden gotchas? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A viewer interface suggestion
As I promised to Norm earlier, here's how I think the interface for
the new viewer module should look. The viewer would be configurable
for three situations:
1. looking from a known position outwards
2. looking at a known position from an offset
3. looking at one known position from another
The main input vectors are as follow:
- geodetic position of viewer (used by 1 and 3)
- geodetic position of target (used by 2 and 3)
- Euler angles for viewer orientation (used by 1, 2, and 3)
- position offsets (distance from viewpoint in 1 and 3 and from target
in 2)
- Euler angle offsets (used by 1, 2, and 3)
Undoubtedly, I've confused or missed something. Code speaks louder
than words, so here's a hack-up of the interface:
class FGViewer : public FGSubsystem
{
public:
enum Type {
FROM_POINT,
TO_POINT,
POINT_TO_POINT
};
FGViewer ();
virtual ~FGViewer ();
//
// Part 1: standard FGSubsystem implementation.
//
virtual void init ();
virtual void bind ();
virtual void unbind ();
virtual void update (int dt);
//
// Part 2: user settings.
//
virtual Type getType () const;
virtual void setType (Type type);
// Reference geodetic position
virtual double getLongitude_deg () const;
virtual double getLatitude_deg () const;
virtual double getAltitude_ft () const;
virtual void setLongitude_deg (double lon);
virtual void setLatitude_deg (double lat);
virtual void setAltitude_ft (double alt);
virtual void setPosition (double lon, double lat, double alt);
// Reference geodetic target position
virtual double getTargetLongitude_deg () const;
virtual double getTargetLatitude_deg () const;
virtual double getTargetAltitude_ft () const;
virtual void setTargetLongitude_deg (double lon);
virtual void setTargetLatitude_deg (double lat);
virtual void setTargetAltitude_ft (double alt);
virtual void setTargetPosition (double lon, double lat, double alt);
// Reference orientation
virtual double getRoll_deg () const;
virtual double getPitch_deg () const;
virtual double getHeading_deg () const;
virtual void setRoll_deg (double roll);
virtual void setPitch_deg (double pitch);
virtual void setHeading_deg (double heading);
virtual void setOrientation (double roll, double pitch, double heading);
// Position offsets from reference
// (axes rotated by ref orientation)
virtual double getXOffset_m () const;
virtual double getYOffset_m () const;
virtual double getZOffset_m () const;
virtual void setXOffset_m (x_offset);
virtual void setYOffset_m (y_offset);
virtual void setZOffset_m (z_offset);
virtual void setPositionOffsets (double x_offset,
double y_offset,
double z_offset);
// Orientation offsets from reference
virtual double getRollOffset_deg () const;
virtual double getPitchOffset_deg () const;
virtual double getHeadingOffset_deg () const;
virtual void setRollOffset_deg (double roll_offset);
virtual void setPitchOffset_deg (double pitch_offset);
virtual void setHeadingOffset_deg (double heading_offset);
virtual void setOrientationOffsets (double roll_offset,
double pitch_offset,
double heading_offset);
//
// Part 3: output vectors and matrices in FlightGear coordinates.
//
// Vectors and positions
virtual const float * get_view_pos () const;
virtual const float * get_absolute_view_pos () const;
virtual const float * get_zero_elev () const;
virtual const float * get_world_up () const;
virtual const float * get_surface_east () const;
virtual const float * get_surface_south () const;
// Matrices
virtual const sgVec4 * get_VIEW () const;
virtual const sgVec4 * get_VIEW_ROT () const;
virtual const sgVec4 * get_UP () const;
private:
// whatever we decide to put here
};
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A viewer interface suggestion
Curtis L. Olson writes: > - we have a pilot view point offset from the CG. Right now this is > handled in the view code, but perhaps this would make more sense to > move to some code specific to the instance of the current > aircraft. Perhaps, but that will require other modules to do matrix manipulations, because the offset is relative to the rotated axes, not the world-up axes. > For internal views, a heading and pitch offset to the view makes > sense. And roll, for that matter -- I don't see any good reason to leave out one degree of freedom. Think of a tail-gunner view in a bomber for one example of where we might want a roll offset. > For external views, we shouldn't use this heading/pitch offset and we > should manage the actual view point as offset from the aircraft CG > somewhere else and just feed the view code an eye point and a "lookat" > vector. If we use a pitch/heading offset for the external view, it > should pitch/yaw the view away from the aircraft in the center of the > screen. Exactly. Most of the code will still be the same, so I think that it makes sense to handle this all in one configurable viewer. > The 'position offset' to me seems to make more sense living elsewhere > (although we may not have a more appropriate place for it at the > moment.) But remember that the offset is, again, in the rotated axes, not the world-up ones. It makes sense to centralize the 3D math in the viewer class and not spread it around. The logic for calculating the position offsets may live elsewhere, of course, but it makes sense to let the viewer calculate the actual transformation from the reference geodetic position, since it will already have rotation and transformation matrices set up. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A viewer interface suggestion
Andy Ross writes: > This looks really good to me. Thanks. > A few nits below, based on the way I think about the problem. > > David Megginson wrote: > > 1. looking from a known position outwards > > 2. looking at a known position from an offset > > 3. looking at one known position from another > > Heh, cockpit, chase and tower. I wasn't thinking generally enough. :) It's not quite that simple. #3 could also be from another moving vehicle (perhaps being flown by another user over the network or by AI code). From the viewer's perspective, it won't matter whether it's a tower or a moving vehicle when the position is reset every frame anyway. > > // Vectors and positions > > virtual const float * get_view_pos () const; > > virtual const float * get_absolute_view_pos () const; > > virtual const float * get_zero_elev () const; > > virtual const float * get_world_up () const; > > virtual const float * get_surface_east () const; > > virtual const float * get_surface_south () const; > > It's probably a good idea to specify the coordinate system for each of > these in the name. Yes, I agree. I just stole these names from the existing viewer.hxx, and have no attachment to them. Perhaps something like getRelativeViewPos_m () getAbsoluteViewPos_m () etc. would be more appropriate. > I'd also suggest putting stuff like the surface directions somewhere > else. These are properties of a location, strictly, not a view. That's also a good idea. Right now, I'm using a temporary SGViewPoint class to hold location information -- perhaps we should make something like it permanent. > Nit: those should be sgMat4's, right? Or are you returning a pointer > to an array of four vectors? Returning sgMat4's seems to cause compiler problems, and this is how Norm had it before. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A viewer interface suggestion
Andy Ross writes: > Why not use an "output" parameter then: > >void getWhateverMatrix(sgMat4* out); > > Returning a bunch of vectors seems kinda hackish. That sounds great to me. As I mentioned before, I just copied over what's there now for the vectors and matrices. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Cockpit, cont'd
Jim Wilson writes: > Nice seats too :-) I'm probably not going to be able to get away with such low poly counts for the interior for long, but I don't want to fork the models quite yet. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
Danie Heath writes: > Just a question. If I create a 3-d model in GMAX, convert it into a .MDL > file for FS2K2, is there a way to get it (as well as detail things like > rotating wheels, moving control surfaces) into Flightgear ? Yes. There's a bit of magic involved in getting the animations working, but we can help you with that. If you'd be willing to release your model under and open-source license (or Public Domain) we can include it right in the base package, and if it's better than my DC-3 model (no big challenge there) we can make it the default. Note that we're starting to model interior as well as exterior views of 3-D models. There's not much, yet, but you might want to keep that in mind. The most important thing, under all circumstances, is to keep the polygon count low. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A viewer interface suggestion
Andy Ross writes: > Or a full-on 3D version of your jitter code, where the pilot's head > tilts to the side due to sudden side forces. :) Yes, I liked that a lot in Battle of Britain. A bit of blurring at high G (or even a red-out) would be nice too, but we can do that in the future. > This is actually something I want to try once the cockpit stuff > stabilizes. The ability to bounce the viewpoint around (in > turbulence, on touchdown) just too cool. In a 3D cockpit, you can > actually watch the aircraft twist around you during yaw oscillations. > The pilots head could lag changes in the aircraft orientation a little > bit... That's important. From what I've read, pilots can feel when they're in uncoordinated flight -- they don't usually have to watch the ball much once they have some flying experience. Moving the head a bit gives some useful sensory feedback for computer users (Alex has also suggested some audio feedback from the propeller). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
David Megginson writes: > Danie Heath writes: > > > Just a question. If I create a 3-d model in GMAX, convert it into a .MDL > > file for FS2K2, is there a way to get it (as well as detail things like > > rotating wheels, moving control surfaces) into Flightgear ? > > Yes. Or no, according to Wolfram. I get confused about what MDL formats plib does and does not support. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_props.cxx,1.49,1.50
Tony Peden writes: > > Restoring a flight is not > > working in a running FlightGear session because of > > JSBSim trim-routine > > problems, > > What is it doing (or not, as the case may be)? It's not setting body velocities from the save file, even when I set /sim/startup/trim and /sim/startup/onground to false first. I'm experimenting with different combinations to see what I can get. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Model Performance and dc3 donuts
Arnt Karlsen writes: > ...2 proportional joysticks, just like a model airplane radio > control transmitter?? I'm not sure what you mean by proportional, but they look exactly like regular joysticks to Linux. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Cockpit, cont'd
Andy Ross writes: > Apropos of this stuff, David, you might want to look at panel.cxx and > investigate parameterizing the panel location. Right now, the panel > is drawn "in front" of the viewer, with the top edge six degrees down > from the center of the view and subtending 60 degrees of arc from side > to side. This is fine, as far as it goes, but the real design allows > for plastering the panel into 3D space by defining three corner > points. I'd be thrilled for someone to take over the 2D panel code. I think that the future lies with the 3D cockpit, and I'm thinking of ways to carry most of the current panel work over -- we should be able to keep the current instrument XML files (which represent 99% of the work invested) and project each instrument individually into 3D space. I'm not promising this next week or even next month (or next quarter, for that matter), but we will need to be able to have different instruments lying on different planes (i.e. the overhead panel, the door panels, the center pedestal, etc.). For bigger things, like throttles and yokes, we'll probably use animated 3D objects. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Tony Peden writes: > You need to write the data to the appropriate properties. You might > take a look at JSBSim.[ch]xx and what we're doing with the > /surface-positions/elevator-pos-norm > /surface-positions/rudder-pos-norm > etc. For LaRCSim, I just added code to copy the control inputs directly to these properties. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
Marcio Shimoda writes: > Well, this is a problem > The current version of ssgLoadMDL just loads the all the information in mdl > file. It doesn't know what is loading, if is a wheel or other moving part. Fortunately, that doesn't matter. We specify animations externally using an XML config file; see http://www.flightgear.org/Docs/fgfs-model-howto.html for details. As long as ssgLoadMDL preserves object names inside the model, we should be able to animate it. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Erik Hofman writes: > To get it working the UIUC code should populate the property tree with > at least the following properties (for a piston engine driven aeroplane): > > > starting/stoping the sounds: > --- > /engines/engine/cranking > /engines/engine/running > /gear/gear[]/wow > /surface-positions/flap-pos-norm > /sim/aero/alarms/stall-warning Since UIUC doesn't have any engine start-up code or stall-detection code, it's probably good enough just to set /engines/engine[0]/running to true (repeat for additional engines), and to copy the value of the flap control directly to /surface/positions/flap-pos-norm. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
Per Liedman writes: > MDL is not a format used for modellers, it's more like > a "compiled" binary format used for MSFS. This means that > it *does not* contain object names. Hence, ssgLoadMDL does > not "preserve" object names, since there are no names to > preserve. :-) > > Having said that, ssgLoadMDL *does* know of some special > types of objects in the MDL format (such as gear, flaps, > spoilers, rudder, elevator, ailerons) and names the branch > nodes appropriately when it finds these nodes. > Unfortunately, the detection mechanism might be highly > dependant on which version of MSFS the model was designed > for, so I don't know how well it will work with models > exported from GMAX for MSFS 2002. Wolfram mentioned that GMAX-exported models don't work with PLIB anyway. In other cases, the best bet would probably be to load the model into PPE, name the appropriate objects, then export it to some other format for FlightGear to use. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ARGGHHH !
Norman Vine writes: > Note for the FDM writers This means that queries for multiple < 3 > or 4 > gear locations should be quicker then just the single query > was before That's good news -- I'd like to encourge the FDM writers to query separately for each gear now, at least for the wheels and skids (crash points aren't as serious). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Jon S Berndt writes: > So, when querying, would we supply the lat/lon/radius of > each bogey of interest, then get the height above ground? I think so. We might want to rewrite the interface so that you can supply offsets in meters, but that would require a bit of thought. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
Tony Peden writes: > So then, we'd need to convert from our body coordinates to FG's global > cartesian? You already have the absolute position, so you need only to add in the body coordinates rotated to the body axes, I think. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Jon S Berndt writes: > The best solution would be for the UIUC guys to bite the > bullet and port their work to use JSBSim. :-) :-) :-) Hmm -- today seems to be a big day for trolls. I wonder if any of Jon's NASA contacts are still waiting for him to bite the bullet and port JSBSim to FORTRAN. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Curtis L. Olson writes: > I'm just about to commit a massive series of changes that converts all > the .xml files to more standard .ini files. Oh, shoot, I meant to > save that announcement for 4/1/2002. :-) We have to coordinate better -- I'm just finishing switching them all to TeX. FlightTeX will be a new executable that both flies a plane and generates beautiful documentation simultaneously, but it will require us all to learn Pascal. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Jon S Berndt writes: > I wonder if modeling this as a pure aural cue would be > enough? Until Linux and PLIB support force-feedback controllers, it might be. For many surfaces, though, we will want the plane to bounce around visibly. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Tony Peden writes: > > And think carefully about the simplification you propose. Yes, it > > works in most case. But the existing code already works in most cases > > -- all of the situations where we can get away with a simplified > > per-gear model are *also* fine with the existing code. There's no > > point to doing the per-gear stuff if we're not going to see any > > benefit. > > A significant benefit will be had immediately -- the aircraft will > follow the terrain while taxiing and the 3D model will look better. Also, if we add the ability to get surface attributes, it will be obvious when one wheel slips off the side of the runway onto the grass or gravel. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
Marcio Shimoda writes: > Does anybody have a tutorial describing how to create the ac > models? You can create ac models with, AC3D (commercial), Blender (commercial but free [and now unsupported]), PPE (open source), or Innovation3D (open source); you'll need to pick your modeller than find tutorials specific to it. > I have to separate the animated parts of the model? Yes, they need to be separate, named objects. That's the only requirement. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Curtis L. Olson writes: > I had to copy sgdPointInTriangle() as well as one other routine from > the old hitlist.cxx to get things to compile. We made a decision a > while back that we wouldn't require a development version of plib, > but require only the most recent 'stable' version. So, these routines > need to be included. Can we #ifdef them in somehow? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
C. Hotchkiss writes: > Should we add good exception handling in the future, then throwing and > catching exceptions would make for a more robust way of dealing with a lot > of problems. And, it would probably be more informative. We have exception support and we use it, but there's a gotcha: exceptions don't survive passage through a C function, and we use C-based callbacks both through GLUT and through Expat. We'll have to make sure that we catch exceptions in every callback function and do something with them, so that they don't just crash the program. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re : DC-3 Info
Danie Heath writes: > FWIW, I'm leaving for the base now. I'll definitely see the groundcrew > today as we're expecting an aircraft to arrive this afternoon. Will try to > get the info, or at least make an appointment for a weekday (Thursday's a > public holiday in SA.). Thanks again -- any information will be enormously helpful. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Andy Ross writes: > I really don't subscribe to the "indirection above all" school of > software engineering, where the slightest hint that change might be > coming is enough to justify all sorts of contortions in the code. > Sometimes, simple things really should be left simple. Fair enough. I certainly overengineered props.[ch]xx, in anticipation of all kinds of sophisticated stuff that people never bothered doing. I've been learning, slowly, from the XP people to build only for today (all my training previously was to anticipate future needs, and it's hard to let that go). To rewind a bit, Andy rightly pointed out some of the problems with C++ exceptions, including the fact that they don't include stack traces and that people usually throw only strings. Granted, on both points, but exceptions still have the advantage that they can be caught at any arbitrary point up the stack and handled. For example, let's say that YASim fails to parse its XML config file. If it throws an exception, perhaps fg_init can catch that, display a warning dialog, and default to magic carpet mode. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Anyone recognize this problem?
William Earnest writes: > In file included from > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../. > ./include/g++-3/iostream.h:31, This doesn't look good -- somehow, include files from G++ 2.95.2 and G++ 3.0 seem to be getting mixed up. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Blinking model lights
Jim Wilson writes: > If I was going to add blinking lights to the model animation code, > how would I do the timing? This is still on my TODO list, together with LOD and other conditional hiding and showing. Were you thinking of blinking by swapping objects, or by changing colour/texture? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Redhat (vs debian) / BSD OK?
Greg Long writes: > My question is primarily this: Other that personal preference, is there > any major need to install Debian over RedHat Linux 7.2 for FlighGear > development? I notice the gcc issue in the FAQ, but I should be cool on > that with 7.2, though I'll check. I think that we have many RedHat users working with FlightGear, so there should be no problem. We'll convert you to Debian some other time. > I have a friend who might join in as well, and he has an OpenBSD setup. > If there are any known issues with FlightGear work on that platform > please advise. That's great -- I think we have very few OpenBSD users, and the more the merrier for hunting down bugs, etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] How to define a new airport
Sergio Roth writes: > I'd like to define a new airport. How can I do that ? Is there any paper > talking about it ? Is there any place where we can get coordinates of all > airports around the world ? The airports are defined in $FG_ROOT/Airports/default.apt.gz, but they don't appear on the fly -- you have to rebuild your scenery using TerraGear, and that's non-trivial. I'd like to add dynamic airport generation at some point in the future, but it's a big job. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Alex Perry writes: > > Fair enough. I certainly overengineered props.[ch]xx, in anticipation > > of all kinds of sophisticated stuff that people never bothered doing. > > I've been learning, slowly, from the XP people to build only for today > > (all my training previously was to anticipate future needs, and it's > > hard to let that go). > > It's nice to have a concept that can support all that stuff if/when we > have an excuse to make use of it. Put the methods and stuff into the > header file, with a comment that they are not implemented yet, and have > the implementations break if used. That makes it easier to have backward > compatible code when the snazzy features get added. Yes, except that I think we're paying a price with a couple of levels of unnecessary indirection and with code that no one but me can understand. I'd like to keep most of the user-level stuff intact, but to remove the developer-level stuff we're not actually using and reduce the number of layers. One thing that has impressed me about Andy Ross's code over most of the rest of FlightGear (including any of my own contributions that I haven't looked at for a few months) is that I was able to understand most of his code immediately. Part of that is because he uses good, clear design patterns, but a lot of it is because he is a good practitioner of worse-is-better: when in doubt seems to err on the side of leaving stuff out rather than putting it in. >From my experience both on open source and on large commercial projects, I've come to agree entirely with the XP people on certain points: 1. Never write code that you don't need right now, and never make a design more complicated than it needs to be for today. On average, it's cheaper to add one new feature later, when it's needed, than to waste time and obfuscate code by adding twenty new features now purely on spec. 2. Deleting code is as important as writing code. Never leave old code lying around. Instead of commenting or #ifdef'ing stuff out, delete it. If no one's using a particular class or method any more, delete it. If only a class or method is used in only a couple of places, try refactoring the code to use a different approach then delete the class or method. Curt and I disagree on the second point but try (most of the time) to respect each-other's opinions. Personally, I believe that (especially with CVS and ediff-revision in XEmacs for restoring old stuff) the cost of leaving in a lot of commented-out old code is painfully high -- it makes the code hard to understand and maintain, so people tend not to touch it until either something breaks or the whole development stalls. We have to try to write code that a new developer can understand the first time through, and that means keeping it short and simple and avoiding indirection and subclassing wherever possible (the last point shouldn't be controversial, since modern OO design frowns on excessive subclassing anyway). For the record, I don't agree with the XP people on team programming or the unimportance of documentation. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Norman's change and the PointInTriangle
Alex Perry writes: > Can we patch the sgdPointInTriangle back to PointInTriangle > _and_ keep the improvements from Norman in the tree ? I think we just need to #ifdef for the PLIB version. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] simple tower view
Michael Selig writes: > I am wondering does the view manager work-in-progress support a simple > tower view at this stage? Having gone from our non-CVS tower view in 0.7.8 > to a recent CVS checkout leaves me wishing for more. Jim Wilson is working on the rewrite. We do plan to support tower view (and other interesting views) very soon, but I don't know if it will be in the first take or not. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simple tower view
Michael Selig writes: > That would be nice, but even something simple that puts the viewpoint 200 > ft above the runway behind the aircraft would be great to start with. That > view is a help when building and testing the new aircraft models. It also > makes the sim well-primed for R/C use. We have a center lon/lat/alt for every airport. For small airports, unfortunately, that's often the runway center, but it should still be useful as a starting tower location until we have better data. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes: > I have made an attempt to describe the contents of 'preferences.xml.' > Could someone knowledgeable in the properties list and preferences.xml > file let me know if I am understanding things correctly? Also, is there > any information about what each component of FlightGear needs from the > property list (i.e., the various FDMs, etc.)? > > http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Just to start, the property tree has nothing to do with Metakit -- we use Metakit only to hold airport and navaid data. Aircraft/c172/Panels/c172-vfr-panel.xml This tells FlightGear where it can find the configuration information for the aircraft. It is the same as using the '--aircraft-dir=' option. Actually, this is the path to the default instrument panel. --aircraft-dir is a special option used only by UIUC. Thanks for starting on this -- it's much needed. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simple tower view
Erik Hofman writes: > Currently when looking around in the cockpit you turn around a > single point (if I recall it correctly). Wouldn't it be nessercary > to actually incoorporate the eye distance from the middle of the > head into that action (and limit the rotation to about 270 > degrees). It would seem more "natural" that way (for me at least > ;-)) With the viewer rewrite, we will be able to handle things like this (if we choose to) in the view manager rather than in the viewer itself. It's something to think about when our 3D models are better, etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Norman Vine writes: > but IMHO what is needed are "imposter tiles" > > "imposters" are where you use a 'texture only" substitute > for the geometry that are computed on the fly 'often enough' > This is 'radical' LOD but in our case the tiles out on the > boundary are really just 'little slivers' and there is no need for > anyting else. I would think that we could easily lump many > tiles together into these impostors to form a 2 level ring of > 'near' and 'far' "impostors" around our current scenery. Yes, I think that's a very good idea; in fact, if you wanted to go to three layers, the furthest one could be simply untextured, coloured polys (that's what you'd see from 120,000ft, for example). For each tile, we need to sample to find the commonest material and then use it for the texture (and/or colour) at load-time. Curt is worried about joining meshed tiles (with irregular terrain) to flat tiles, but I don't think that will be a big problem if the flat ones are far enough away. If we wanted to, we could also sample the elevation variation for each tile to help us decide how far away it should be drawn as a full mesh: flat tiles could go to a single poly much earlier than mountainous ones, for example. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Curtis L. Olson writes: > I know you are making a point by using extereme wording, but if you > are running through the woods, it doesn't hurt to look up once in a > while. I preached full interface design in advance through much of the 1990s -- it seemed like a good idea. I now freely renounce that view. Dead code is just too expensive to keep around; I'm willing to bet that FlightGear contributors spend more time trying to understand existing code (including mine) than writing new code. > Perhaps you misunderstand my position. It's one thing to delete > crufty old useless code. However, there may be reasons to keep old > code #ifdef'd in. This is where we disagree -- keeping it in makes the code much harder for new (and existing) contributors to read and understand, gives false hits when searching for variables and method calls, etc. etc. With CVS, it's trivially easy to look at or restore old code later if we need to; I'm strongly in favour of keeping the onscreen code short, clean, and uncluttered. Unlike the XP people, however, I am a big supporter of explanatory comments. There are parts of FlightGear that have a single, well-known maintainer (such as YASim or WeatherCM), but a lot of the dead code is in the well-trodden public corridors of FlightGear, like fg_init.cxx, main.cxx, etc. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes: > Some of the other XML files are rather easy to figure out > (i.e,. keyboard. xml), but others are not (i.e., the FDM specific > files). YASim and JSBSim each uses its own XML format, which is different from the XML format used by the rest of FlightGear. For YASim, see $FG_ROOT/Aircraft-yasim/README.yasim in the base package; for JSBSim, see the documentation at http://jsbsim.sourceforge.net/. UIUC uses a non-XML config-file format. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
Jon Berndt writes: > Elimination of dead code (as we all know, CVS is really good for > tracking past changes) and better documentation would be really > helpful. We'd like to be better in JSBSim too - we all face this. Absolutely. While I don't tend to keep #ifdef's around, some of my code is pretty badly obfuscated right now, so I need to take care of the beam in my own eye before I do too much more preaching about everyone else's slivers. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
Norman Vine writes: > IMHO the biggest obstacle to reading and developing FGFS code is > the formatting > > We really need a mechanical formating means that is acceptable to > every one as the CVS standard even if it is not perfect or even > close to what one would personally use. I disagree that this is the biggest obstacle (or even one of the top 10), but then, I use an editor (XEmacs) with syntax highlighting, brace matching, language-based navigation (jump forward one function), etc., so those features might be hiding the problem from me. That said, I do agree that this is a problem. We probably need a standard coding style for FlightGear code, preferably one that is preinstalled in most programmers' editors. The question is whether we have anyone with cycles available to lead discussion on this and clean up the existing code base. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained
Greg Long writes: > I might go ahead and give Debian a shot on the install, seems like the > distro of choice, and I have a separate Redhat box (233mhz, don't think > its S3 Virge supports OpenGL, I'd have to look) but I could use that for > testing Debian seems to be the choice by large, and if it supports > rpm's I might as well muck around with it for a bit. Debian is a bear to install but a dream to maintain. While Magic Carpet makes it easier than it used to be to pull in security fixes and bug patches for a specific version of RedHat, it doesn't help upgrading from one version to another. In Debian, when you're ready to move from, say, potato, to woody or sid, you just update the paths in /etc/apt/sources.list, then type apt-get update apt-get dist-upgrade To move from one RedHat version to another, I usually had to reformat my hard drive. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Curtis L. Olson writes: > One thing we'd need to think about before we got too far down this > path is the texture RAM requirements of such a scheme. They should be minimal. For the first tier of imposter tiles, we're using textures that we already have, and just replacing the tile with a single quad (or two triangles) that use the most common texture. For the second tier, we're not using textures at all. It should work. > We would need to do something like put 'long enough' skirts around all > the tiles (including the ones with terrain mesh) to hide the gaps. By skirts do you mean something like these? http://java.sun.com/products/jfc/tsc/articles/jcanyon/#SECTION3.1.2 All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Jim Wilson writes: > From where I sit, I'd have to agree more with David. There should > be no cruft left in the code that gets committed. This doesn't > mean individual developers can't keep it around on there local > drive, but once something is good enough to commit it should > contain working code and nothing else. Critical information can > always be kept in comments, but ifdef'ed or commented out code is > very distracting. For here on out I hereby give anyone permission > to hack out any dead, commented out, or useless code that I submit > to the project. You don't need to ask. :-) We'll keep this on file. Same goes for me, by the way. Here's something that might help -- perhaps coders who want to keep old code around and visible could paste it into a separate file, like foobar.attic for foobar.cxx. That way, it would still be visible and easy to find. Personally, I think that's overkill, but it's an alternative for people who don't quite trust CVS to preserve their thoughts for posterity. > On planning ahead: Back when I studied systems analysis 20 years > ago, planning ahead was everything. Hardware price/performance, OO > design, and networks have changed all that. These things are what > make requirements so unpredictable these days (and systems so > flexible). How many distribution software designs of the early > nineties anticipated web based e-commerce? But now as the business > world becomes increasing internetworked, requirement cycles measure > in weeks and months, not years and decades. It is hard to break > old habits though. On tech projects where I've been involved (ranging from $25K to over $50M), I figure we lost $10-$100 for every $1 we saved anticipating future needs. Jim's right -- people are just too stupid to guess the future (if you want a laugh, read the analysts' predictions on Yahoo! finance every morning before the markets open, and compare them with the market close after 4:15 EST -- it boggles my mind that they analysts be wrong *more* than 50% of the time). Planning ahead is OK, but C++ code and interfaces are not the place to do it. What you want is a short, 1-3 page roadmap document saying "here's what we might do in the future and here's how we might do it." There's no point writing more than a few pages unless you want to give up any pretence of writing non-fiction. Perhaps we should stick three files in every code directory: a README file, explaining what the code in the directory does, a PLANS file, where we can put ideas for future interfaces, and an ATTIC file, where we can paste old code we might need again some day. When people send patches, they can send updates to these files as well. I'll volunteer to start the README files myself, if no one objects. Don't expect more than ten words each. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Curtis L. Olson writes: > If you are willing to setup these files and keep them from getting too > far out of date, then this sounds like a reasonable proposal to me. I don't mind setting up the READMEs. The others will be set up as needed. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Getting settled in my new "home" / Mars Scenery
Curtis L. Olson writes: > That's one valid knock against Linux in general ... knowing how to > admin one distribution doesn't necessarily help you a bit with other > distributions. That's a bit of an exaggeration. There are quirks -- Debian uses /etc/rc?.d while RedHat adds another level, or example -- but the distros are 99% the same; it's just that we notice the parts that are not. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Inlined code harmful?
I've been running some experiments on the property manager today, retrieving different kinds of double properties in a tight loop and timing the results (the worst case was 6.2 seconds for 100M accesses of a property tied to object methods; the best was 4.3 seconds for 100M accesses of a property tied to a pointer). I had been concerned that SGPropertyNode::getDoubleValue was showing up at the top of the profiling output for JSBSim, but I think that that was masking the object methods it was invoking in other JSBSim code. I tried a lot of different combinations to speed things up and have managed around a 13 per cent improvement so far for internal properties, but not much for anything else. The biggest surprise was that inlining methods made things slower, not faster, in most cases (there were a couple of exceptions). That may be a quirk of G++'s code generation, but it's probably worth considering -- I had inlined much of the infrastructure to try to speed things up, but then put it back out of line again piece by piece. Since inlined code is nasty for other reasons -- it bloats the executable, makes the header files hard to read, screws up gdb, and forces a lot of recompilation whenever the implementation changes (since everything that includes the header has to be recompiled) -- we might want to consider trying to avoid it. Does anyone know of any studies or statistics available on this? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inlined code harmful?
Andy Ross writes:
> It's probably not a quirk. Inlining actually helps very little except
> for VERY small functions. It used to be that a function call was slow
> -- you had to spill a bunch of registers and a return value onto the
> stack, and then clean them up later. But modern processors can, for
> the most part, stick all that mess into into a few extra pipeline
> stages.
Yes, that was my guess, too. When the method was just a straight
getter, like
inline double get_foo () const { return _foo; }
inlining didn't seem to hurt much (and in a couple of cases it made a
very tiny speed improvement), but once the inlined code had a couple
of lines, either in itself or indirectly by invoking other inlined
code from the standard library headers, inline caused a significant
slowdown (sometimes >25% in a tight loop). That happened even in the
inlined code wasn't invoked, i.e.
inline void foo ()
{
SG_LOG(SG_GENERAL, SG_ERROR, "An error");
}
then
bool flag = false;
if (flag)
foo();
// some other stuff
I was surprised by how much faster things like this ran when I
un-inlined foo().
The build-time problem that Andy mentions has two causes: one is the
code inlining, and the other is the simple fact that so many modules
still include headers from so many other modules. Curts FGGlobals and
my property stuff is an attempt to get rid of (a lot of) that, but the
cleanup has only started. It might be some consolation to Andy that
things used to be much worse.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Doc Check
Cameron Moore writes: > I'm not familiar with our XML parser, but could we get away with using > this instead?: > > In other words, you'd like to be the equivalent of true or 1 I'm not sure if that's a good idea -- I'd be more inclined to default to 0/false/empty-string. What do other people think? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Inlined code harmful?
Jon Berndt writes:
> > I had been concerned
> > that SGPropertyNode::getDoubleValue was showing up at the top of the
> > profiling output for JSBSim, but I think that that was masking the
> > object methods it was invoking in other JSBSim code.
>
> Could very well be.
>
> > properties, but not much for anything else. The biggest surprise was
> > that inlining methods made things slower, not faster, in most cases
>
> This is certainly interesting. Do you have any statistics on how the
> property code was changed by un-inlining things?
I'm afraid that my tests were fast and not that scientific, but here's
the most dramatic case, for 100,000,000 accesses of a double property:
Everything inlined: 3.9sec
Nothing inlined: 3.2sec
Only variable-reference getters inlined: 3.15sec
In this test, we paid a 22% time penalty for inlining even 2-3 line
methods (anything that didn't resolve simply to a variable reference).
Perhaps the results would be different under other circumstances. By
"variable-reference getters" I mean things like
double get_foo () const { return _foo; }
where the compiler will treat
double foo = thing.get_foo();
as
double foo = _foo;
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inlined code harmful?
Tony Peden writes:
> To get the equivalent of tieing to object methods, a once-per-frame data
> copy is necessary. Did your testing take this into account?
No, I was just testing access time. I checked in some optimizations
that skip a lot of unnecessary code when the value is held internally,
so the differences are even greater now.
Here are some tests I just ran, for 100,000,000 accesses of a double
property (I ran each on a few times then picked the most typical user
time; there was little variation anyway):
Tied to object methods: 5.880 sec
Internal (access only): 2.870 sec
Internal (1:1 get:set ratio): 3.74 sec
Internal (10:1 get:set ratio): 3.07 sec
Even when I copy the property value once for every access, it's much
faster than tying to methods. When I set once for every 10 accesses
(probably typical for the more popular properties), there's almost no
additional overhead.
I am trying to find ways to optimize tied methods, but I haven't found
any way yet to handle them without excessive indirection, because of
the necessity of instantiating a template for each different
class/type combination. I should be able to get tied pointers working
as fast as internal methods, though, if we decide to keep those.
> I found only a slight improvement by un-inlining several of the most
> called object methods in JSBSim. The profiling did show less time spent
> in SGPropertyNode::getDoubleValue, but more time in the un-inlined
> getters.
Yes, that was mainly just a matter of making the profiling report more
accurate. Remember that my tests were just for the speed of property
accesses (hence the focussed, tight loop). If we made property
accesses 25% faster, and they accounted for, say, 1% of program
execution time, we'd see only a 0.25% speed improvement.
> In terms of total execution time, I'd say it came out about the same.
> A real gain might be had if I un-inlined more tied methods, I don't
> know at this point.
Even if uninlining the methods kept the speed the same, it would be a
good idea -- the JSBSim executable will be smaller and GDB will be
able to report the current position more accurately. The only reason
not to do it would be if uninlining caused a serious performance hit.
As I mentioned before, the only methods that seem to work well inlined
are ones that simply resolve to variables, like
double get_foo () const { return _foo; }
void set_foo (double foo) { _foo = foo; }
Even here, the advantages are very slight; anything more complicated
seems to slow things down.
This is all separate from the issue of the property manager, of course.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
