[Flightgear-devel] keyboard.xml
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-key to left of 1) break the XML parser. Is this intentional? 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. Perhaps a generic keyboard.xml, with keyboard-uk.xml or whatever included to redefine the relevant keys? Richard ___ 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-key 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): ?xml version=1.0 encoding=ISO-8859-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 #163; 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] ANN: first experimental 3-D cockpit
David Megginson [EMAIL PROTECTED] said:
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.
Think you have to decide which up vector to rotate. With the pilot-view the
world up vector gets rotated around the x and y. And with model view it gets
rotated around the same for the model's up vector. So pick one and it should
look fine. I guess I would recommend leaving the model fixed so that the
panel isn't bouncing all over the place. That alone would fix the problem.
As far as the matrix math, I think I know what to do, just not sure where the
model rotation is getting applied...see a possibility, but have to head out of
town now until tonight. Basically it is a matter of finding it and not
applying rotation to the model. I can see how getting all this into a single
view class would help here :-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
* [EMAIL PROTECTED] (David Megginson) [2002.03.10 10:47]: 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. David and I briefly discussed changing the keyboard XML schema back in November. If anyone is considering reorganizing the keyboard XML, please consider what we came up with: http://mail.flightgear.org/pipermail/flightgear-devel/2001-November/001134.html http://mail.flightgear.org/pipermail/flightgear-devel/2001-November/001136.html Well, back to RL... Thanks -- Cameron Moore [ Why doesn't Tarzan have a beard? ] ___ 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
On Sat 9. March 2002 20:36, you wrote: 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. 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. 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. 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 think that we should write down the properties tree first and then make new view class. There is also question if support command line parametrs for changing view parametrs and how. I started some coding and found all places where viewer is hardcoded. But total rewrite of view class is IMHO out of my programing skill, specially unlink scenery from FDM position :-( Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgReshape
I find that we call fgReshape function in each RenderFrame, and it is IMHO needless. When you remove fgReshape from fgRenderFrame all resizing works, you only can't change resolution via property manager. But do we need it? Do you have some objection, before I send a patch. Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] keyboard.xml
Richard Bytheway wrote: 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-key to left of 1) break the XML parser. Is this intentional? 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. It's not the location of the keys, but their encoding values. In this case, the pounds sterling symbol (which I cannot easily type) has an ISO-8859-1 value of 163, while the # symbol, which US keyboards have in that position (and which, confusingly, is also often called a pound sign) is represented by 35. The core point is that XML is encoded, by default, in unicode's UTF-8. UTF-8 has the nice property that ASCII values less than 128 encode as themselves. But higher values, including the ISO-8859-1 symbols you want to type, do not. The XML parser will break if you hand it an ISO-8859-1 document. Now, the XML standard allows for specifying the document encoding in the header. I don't know if ours does or not, but it's probably worth investigating. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 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] Virtual cockpit notes
I was once on check ride (in a DC-6 simulator) where the person flying the sim (not me!) ran teh fire proceedure as follows: Throttle close, closed the number one throttle Feather the engine, feathered the number two engine Mixture control idle-cut off, placed the number three mixture to cut off Fire wall shut off valve pull, pulled the fire wall shut off valve lever for the number four engine Airplane got very quiet. Check pilot got very loud!!! I'm now forced to admit that there IS some use for the view of the props. I don't know about DC3s but in DC6s and DC7s we counted either 6 or 8 blades before giving the engine fuel and ignition. (Do you know why? Answer, to avoid bemding the crankshaft or connecting rods i oil had fun down into a jug. If it had, the starter motor could not do damage, but if the engine fired it would bent stuff as teh oil in the closed cyl did not compress well grin! 6 (or 8) blades insured that the engine had made a full revolution on the starter motor only. jj On Sun, 10 Mar 2002, David Megginson wrote: 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
David Megginson wrote: 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. Amen. I spent many hours over the weekend trying to make the view code work in the presence of the virtual cockpit without breaking everything, and got essentially nowhere. I can think of only one or two other times in my career that I've been so befuddled by code. :) 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. This sounds best. Ultimately, the view is just a tuple with six degrees of freedom. The front-end code would feed these numbers via the appropriately complicated mechanism (aircraft phi/theta/psi plus view offset/tilt, for example), but clients would only care about the final numbers, and not the intermediary stuff. Right now, everyone has to agree on everything. There are *lots* of places where the external view is hard-coded as the second view, for example, because it has to be interpreted specially. In practice, everyone only sort of agrees. So most stuff works, until something (virtual cockpit) comes along that wants to interpret the existing numbers in a new way, and boom. I'm going to try tackling the back-end rewrite -- the code that takes view and presents it to the various clients in a consistent way. This is going to touch a lot of stuff, but should result mostly in code removal. Which brings up a good question to ask: can someone provide a quickie overview of the various coordinate systems? I've read the coordinates document, which is good, but incomplete. Really, what I want is a list of all the things that are going to be drawn, and what they expect the modelview matrix (er, plib matrix state, rather) to look like. Specifically, does scenery draw using global cartesian coordinates? Some comments seem to imply that, but I'm dubious -- these would require doubles throughout the matrix pipeline for sufficient precision. Likewise, what are the conventions for the aircraft model? I *think* that it's X-back, Y-right, Z-down, but I'm not sure. Could someone verify? And can someone tell me what the deal is with plib coordinates? I was browsing through the source code and stumbled on a very frightening-looking axis swap matrix (its existence was frightening, the axis swap is obviously trivial) that gets applies in various situations. Are plib coordinates different from OpenGL ones? Eek. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
David wrote: 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. I wrote my critizism so that things will be improved, not to critize someone and certainly not one of the most active devlopers. I do admit I was a bit frustrated, since I have slept little for at least a month now and my current non coding free time is listening to tapes on the work to and from work. So, I got frustrated when I needed an hour or two just to find out the name of a parameter. So, IMHO, we should try to not change *after* 0.8.0 (or 0.7.10) again. Also, it was meant as encouragment to write a UI; If you can simply choose from possible parameters, you don't need to hunt for its name. If noone does a UI then one thing one can do is have a commmand line parameter to fgfs that forces it to write out all possible properties etc. I would guess fgfs has a complete list of these somewhere? The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, I am not arguing against XML. There are several things unclear to me that IMVHO should be (better) documented. 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) This should be in the Docs (or did I miss a major XML doc? I only read the http://www.megginson.com/flightsim/fgfs-model-howto.html ). 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: I see. At the beginning, this was unclear to me although I more or less realized this after a bit. Calling things properties that are not --prop: things is IMHO not a good idea. 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. All the best, David Bye bye, Wolfram. ___ 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: first experimental 3-D cockpit
decloaking Hopefully the list administrators will allow this post from a non-subscriber thru to the list :-) Here are some of my thoughts on how the 'View' please change this to 'Camera' should work. 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. Sadly, this requires more than just a fix. The virtual cockpit code needs to be able to read the current view direction as an offset from aircraft coordinates from the view_offset/view_tilt properties. But those are lies -- the real view direction is maintained by the mouse code, and is defined in global coordinates. These need to be unified. I keep thinking I've got it, and then getting crushed by a new discovery. This morning's surprise was that the mouse direction is handled by FGViewer, but the view_offset stuff actually happens outside the viewer object, in the main loop. It may well be better to wait for the ground-up rewrite of the view code before dealing with this. Alternatively, dealing with this may well *become* the ground up rewrite. :) I'll keep you posted. FWIW - IMHO FIRST yank out all the offset/tilt stuff and use a 'camera' quaternion to represent these instead, THEN put the Mouse quaternion back adding in the previously commented out horizontal component as you will need it. Now you can just add the Mouse quat to the Camera quat and any other applicable 'orientations' into a VIEW ORIENTATION quat in the main loop From this you can easily get the Euler Angles and/or the Rotation Matrix of the 'cumulative view rotation' for what ever purposes you need. Easy beans - no gimble lock - infinitely stackable orientations - everything has it's own logical spot - quick - elegant - natural orientation changes ie slerp's - the code is basically all in PLib for the using already - ect Now since every one seems confused a general overview of how FGFS determines the 'VIEW' There are several things that you want to keep in mine along the way 1) the PLib coordinate system has the same 'sense' as OpenGL but is 'Z' up. ie when looking the origin in a cannonical way X is across the screen left to right ie right is positive Z is across the screen bottom to top ie up is positive Y is going into the screen positive is away from you this is a simple rotation of a right handed coordinate system and is due to the fact that the PLib author primarily writes FlightSimulators where this is a 'natural coordinate basis If you don't like this fact either get over it or quit using PLib 2) the LaRC coordinate system is different also but this should be handled transparently for you in existing code see comment in viewer_rph.cxx 3) The next piece in the puzzle that complicates things 'a little bit' is that there is not enough precision in a float32 to handle things precisely on the surface of the Earth if the coordinate system originates at the ECP [0,0,0] therefore 'most coordinates' are manipulated in a local cordinate system that gets regenerated every frame relative to the 'scenery center', which conveniently is set each frame to the overflown tiles center point which is 'close to the intersection of Earth Radial Vector expressed in direction cosine form with the 'best fit plane' of all the points in that tiles scenery. in reality I think it is just the average of all tiles points but it helps to visualize it as 'this tiles plane' Finally given the above pieces an a current position expressed as Lat Lon AGL we first determine the XYZ offset of this Lat Lon AGL triplet by 1) converting from Ellisoidal Lat Lon SeaLevel to Spherical Lat Lon SeaLevel // cartesian coordinates of current lon/lat if at sea level // translated to scenery.center sgVec3 zero_elev; 2) we add to this our AGL to get // absolute view position in earth coordinates sgdVec3 abs_view_pos; 3) we subtract the Scenry Center the overflown tile's center from this // view position to go into our opengl world coordinates (this is the // abs_view_pos translated to scenery.center) sgVec3 view_pos; 4) we determine the Rotation Matrix that represents the Orientation of the Aircraft with respect to the Current Tangent Plane ie FDM's reference plane // code to calculate LOCAL matrix calculated from Phi, Theta, and // Psi (roll, pitch, yaw) in case we aren't running LaRCsim as our // flight model You can do this long hand or use my handcoded MakeLOCAL( LOCAL, rph[1], rph[0], -rph[2] ); 5) You then make a rotation matrix that brings the current surface position ie you lat lon position to the 'zero spot' This is your UP Matrix 6) multiplying this by the previously found LOCAL matrix aircraft orientation Gives you your Primary VIEW_ROT matrix which knows all about the Aircraft's
Re: [Flightgear-devel] ANN: first experimental 3-D cockpit
[A bunch of notes on Norm's notes. Basically, everything he wrote (even the editorializing) makes sense to me, with a few exceptions as detailed below] Norman Vine wrote: Easy beans - no gimble lock - infinitely stackable orientations - everything has it's own logical spot - quick - elegant - natural orientation changes ie slerp's - the code is basically all in PLib for the using already - ect Heh, you're a quat nut, huh? They're nice, but hardly necessary*. The biggest difficulty is in picking the front-end interface, for which quats basically suck. I want to have a hat switch mapping where left becomes subtract a little from view_offset. You can't expose the quats to the user -- you need eulers for that, warts and all. [* YASim doesn't bother, for example -- everything is stored as an orientation matrix. A Graham-Schmidt normalization is more expensive than a quaternion normalization, but no less stable. And if you have to constantly convert to the matrix space anyway, the performance gains are a wash.] Now since every one seems confused a general overview of how FGFS determines the 'VIEW' 1) the PLib coordinate system has the same 'sense' as OpenGL but is Z' up. [...] this is a simple rotation of a right handed coordinate system and is due to the fact that the PLib author primarily writes FlightSimulators where this is a 'natural coordinate basis If you don't like this fact either get over it or quit using PLib Chill, Norm, we can deal. :) But having it spelled out somewhere more obvious would be nice. I discovered it accidentally while browsing through the source code. Just a hint for the next time you guys are auditing the documentation. 2) the LaRC coordinate system is different also but this should be handled transparently for you in existing code see comment in viewer_rph.cxx There's a (reasonably) standard interface for the FDMs to export their location and orientation. This bit isn't a problem. 'most coordinates' are manipulated in a local cordinate system that gets regenerated every frame relative to the 'scenery center', which conveniently is set each frame to the overflown tiles center point which is 'close to the intersection of Earth Radial Vector expressed in direction cosine form with the 'best fit plane' of all the points in that tiles scenery. in reality I think it is just the average of all tiles points but it helps to visualize it as 'this tiles plane' Hrm... why not set the origin to the aircraft's (or pilot's eye) location instead? Why should the camera code care about scenery tiles? I'll take a look, maybe we can simplify this some. It strikes me as easier for the tile renderer to compute an offset from the aircraft's (double-valued) cartesian coordinates than it is for the camera code to figure out (1) what the nearest tile is and (2) what its center point is. Have I misunderstood? Finally given the above pieces an a current position expressed as Lat Lon AGL we first determine the XYZ offset of this Lat Lon AGL triplet by [... very long description of how the scenery renders ...] This seems like more behavior than is appropriate for camera code. How about this as a design: The camera code hands the tile renderer the following information: + An orientation-only matrix that converts between pilot's eye reference frame to global cartesian coordinates. This could be placed in the scene graph and used implicitly. + A cartesian position of the eyepoint origin. The tile renderer would fix up its coordinates appropriately, be that in an OpenGL matrix or via plain old FPU addition. This is sufficient for the tile renderer to draw itself, and is significantly smaller than the current interface. Specifically, the lat/lon/agl stuff (Euler angles in disguise) comes out of the interface and can live in the implementation where it belongs. Now all you have to do is add in your local 'eye' rotations to this matrix and as should be apparent I STRONGLY suggest using individual quaternions for this This seems wrong. Nothing but the camera code cares about the difference between eye rotations, model orientations, or world orientations. All they want to know is which way the camera is pointing. Certainly, the cockpit renderer (for example) will not include the eye rotation, but it doesn't care about the *value* of the rotation. That's the whole point of the matrix stack -- just push your modifications on to it and forget about what came before. The business of quats is fine with me. I'm not nearly so enamoured of them as you are, but they're a good tool for holding an orientation. They make a very poor tool for (user-)specifying a rotation, however. FYI I was about to rip out the view offset stuff after first having a discussion about the View Pipeline and how it all tied together but then somehow the tilt matrix just got added
[Flightgear-devel] SimGear - security fix - zlib upgraded
Normally the FlightGear project isn't affected by or concerned with various platform security problems or viruses, and because FlightGear shouldn't need to be run suid root, typical security issues shouldn't affect us. However, a bug has been found in zlib-1.1.3 (which is distributed as a convenience with SimGear.) Zlib-1.1.4 has been released to address this security problem: http://www.gzip.org/zlib/advisory-2002-03-11.txt I have upgraded the zlib package in simgear's cvs repository and future versions of SimGear will ship with at least zlib-1.1.4. Most Linux/Unix/Cygwin people will likely want to install an updated package from their OS 'vender' ... i.e. an .rpm, .deb, or .tar.gz as soon as one becomes available. People who have built and installed zlib-1.1.3 from SimGear for the sole purpose of building FlightGear should have little to worry about, but just to be safe, it wouldn't be a bad idea to upgrade your version of zlib and rebuild simgear and flightgear (and any other applications that you might have built against the older version of zlib.) Again, this problem really doesn't affect flightgear/simgear/terragear directly, but because zlib-1.1.3 adds a potential security hole to security sensitive applications (i.e. network daemons, web servers, etc.) I want to make sure the version we distribute is the latest. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: first experimental 3-D cockpit
[A bunch of notes on Norm's notes. Basically, everything he wrote (even the editorializing) makes sense to me, with a few exceptions as detailed below] Norman Vine wrote: Easy beans - no gimble lock - infinitely stackable orientations - everything has it's own logical spot - quick - elegant - natural orientation changes ie slerp's - the code is basically all in PLib for the using already - ect Heh, you're a quat nut, huh? NO I HATE WORKING IN QUATS THEY MAKE MY HEAD SPIN :-) but they have their occasional place and this is one of them ! They're nice, but hardly necessary*. The biggest difficulty is in picking the front-end interface, for which quats basically suck. I want to have a hat switch mapping where left becomes subtract a little from view_offset. You can't expose the quats to the user -- you need eulers for that, warts and all. There are euler to quat interface routines in PLib Use what ever interface you want but INTERNALLY I say you want quats when you are modeling a 'free' rotation otherwise you ALWAYS run into a 'singularity' that you CAN'T work around And of course there is the elegant way to control spherical accellerations that we haven't even talked about :-) ie I want my head a(de)ccelerating smoothly not with an unatural jerk Now since every one seems confused a general overview of how FGFS determines the 'VIEW' 1) the PLib coordinate system has the same 'sense' as OpenGL but is Z' up. [...] this is a simple rotation of a right handed coordinate system and is due to the fact that the PLib author primarily writes FlightSimulators where this is a 'natural coordinate basis If you don't like this fact either get over it or quit using PLib Chill, Norm, we can deal. :) Hey all you had todo was ask and PLib has been that way from the beginning and we all thought every one just knew it :-) ie When in Rome do as the Romans ect But having it spelled out somewhere more obvious would be nice. FWIW - I was not a big fan of adopting PLib for this and more importantly its NON-C++'ness but I accepted it and more importantly became a PLib developer jsut so I could watch out for FGFS Interests ! FYI - Several other FGFS'ers did the same feeling that developing PLib was developing FGFS. I feel sorry for all of those that think of PLib as an 'external' constraint it certainly didn't start off that way and it certainly needen't remain that way I discovered it accidentally while browsing through the source code. Just a hint for the next time you guys are auditing the documentation. You mean you just ASSUMED we were using an OpenGL coordinate system ? 2) the LaRC coordinate system is different also but this should be handled transparently for you in existing code see comment in viewer_rph.cxx There's a (reasonably) standard interface for the FDMs to export their location and orientation. This bit isn't a problem. Hey LaRC Sim is what made FGFS possible and by default determined how a lot of things were done. FWIW this is a good piece of Quat code and is well documented in reference 1 at http://jsbsim.sourceforge.net/fsreference.html As Newton said 'I stand on the shoulders of giants' This isn't quite fair. I wasn't party to the discussion, but the tilt angle got added to solve a specific problem. The panel/UI world *needs* an euler angle interface to the view direction to do its job. Bah It needs an interface . If you want to talk to that interface with eulers fine but it doesn't have to be an euler representation as you yourself just said it just needs an euler interface. Under the existing implementation, the mouse code was the sole aribiter of those numbers, didn't export them as anything but a full quaternion, and didn't accept input from anywhere. So a new feature was needed. Wrong the GUI exported an euler matrix ! From which you could have easily picked up the 'Mouse contribution' to the vies rotation with gram scmidt or whatever. OUT ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Build Failure with Newest fg_sound.?xx
I just updated my Windows machine with the latest source and did a build.
Under MSVC, it does not like:
static const struct {
string name;
double (*fn)(double);
} __fg_snd_fn[] = {
// {lin, _fg_lin},
{inv, _fg_inv},
{abs, _fg_abs},
{sqrt, _fg_sqrt},
{log, _fg_log10},
{ln, _fg_log},
// {sqr, _fg_sqr},
// {pow3, _fg_pow3},
{, NULL}
};
and I got the following errors:
fg_sound.cxx
c:\flightgear\src\sound\fg_sound.cxx(56) : error C2440: 'initializing' :
cannot convert from 'char [4]' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(56) : error C2440: 'initializing' :
cannot convert from '' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(57) : error C2440: 'initializing' :
cannot convert from 'char [4]' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(57) : error C2440: 'initializing' :
cannot convert from '' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(58) : error C2440: 'initializing' :
cannot convert from 'char [5]' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(58) : error C2440: 'initializing' :
cannot convert from '' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(59) : error C2440: 'initializing' :
cannot convert from 'char [4]' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(59) : error C2440: 'initializing' :
cannot convert from '' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(60) : error C2440: 'initializing' :
cannot convert from 'char [3]' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(60) : error C2440: 'initializing' :
cannot convert from '' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(63) : error C2440: 'initializing' :
cannot convert from 'char [1]' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(63) : error C2440: 'initializing' :
cannot convert from 'const int' to 'const struct '
No constructor could take the source type, or constructor overload
resolution was ambiguous
c:\flightgear\src\sound\fg_sound.cxx(64) : error C2639: compiler generated
default constructor required by unnamed class
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Failure with Newest fg_sound.?xx
Changing the data structure to read:
static const struct {
char * name;
double (*fn)(double);
} __fg_snd_fn[] = {
caused everything to work properly. I know that this is not the proper C+
+ solution, but it worked for me.
Jonathan Polley
On Monday, March 11, 2002, at 08:21 PM, Andy Ross wrote:
Jonathan Polley wrote:
I just updated my Windows machine with the latest source and did a
build.
Under MSVC, it does not like:
static const struct {
string name;
double (*fn)(double);
} __fg_snd_fn[] = {
// {lin, _fg_lin},
{inv, _fg_inv},
{abs, _fg_abs},
{sqrt, _fg_sqrt},
{log, _fg_log10},
{ln, _fg_log},
// {sqr, _fg_sqr},
// {pow3, _fg_pow3},
{, NULL}
};
Hrm... this was the same construct that was giving Erik trouble with
the MIPS compiler. Apparently VC++ doesn't like it either.
You could try making the type explicit instead:
struct DummyTypeName {
string name;
double (*fn)(double);
};
DummyTypeName __fg_snd_fn[] = { ... }
...and see if that fixes it. Or if you're not stuck on the MS
compiler, you could use GCC under cygwin, which handles it just
fine.
duck
Andy
-- Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
