Re: [Flightgear-devel] New subsystem: FGEnvironment
Andy Ross wrote: safety lock; even a perfectly threadsafe property system is susceptible to race conditions. The point, again: *all* multithreaded code is susceptible to race conditions and deadlocks. There is *no* way around this. The only way to avoid them is to be very, very careful with your design. You cannot rely on libraries to save you. You cannot rely on simple techniques to save you. You have only your mind, your experience, and the minds and experience of the yahoo threading cowboys working on the rest of the project to rely on. Now, are you getting the point? :) I like the consept of multiple programs (communicating through sockets or pipes) over threading anyhow, and that *forces* you to think about it :-) You are right about the example you gave, the pth packages only removes the multiple r/w operations on the same value at the same time (which might be a good step foreward anyhow), but indeed it doesn't save you from *all* problems. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] (Newbee) Problems compiling MetaKit
Hoyt A. Fleming wrote: I am attempting to compile (version 2.4.2-32) MetaKit, which is included in (version 0.0.17) Simgear. (I am utilizing cygwin to create binaries on a PC.) The ../unix/configure command appears to work fine. However, the make command creates the following error message: g++ -c -O2 -I../unix/../include -I/usr/include ../unix/../tcl/mk4tcl.cpp -DDLL_ I have to be carefull abot what I'm saying about metakit here but (;-)) do you realy wan't the metakit tcl bindings? If not, the easies way is to configure it with the following option: --without-tcl I know it's not a fix, but it could get you going. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Broken Code
John Wojnaroski writes: On Jan 19 the FGEngInterface and FGGearInterface were removed from the flight.hxx source. It broke a lot of code in the opengc interface as well as internal logic to modulate the display symbols. Is the OpenGC interface in the FlightGear code base, or separate? I made sure that all existing code still compiled, but I wasn't aware of breaking any third-party code at the time, and I apologize for any damage. In general, it is a good idea to follow the advice that has come across this list during earlier discussions (especially from Curt, Andy, and me), and rely on the property manager rather than the C++ interfaces. Property names do change occasionally, but the breakages those changes cause are much less violent (and easy to debug using the property browser). As Curt has mentioned recently, we do plan to remove most of FGInterface as well, when we have the chance; we are able to test that nothing in the FlightGear code base breaks, but obviously, we have no way to test external code. If you're still using FGInterface calls to get the current altitude, velocities, etc., I recommend switching to properties as soon as possible to avoid future problems. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Animated C172
Almost all of the major moving surfaces in the C172 are now animated: - propeller - ailerons - flaps - rudder - elevators The nosewheel still doesn't turn, but I'll add that when I get a chance. I'll probably start on the DC-3 first, though. Inevitably, I've got some of the movements backwards. Could someone check and let me know which ones? It's a lot more interesting watching the C172 in autopilot from the outside, now that you can see the surfaces move. 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] Animated C172
On Tue, 2002-02-26 at 05:58, Jon S. Berndt wrote: Excellent. Is there an X-15 model? :-) There's not much to see at Mach 5. Jon Almost all of the major moving surfaces in the C172 are now animated: - propeller - ailerons - flaps - rudder - elevators David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] (Newbee) Problems compiling MetaKit
Erik, Thanks for the help! I configured MetaKit with the --without-tcl option and received the following error: Hoyt A. Fleming@HOYT'S_DESKTOP /usr/local/source/simgear/metakit/builds $ ../unix/configure --without-tcl checking for Python configuration... not enabled checking for Tcl headers... configure: error: no directory doesn't contain tcl.h Hoyt A. Fleming@HOYT'S_DESKTOP /usr/local/source/simgear/metakit/builds $ Any ideas? Hoyt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Erik Hofman Sent: Tuesday, February 26, 2002 3:00 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] (Newbee) Problems compiling MetaKit Hoyt A. Fleming wrote: I am attempting to compile (version 2.4.2-32) MetaKit, which is included in (version 0.0.17) Simgear. (I am utilizing cygwin to create binaries on a PC.) The ../unix/configure command appears to work fine. However, the make command creates the following error message: g++ -c -O2 -I../unix/../include -I/usr/include ../unix/../tcl/mk4tcl.cpp -DDLL_ I have to be carefull abot what I'm saying about metakit here but (;-)) do you realy wan't the metakit tcl bindings? If not, the easies way is to configure it with the following option: --without-tcl I know it's not a fix, but it could get you going. Erik ___ 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] Animated C172
Jon S. Berndt writes: Excellent. Is there an X-15 model? :-) Seriously, there probably won't be one from me. My main interest is civil propeller-driven planes, and after I've fixed up the DC-3 model, I'll probably do a C-310 3D model, followed by a Twin Otter (if I can manage a JSBSim or YASim aero model to go with it) and maybe a Dash-8 (ditto). I might be interested in some civil jets like the DC-9, but I'm unlikely to be making any military or NASA models (not even a Spitfire). That said, it might be possible to animate the X-15 model that we already have, assuming that the various objects in the model are named. 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] Animated C172
David Megginson writes: Almost all of the major moving surfaces in the C172 are now animated: - propeller - ailerons - flaps - rudder - elevators The nosewheel still doesn't turn, but I'll add that when I get a chance. I'll probably start on the DC-3 first, though. Inevitably, I've got some of the movements backwards. Could someone check and let me know which ones? It's a lot more interesting watching the C172 in autopilot from the outside, now that you can see the surfaces move. David, The elevator is backwards, but other than that it looks great. (The flaps don't smoothly transition, but you probably are aware of that.) Good work! 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] 'position/altitude-ft' property with UIUC model ?
I've built ftp://ftp.uni-duisburg.de/FlightGear/Aircraft/marchetti-uiuc-set.xml Fortunately this is really simple. But it does not recognize the position altitude-ft1500/altitude-ft /position statement. Wht I start at KSFO i'm still sitting on the ground. Anything wrong out there ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Curtis L. Olson writes: The elevator is backwards, but other than that it looks great. (The flaps don't smoothly transition, but you probably are aware of that.) Yes -- right now the surfaces are tied to /controls/*; I plan to switch to values reported by the FDMs when a) they're all being reported and b) I have time -- I think Tony already has JSBSim reporting gear and flap position. I'll fix up the elevator today. Thanks, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
David Megginson writes: Curtis L. Olson writes: The elevator is backwards, but other than that it looks great. (The flaps don't smoothly transition, but you probably are aware of that.) Yes -- right now the surfaces are tied to /controls/*; I plan to switch to values reported by the FDMs when a) they're all being reported and b) I have time -- I think Tony already has JSBSim reporting gear and flap position. Here's something to consider: right now the control surfaces a visibly separate from the rest of the aircraft. You can see a tiny pixel wide gap in between. Depending on view angle, you can get a lot of aliasing artifacts from this. It might be worth tweaking the model slightly so that the control surfaces overlap by a small amount so you can't see the gap. Another thing that might be interesting is to read the gear compression values out of the FDM ... :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Curtis L. Olson writes: David Megginson writes: Curtis L. Olson writes: The elevator is backwards, but other than that it looks great. (The flaps don't smoothly transition, but you probably are aware of that.) Yes -- right now the surfaces are tied to /controls/*; I plan to switch to values reported by the FDMs when a) they're all being reported and b) I have time -- I think Tony already has JSBSim reporting gear and flap position. David, I'm starting to get nit-picky here :-) but one more thing ... the elevator doesn't seem to be responding to elevator trim. In a real life C172 the elevator trim is a little tab on the trailing edge of the elevator that causes the elevator to actually change position ... kind of like an elevator elevator. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 'position/altitude-ft' property with UIUC model ?
Martin Spott writes: Fortunately this is really simple. But it does not recognize the position altitude-ft1500/altitude-ft /position JSBSim has an on-ground trimming routine. Try also setting the velocity to non-zero. 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] Animated C172
Curtis L. Olson writes: David, I'm starting to get nit-picky here :-) but one more thing ... the elevator doesn't seem to be responding to elevator trim. In a real life C172 the elevator trim is a little tab on the trailing edge of the elevator that causes the elevator to actually change position ... kind of like an elevator elevator. I haven't added a tab object to the 3-D model yet, but I'd like to understand more about how it actually works first (ditto for elevator and rudder trim). From the pilot's point of view, I think, the elevator trim tab controls the amount of pressure required to hold an elevator position on the yoke -- you just turn the wheel with your right hand until you don't have to pull or push the yoke with the left hand (or vice-versa in the co-pilot's seat). I don't think that the trim tab changes the range of the elevator movement per se, as much as it changes the lift of the elevator surface in the airstream (i.e. neutral position is different), but I could be totally confused. In JSBSim, we're just summing up the trim and elevator and clamping to the elevator range -- I don't know if that's right, but it doesn't seem to bother most people. We cannot do real trimming without force-feedback controllers (that can hold a non-neutral position). 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] Animated C172
Curtis L. Olson [EMAIL PROTECTED] said: David Megginson writes: That said, it might be possible to animate the X-15 model that we already have, assuming that the various objects in the model are named. I haven't looked at pretty-poly lately, but it might not be hard to load up the model and assign names to sections (or at least shouldn't be all that hard once pretty-poly is 'finished'.) :-) If someone really wants to do this I'll be glad to load it in my ac3d and name the parts. Just need someone to tell me what to call what (e.g. the flap that opens out of the left side of the upper vertical stabilizer is: blah blah). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Curtis L. Olson writes: David, I'm starting to get nit-picky here :-) but one more thing ... the elevator doesn't seem to be responding to elevator trim. In a real life C172 the elevator trim is a little tab on the trailing edge of the elevator that causes the elevator to actually change position ... kind of like an elevator elevator. David's excuse (grin): I haven't added a tab object to the 3-D model yet, but I'd like to understand more about how it actually works first (ditto for elevator and rudder trim). The motion of the trim tab is only a function of trim wheel position, so it should be easy to show the tab itself in the model. The force of the trim tab on the whole aircraft is minimal and can be ignored. The position of the elevator is a force balance, consisting of the aero force on the elevator, the aero force on the tab and the muscle force on the yoke. All of these forces are linear with position, but the aero forces are also proportional to the square of airspeed. The apparent spring constant for the pilot therefore has a range of a factor of nine (141kias/47kias)^2 according to the situation. However, we ignore spring constant for non-force-feedback controllers. The aircraft motion is determined by the net elevator position, so you should simply draw the elevator in whatever position is being used by the FDM. No other correction is needed. For zero force yoke (aka centered joystick), motion of the trim causes the tab to move one way and the elevator to move the other. The ratio of the two angular rates is about equal to the ratio of the two lengths of the movable pieces of metal. I don't know what it is offhand; it should be apparent from any photo of that area. Hope that helps ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Inconsitent naming in src/FDM/JSBSim
Compilation stops with: JSBSim.cpp file not found. File is JSBSim.cxx Rainer begin:vcard n:Emrich;Rainer tel;fax:+49 6142 827249 tel;work:+49 6142 827212 x-mozilla-html:FALSE org:TECOSIM GmbH adr:;;Im Eichsfeld 3;Ruesselsheim;;65428;Germany version:2.1 email;internet:[EMAIL PROTECTED] title:Director QM/IT x-mozilla-cpt:;-1504 fn:Rainer Emrich end:vcard
RE: [Flightgear-devel] Animated C172
Dave, The system that you describe is the exact type of system that I have in my (full-size) Lancair ES for rudder and aileron trim. Hoyt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of D Luff Sent: Tuesday, February 26, 2002 9:53 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Animated C172 Alex Perry writes: (lots about trim) For zero force yoke (aka centered joystick), motion of the trim causes the tab to move one way and the elevator to move the other. The ratio of the two angular rates is about equal to the ratio of the two lengths of the movable pieces of metal. I don't know what it is offhand; it should be apparent from any photo of that area. I've been wondering for a while - suppose I take a non-force feedback yoke, and attach a wheel that actually moved the neutral position by moving the end points of both springs backwards or forwards, and use this instead of the software trim, would this be a reasonably realistic approximation of elevator trim (from the pilots perspective) or not? Cheers - Dave -- [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] Inconsitent naming in src/FDM/JSBSim
Compilation stops with: JSBSim.cpp file not found. File is JSBSim.cxx Rainer No, there is a file called JSBSim.cxx that is used by FlightGear. The file JSBSim.cpp is used only to test JSBSim in a standalone mode. This file has recently been removed from the FlightGear tree. Try updating your FlightGear code: cvs update -dP If this does not work, write back right away. Could be Curt needs to do something more in CVS. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: re: [Flightgear-devel] position/altitude-ft property with UIUC model ?
JSBSim has an on-ground trimming routine. Try also setting the velocity to non-zero. The file I put on the ftp server is called marchetti-uiuc-set.xml and looks like this: ?xml version=1.0? !-- UIUC Marchetti S.211 init file. -- PropertyList sim flight-modellarcsim/flight-model aerouiuc/aero aircraft-dirAircraft-uiuc/Marchetti/aircraft-dir soundfalse/sound panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path visibilitytrue/visibility /panel panel_2 pathAircraft/c172/Panels/c172-trans-mini-panel.xml/path /panel_2 !-- You must download this separately -- model pathAircraft/Marchetti/Models/marchetti.mdl/path /model /sim position altitude-ft1500/altitude-ft /position velocities airspeed-kt100/airspeed-kt /velocities /PropertyList Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inconsitent naming in src/FDM/JSBSim
Rainer Emrich writes: Compilation stops with: JSBSim.cpp file not found. File is JSBSim.cxx There is some weird default make behavior getting triggered some how. in src/FDM/JSBSim, remove the entire .deps subdirectory. Then do a make clean down there, and that should help. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 26 Feb 2002 11:19:13 -0600 (CST), Curtis L. Olson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: David Megginson writes: I haven't added a tab object to the 3-D model yet, but I'd like to understand more about how it actually works first (ditto for elevator and rudder trim). From the pilot's point of view, I think, the elevator trim tab controls the amount of pressure required to hold an elevator position on the yoke -- you just turn the wheel with your right hand until you don't have to pull or push the yoke with the left hand (or vice-versa in the co-pilot's seat). I don't think that the trim tab changes the range of the elevator movement per se, as much as it changes the lift of the elevator surface in the airstream (i.e. neutral position is different), but I could be totally confused. In JSBSim, we're just summing up the trim and elevator and clamping to the elevator range -- I don't know if that's right, but it doesn't seem to bother most people. We cannot do real trimming without force-feedback controllers (that can hold a non-neutral position). Right, when you move the trim tab, it changes the 'neutral' position of the elevator which is why you then don't need pressure to hold the position. The key thing though is that the elevator does move when the trim changes. I think you could think of it as an alternate input to the elevator control. ..another mental model of this, is servo rudder. Here you have a trim tab size rudder, controlling the rudder (etc for the pre-hydraulic big irons), yawing the plane. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
* [EMAIL PROTECTED] (David Megginson) [2002.02.26 11:35]: Alex Perry writes: The position of the elevator is a force balance, consisting of the aero force on the elevator, the aero force on the tab and the muscle force on the yoke. I'm still not entirely certain that I understand. I know that you don't think in terms of absolute yoke position when you're flying, any more than I think in terms of absolute steering-wheel or gas-pedal position when I'm driving, but perhaps you can verify that this is right: if I hold the yoke in *exactly* the same position and move the trim wheel, the elevator surface will not move; only the amount of force required to hold the yoke in position will change. Is that right? Have a look at these: Elevator: http://www.zenithair.com/zodiac/xl/pic9601z/elevator-trim1.jpg Aileron: http://www.zenithair.com/zodiac/xl/pic9601z/aileron-trim1.jpg The trim tabs are small adjustable surfaces on the main control surface. The trim adjustment doesn't alter the entire control surface. And just for fun, here's an elevator trim tab that's been ripped off at the Reno air races (looks like a modified P-51D): http://www.avweb.com/articles/reno98/dsc066.jpg -- Cameron Moore [ So what's the speed of dark? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Alex Perry writes: The position of the elevator is a force balance, consisting of the aero force on the elevator, the aero force on the tab and the muscle force on the yoke. I'm still not entirely certain that I understand. I know that you don't think in terms of absolute yoke position when you're flying, any more than I think in terms of absolute steering-wheel or gas-pedal position when I'm driving, but perhaps you can verify that this is right: if I hold the yoke in *exactly* the same position and move the trim wheel, the elevator surface will not move; only the amount of force required to hold the yoke in position will change. Is that right? Yes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
I've been wondering for a while - suppose I take a non-force feedback yoke, and attach a wheel that actually moved the neutral position by moving the end points of both springs backwards or forwards, and use this instead of the software trim, would this be a reasonably realistic approximation of elevator trim (from the pilots perspective) or not? That implements the trim effect, but not the change in spring force. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 26 Feb 2002 12:29:35 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Alex Perry writes: The position of the elevator is a force balance, consisting of the aero force on the elevator, the aero force on the tab and the muscle force on the yoke. I'm still not entirely certain that I understand. I know that you don't think in terms of absolute yoke position when you're flying, any more than I think in terms of absolute steering-wheel or gas-pedal position when I'm driving, but perhaps you can verify that this is right: if I hold the yoke in *exactly* the same position and move the trim wheel, the elevator surface will not move; only the amount of force required to hold the yoke in position will change. Is that right? ..yes. The force changes because will help you, or not, holding the elevator in that exact position. ..also try to think of the trim tab as an servo rudder. Here, 'you control the rudder', not the plane. ..several (creative) pilots has been able to land airliners without hydraulic fluid in their control systems, using trim tab systems as servo rudders (and asymmetric power too), to save their own and passengers bacon. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 26 Feb 2002 18:51:05 +0100, Arnt Karlsen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: ..the PA 28/Piper Cherokee family use an all moving elevator, with an anti-servo tab, to _add_ stick forces for pilot feedback. This tab also serve as a trim tab. ..the Piper Cubs use a jackscrew to raise or sink the leading edge of the horizontal stabilizer. Many ways to skin these cats. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken Code
John Wojnaroski writes: Excuse me, but if you go back you will see that I allowed to the fact that I was unclear on the idea of the properties, but was willing to give it a go. I cannot find that message or my replies to it through Google, but it may have missed indexing some archived postings. When you asked about using properties, I probably suggested that you start either by looking at $FG_ROOT/preferences.xml or by saving a flight (using the drop-down menu). Now, fortunately, we have an interactive GUI property browser built right into FlightGear, as well as HTTP and telnet interfaces, so it's very easy to study the properties while the program is running. There are two important C++ APIs you have to learn for properties -- I added extensive documentation comments to both so that contributors won't have to guess how to use them. The low-level implementation is declared in simgear/misc/props.hxx, and Curt has autogenerated HTML documentation here: http://www.simgear.org/doxygen/props_8hxx.html Most of the time, though, you can get away with using the higher-level functions declared in src/Main/fg_props.hxx. Curt hasn't generated HTML documentation from this yet, but if you look at the file, you'll see about a 1:1 documentation:code ratio, and the comments are fairly easy to read. You can look at many parts of FlightGear to see how properties are being used in actual code. I don't agree with that. IMHO that might be true if one is already cognizant and comfortable with the architecture. C++ is a common reference point and moving away from it adds obfuscation. And the more I think about it the less I like it. If one is writing code for a small group then properties might be okay, but in a larger group and open source efforts it seems that changes need to move more slowly and at a more measured pace That's a valid point, and one that Norman Vine (whom I respect greatly) has made forcefully many times. Our problem is that our C++ code base is a mess of spaghetti code with stale methods and excruciating interdependencies -- some of it, like the HUD, isn't even recognizably object-oriented. Writing good, clean C++ code is hard, and refactoring old code is even harder. More importantly, the project was stalling badly a while ago because there were so few hard-core C++ programmers willing and able to contribute. I added the property manager especially so that non-programmers could contribute more easily, but it turned out that it was useful for programmers as well (witness Andy's rapid development of YASim) -- instead of having to learn dozens of inconsistent C++ interfaces, you have to learn only one property-tree structure and you can get and set whatever information you need. The filesystem idiom used in the property tree is familiar to many more people than C++ design patterns (which we don't use well anyway), and given the accelerated progress since we introduced the property manager, it seems to have been a success. As Curt has mentioned recently, we do plan to remove most of FGInterface as well, when we have the chance; we are able to test that nothing in the FlightGear code base breaks, but obviously, we have no way to test external code. Whoa! The arrogance of it all. Sounds like the microsoft way. Do it my way or no way. If your code breaks it's your fault. What's wrong with Microsoft? No, I'm just joking, and I think you misunderstood what I wrote. I apologize that I haven't had time to look at the OpenGC code yet -- FlightGear's a big project. Let me rephrase: I had assumed that your code was already in the FlightGear CVS somewhere, and that when there were no compilation errors, I hadn't broken it. You still haven't honored my request for information on where the gear property values are located or is it a case that each developer is free to defined the properties as they see fit within their own context. If that is the case then I don't think it will be possible to build and maintain an interface to external programs. Again, I cannot find this posting with Google, but the indexing may be incomplete; I also cannot find the message from Tony Peden a couple of months ago where he explained the gear properties to everyone in detail, because that would have most helpful. The gear control position is in /controls/gear-down which is either true or false. Actual gear information for each wheel is published by JSBSim under the /gear hierarchy, but we haven't really standardized that yet -- status reporting from the FDMs for aircraft parts is still something new, and subject to reorganization. YASim may be doing something totally different right now. Please feel free to participate in this discussion and contribute your suggestions as we try to standardize all of this, but remember, also, that we're not a big, impersonal organization like Microsoft, so please try not to use us as a target of any anger or frustration you
re: [Flightgear-devel] Inconsitent naming in src/FDM/JSBSim
Rainer Emrich writes: Compilation stops with: JSBSim.cpp file not found. I had the same problem. You have to remove src/FDM/JSBSim/.deps then recompile (yes, it took me an hour to figure that out). 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 subsystem: FGEnvironment
I like the consept of multiple programs (communicating through sockets or pipes) over threading anyhow, and that *forces* you to think about it :-) You are right about the example you gave, the pth packages only removes the multiple r/w operations on the same value at the same time (which might be a good step foreward anyhow), but indeed it doesn't save you from *all* problems. ..say I build my self a plane the EAA (eea.org) way, in 4 years. And that I want to use a class cockpit and build upon FlightGear code. ..which of the above concepts is easier to make airworthy, and to certify as airworthy? The latter (if yo're concerned about software only). You could certify all the subprograms and the socket interface in seperate runs. Once certified there is no need to look after it, except when it changes. But changing one wouldn't hurt the others. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Alex Perry writes: I'm still not entirely certain that I understand. I know that you don't think in terms of absolute yoke position when you're flying, any more than I think in terms of absolute steering-wheel or gas-pedal position when I'm driving, but perhaps you can verify that this is right: if I hold the yoke in *exactly* the same position and move the trim wheel, the elevator surface will not move; only the amount of force required to hold the yoke in position will change. Is that right? Yes. OK, so our whole FGControls system is actually kludged right now for a particular class of controllers (ones that spring back to a neutral position), rather than an abstract representation of control position. Our elevator value is actually relative deviation from the zero-force position rather than absolute deviation from the centre, and our elevator-trim value is actually deviation from the centre. Ouch. That's fairly intuitive for sprung joysticks, but it makes no sense for the keyboard or mouse, much less force-feedback devices. There's no use wasting time on it now, but that's something we'll need to look into in the future. 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] Animated C172
And just for fun, here's an elevator trim tab that's been ripped off at the Reno air races (looks like a modified P-51D): I read an article about this one: 3500 HP and Vmax of approx. mach 0.82 Not bad for a propeller driven plane, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Alex Perry wrote: David Megginson wrote: I've been wondering for a while - suppose I take a non-force feedback yoke, and attach a wheel that actually moved the neutral position by moving the end points of both springs backwards or forwards, and use this instead of the software trim, would this be a reasonably realistic approximation of elevator trim (from the pilots perspective) or not? That implements the trim effect, but not the change in spring force. The spring force isn't felt by the pilot in that scheme, or the typical (tab style) aerodynamic trim. The trim changes the neutral point of the control; all the force the pilot feels in the yoke is due to the difference from the neutral point. Of course, other trim systems have different properties. The MD-80 scheme I mentioned earlier has no feel whatsoever (the trim axis doesn't connect to the pilot's controls), so feel has to be added artificially somehow if you want the neutral-stick position to change with trim. (I don't know if they bothered or not for the MD-80). Then there are all sorts of meta-trim features in control systems. Consider things like bob weights attached to the stick. These exert extra stick force in situations of high-G, to prevent pilots of aircraft with loose controls (or low dynamic stability) from losing control by snapping the stick back. How do you handle *this* with a USB joystick? :) Control system theory is complicated, and control system simulation is complicated by a 100 year history of pragmatic hackery. Maybe Jon or Tony will want to jump in here. I think we're fine so long as we get the control sense right, and render the appropriate thing on the screen. Getting the feel of a control system down with PC hardware is essentially impossible anyway. 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] Broken Code
John Wojnaroski [EMAIL PROTECTED] said: Excuse me, but if you go back you will see that I allowed to the fact that I was unclear on the idea of the properties, but was willing to give it a go. If this is truely an open source project then other ideas and opinions need to be honored, not just the few with dictatorial commit authority! That doesn't sound quite right from my experience, but i should also say this: Even though these concepts and ideas get discussed on the list often the final decision seems to be done off list. It might be good for someone to pre-announce when they are going to remove or rewrite a major class. While I've seen projects get ruined by too much central authority, personally I appreciate the help of people who already know the project and have a sense of where things ought to be going. I think the FlightGear project strikes a very nice balance. Property names do change occasionally, but the breakages those changes cause are much less violent (and easy to debug using the property browser). I don't agree with that. IMHO that might be true if one is already cognizant and comfortable with the architecture. C++ is a common reference point and moving away from it adds obfuscation. And the more I think about it the less I like it. If one is writing code for a small group then properties might be okay, but in a larger group and open source efforts it seems that changes need to move more slowly and at a more measured pace Having used the property system to learn what I have so far about the code and debug some of it, I'd have to say it helps. Or at least it is more convenient...sort of like having a built in debugger. On the other hand it can badly obfuscate some of the workings since they are not classified the way C++ objects are. As Curt has mentioned recently, we do plan to remove most of FGInterface as well, when we have the chance; we are able to test that nothing in the FlightGear code base breaks, but obviously, we have no way to test external code. Whoa! The arrogance of it all. Sounds like the microsoft way. Do it my way or no way. If your code breaks it's your fault. No the microsoft way is: Yeah we broke that on purpose so you'll have to buy more of our products :-D Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Andy Ross writes: And on that subject, would you like to pick a property tree for the FDM output properties? How about /control-positions? Adding this support to YASim will be quick. Currently, JSBSim uses an /fdm subtree to report some information, and /engine subtree, and a /gear subtree if there is retractable gear. I'd love to hear suggestions for making all of this more consistent and intuitive. Some things, though, might get a little complicated. On some aircraft (like the 172 Curt describes) trim is implemented as a mere offset to the control position. On others, though, it's a change to the incidence angle of the whole assembly. The MD-80 works this way; remember the crash due to the stripped jack screw? That's something we have to implement model-by-model anyway, so we'll just try to do the right thing. So distinct aircraft models will require special support from the FDM. There's no single elevator output that will work for all of them. If the elevator angle is always reported relative to the incidence angle of the horizontal stabilizer, we should be OK. I think that incidence angle should be a separate property from trim, though, just in case there's a plane somewhere that uses both. 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] Animated C172
At 2/26/02, you wrote: Almost all of the major moving surfaces in the C172 are now animated: snip... Sounds really neat. Does all this animation work w/ the LaRCsim and UIUC code? I have a feeling 'yes', but we're still running 0.7.8. Regards, Michael * ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
These are the output names you may find in the current MDL loader: rudder, elevator, ailerons, flaps, gear, spoilers, propeller Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
What do you suggest that I do to the models on my homepage? Is it somehow possible to create a model that works with the old and the new FGFS version? I fear you will tell me to use XML instead of Python? Maybe use both and generate a XML on the fly by Python? Can I easily find out what version of FGFS the user has? Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Valgrind memory checker
Hi, I've just seen an article that mentioned Valgrind, a program that checks for memory access and corruption: http://devel-home.kde.org/~sewardj/ From the homepage it look easy enough to run. Can someone with Linux give it a try? CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Michael Selig writes: Does all this animation work w/ the LaRCsim and UIUC code? I have a feeling 'yes', but we're still running 0.7.8. Yes, it should. Some of it might stop working, though, when we switch to reading positions from the FDMs themselves rather than the control inputs. 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] Animated C172
Wolfram Kuss writes: These are the output names you may find in the current MDL loader: rudder, elevator, ailerons, flaps, gear, spoilers, propeller Cool. It should not be hard for someone to write XML wrappers for the current MDL models to animate them -- just a matter of getting the rotation centers and axes right. People can use $FG_ROOT/Aircraft/c172/Models/c172-dpm.xml as a model for writing a wrapper. 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] Animated C172
David Megginson writes: Michael Selig writes: Does all this animation work w/ the LaRCsim and UIUC code? I have a feeling 'yes', but we're still running 0.7.8. Yes, it should. Some of it might stop working, though, when we switch to reading positions from the FDMs themselves rather than the control inputs. For FDM's that don't do sophisticated control surface position modeling (or fly-by-wire) we could simply echo back the flightgear control position (possibly multiplied by a constant to get it into the desired range.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 2002-02-26 at 10:29, David Megginson wrote: Andy Ross writes: And on that subject, would you like to pick a property tree for the FDM output properties? How about /control-positions? Adding this support to YASim will be quick. Currently, JSBSim uses an /fdm subtree to report some information, and /engine subtree, and a /gear subtree if there is retractable gear. I'd love to hear suggestions for making all of this more consistent and intuitive. Well, what are the chances that both the fdm and the 3D model will need their own set of properties for these things? If there is little chance of that then I think we should go with Andy's suggestion and either eliminate the /fdm tree or save it for special purpose fdm stuff (like the trimming routine is now) Out of my own need to distinguish between input and output, I'd rather the name uses 'surfaces' rather than 'controls'. What form would you need the surface positions in? Actual angles are the easiest thing for JSBSim to output (would those be useful for 3D models?), but I can see where normalized positions (-1..1) might be easier to deal with. Some things, though, might get a little complicated. On some aircraft (like the 172 Curt describes) trim is implemented as a mere offset to the control position. On others, though, it's a change to the incidence angle of the whole assembly. The MD-80 works this way; remember the crash due to the stripped jack screw? That's something we have to implement model-by-model anyway, so we'll just try to do the right thing. So distinct aircraft models will require special support from the FDM. There's no single elevator output that will work for all of them. If the elevator angle is always reported relative to the incidence angle of the horizontal stabilizer, we should be OK. I think that in most cases this will not be true, elevator will usually be reported relative to a body reference line. I think that incidence angle should be a separate property from trim, though, just in case there's a plane somewhere that uses both. Agreed. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Tony Peden writes: Well, what are the chances that both the fdm and the 3D model will need their own set of properties for these things? If there is little chance of that then I think we should go with Andy's suggestion and either eliminate the /fdm tree or save it for special purpose fdm stuff (like the trimming routine is now) Out of my own need to distinguish between input and output, I'd rather the name uses 'surfaces' rather than 'controls'. What form would you need the surface positions in? Actual angles are the easiest thing for JSBSim to output (would those be useful for 3D models?), but I can see where normalized positions (-1..1) might be easier to deal with. We started out using normalized positions for the controls and they have a certain amount of convenience, but these days I'm almost leaning towards actual positions (i.e. yoke in inches forward and aft, and in degrees rotation. Throttle in inches, etc. For us it might make more sense to do meters or centimeters ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 2002-02-26 at 10:30, Andy Ross wrote: David Megginson wrote: ... if I hold the yoke in *exactly* the same position and move the trim wheel, the elevator surface will not move; only the amount of force required to hold the yoke in position will change. Is that right? Yes. On any aircraft that is not fly-by-wire*, the controls the pilot touches are linked directly to the position of the aerodynamic control surfaces. Although in many cases the actual motions are more complicated -- spoilers deploy in support of the ailerons at high control deflections on big jets, for example. But the principle is the same: the control position in the cockpit has a 1:1 mapping to the aircraft's external configuration. Andy * The relationship goes the other way around. Fly-by-wire, by definition, means aircraft where the controls aren't directly linked to the surfaces. OK, if you define fly-by-wire this way. You don't need to have an F-16 style control system though to lose that 1:1 relationship you talk about above. Personally, I would be hestitant to make that assumption for *any* aircraft with fully powered controls. -- 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 2002-02-26 at 11:27, Curtis L. Olson wrote: Tony Peden writes: Well, what are the chances that both the fdm and the 3D model will need their own set of properties for these things? If there is little chance of that then I think we should go with Andy's suggestion and either eliminate the /fdm tree or save it for special purpose fdm stuff (like the trimming routine is now) Out of my own need to distinguish between input and output, I'd rather the name uses 'surfaces' rather than 'controls'. What form would you need the surface positions in? Actual angles are the easiest thing for JSBSim to output (would those be useful for 3D models?), but I can see where normalized positions (-1..1) might be easier to deal with. We started out using normalized positions for the controls and they have a certain amount of convenience, but these days I'm almost leaning towards actual positions (i.e. yoke in inches forward and aft, and in degrees rotation. Throttle in inches, etc. For us it might make more sense to do meters or centimeters ... That would complicate things if you wanted to put surface positions in place of the control positions on the panel since you won't have any sense of how to scale things without knowing the min and max values. Maybe both would be the ideal thing, in other words: elevator-pos-deg elevator-pos-n left-aileron-pos-deg left-ailerlon-pos-n ... 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Does all this animation work w/ the LaRCsim and UIUC code? I have a feeling 'yes', but we're still running 0.7.8. Your feeling's right, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
David wrote: Wolfram Kuss writes: What do you suggest that I do to the models on my homepage? If I recall correctly, the models on your page are already oriented correctly; if so, then they should continue to work fine. You don't need to write any XML unless you need to reorient or animate the models. The Python script sets these parameters: /sim/model/path /sim/model/r-rotation /sim/model/z-offset What does the file version say for the current CVS version? If it says 0.8.0 or 0.7.10 or 0.7.9a or something like that, then I could update my script so that my planes work with 0.7.9 and the current CVS version. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Tony Peden writes: What form would you need the surface positions in? Actual angles are the easiest thing for JSBSim to output (would those be useful for 3D models?), but I can see where normalized positions (-1..1) might be easier to deal with. I use angles (degrees) in the 3D models as well. Currently, I'm converting from the normalized positions, but actual angles would be great. Note that angles will have to be reported separated for each aileron, since the amount of travel up and down often differs. If the elevator angle is always reported relative to the incidence angle of the horizontal stabilizer, we should be OK. I think that in most cases this will not be true, elevator will usually be reported relative to a body reference line. That's fine -- I can design markup to deal with that situation when the need arises. 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] Animated C172
Curtis L. Olson writes: For FDM's that don't do sophisticated control surface position modeling (or fly-by-wire) we could simply echo back the flightgear control position (possibly multiplied by a constant to get it into the desired range.) That sounds reasonable. 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] Animated C172
On Tuesday 26 February 2002 08:52 am, you wrote: Almost all of the major moving surfaces in the C172 are now animated: - propeller - ailerons - flaps - rudder - elevators The nosewheel still doesn't turn, but I'll add that when I get a chance. I'll probably start on the DC-3 first, though. Inevitably, I've got some of the movements backwards. Could someone check and let me know which ones? It's a lot more interesting watching the C172 in autopilot from the outside, now that you can see the surfaces move. All the best, David Awesome! Does gear retraction work? BTW re gear retraction... I'm sure you are aware... The fixed gear planes make gear retraction noise J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Model Configuration Changes
Wolfram Kuss writes: The Python script sets these parameters: /sim/model/path /sim/model/r-rotation /sim/model/z-offset The last two changed quite a few months ago, to z-offset-meters and pitch|roll|heading-offset-deg. They will be that way in 0.7.9, at least. 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] Animated C172
On Tue, 26 Feb 2002 09:55:59 -0500, David Megginson [EMAIL PROTECTED] wrote: Jon S. Berndt writes: Excellent. Is there an X-15 model? :-) Seriously, there probably won't be one from me. My main interest is civil propeller-driven planes, and after I've fixed up the DC-3 model, I'll probably do a C-310 3D model, followed by a Twin Otter (if I can manage a JSBSim or YASim aero model to go with it) and maybe a Dash-8 (ditto). I might be interested in some civil jets like the DC-9, but I'm unlikely to be making any military or NASA models (not even a Spitfire). That said, it might be possible to animate the X-15 model that we already have, assuming that the various objects in the model are named. Could you do a short 'how-to' on the model building/naming/texturing please? Then I might be able to contribute something useful at last! Actually, I've been doing quite a bit of research and have various 3-views etc but I'd like a run through of the process you use and surface naming etc. Unfortunately I'm not running FGFS ATM as various hardware and OS shufflings need to take place before it becomes worthwhile again. When that's done I might even get PPE to generate a non-zero frame rate! Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - [Post attack] crew changes would have been based on crew availability.' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 2002-02-26 at 11:58, David Megginson wrote: Tony Peden writes: What form would you need the surface positions in? Actual angles are the easiest thing for JSBSim to output (would those be useful for 3D models?), but I can see where normalized positions (-1..1) might be easier to deal with. I use angles (degrees) in the 3D models as well. Currently, I'm converting from the normalized positions, but actual angles would be great. Note that angles will have to be reported separated for each aileron, since the amount of travel up and down often differs. OK, JSBSim now reports control surface positions. I set up the following properties: /surface-positions/elevator-pos-deg /surface-positions/left-aileron-pos-deg /surface-positions/right-aileron-pos-deg /surface-positions/rudder-pos-deg /surface-positions/flap-pos-deg I believe the sign conventions are the same as those used by FGControls, but holler if they need to be different. If the elevator angle is always reported relative to the incidence angle of the horizontal stabilizer, we should be OK. I think that in most cases this will not be true, elevator will usually be reported relative to a body reference line. That's fine -- I can design markup to deal with that situation when the need arises. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Property Access
I'm in a bit of a quandary here. I know the preferred method of supplying data to properties is by binding or tying the properties to C++ methods. In order to do this with JSBSim, however, I need to do one of two things: 1) bind the properties in the JSBSim classes themselves. This is not attractive to me (and I'm sure Jon as well) because it introduces a compile time dependency on FG that would have to be ifdef'd out and would, in the long term, touch a lot of classes. (AFAICT, bind() methods *must* be members of the same class that the methods being bound to are) 2) add new data and methods to FGInterface. This is doable, but FGInterface is already quite big and unwieldy and I'm not sure what its future is. Are we just trying to eliminate the direct use of its data methods by code outside of src/FDM or are we trying to eliminate its data entirely? (We'll still need something like FGInterface to abstract the FDM objects themselves, of course) Right now, I'm avoiding the question altogether and using the pointer and copy technique. This is not as efficient as binding and requires a data member for each property in FGJSBSim, so its something I'd like to get away from doing. So, I guess the question is, is 2) a reasonable way to proceed right now or will that get in the way of future plans? -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 25, 2002 at 05:07:16PM -0800, Andy Ross wrote: No, it's not. Imagine what happens when one thread is reading it while another thread is writing to it. :-) You missed my point. First, the Vector class *is* threadsafe; check all the methods, they're synchronized. There is no way, in Java, to corrupt the state of a Vector object by modifying it in multiple threads. Okay okay, I'll admit that I'm not 100% (con)current on Java. My point was that this buys you *nothing*. You can still write all the race conditions you want by assuming that the object won't be modified from another thread. See my post about the nuclear bomb safety lock; even a perfectly threadsafe property system is susceptible to race conditions. So essentially you are saying that it is impossible to completely defend against sloppy programming and lack of documentation. Or, to put it another way, if you make something foolproof, they just come up with a better fool. :-) The point, again: *all* multithreaded code is susceptible to race conditions and deadlocks. There is *no* way around this. Obviously. But my point is that you can hide a lot of the complexity that comes with multithreading, *if* you properly define the interfaces, and don't stray from the path. Now, are you getting the point? :) Yes. We desperately need a comprehensive FG hacker's guide to the galaxy. :-) - -- Regards, I RADIS, do you? =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Mon, Feb 25, 2002 at 05:07:16PM -0800 X-S-Issue: [EMAIL PROTECTED] 2002/02/27 01:34:27 2ed0948a567b8aeaac36e3a8338e87ea -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx8KZsACgkQN880WP6HRIt/CwCfa/2C0NN+vWyjWW6/ySGccf5z 6ioAn0VfiySeXw6x1FmumRBABYrPNitL =Qx0v -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Model Performance and dc3 donuts
The new model animation is very cool so far. One thing I did notice is that there seems to be significantly greater CPU overhead when running these models as opposed to some of the msfs models I've tried. When taking off in chase view there's a great deal of interuption in the sound. Also and this might be a clue, the frame rates run almost double what the same exact view provides with the MDL models I'm using. So it seems like Dave's models are easier on the card but harder on the CPU. Note that I tried this without any animation enabled and the result was the same. Higher frame rate but more breaks in the sound (in fact more silence than sound). Also noticed the rudder control seems to be broken on the dc3 at the moment. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Model Performance and dc3 donuts
Jim Wilson wrote: Also noticed the rudder control seems to be broken on the dc3 at the moment. Blame David. :) The DC-3 is a taildragger, and therefore doesn't have a steerable wheel to turn with. Instead, real aircraft use differential braking to do this. The problem is, typical control setups don't have toe brakes on the rudder pedals. So I cheated in the initial configuration and mapped the outer (+/- 0.5-1.0) range of the rudder pedals to the brakes. I thought this was nifty and clever, but David (who spends a lot more time flying it and cares more about the model behavior) didn't like it. The DC-3 is his baby, after all. The lines are still in there, but commented out. Look in your dc3.xml file for the control mapping in the gear tags, and take out the comments. It's not really an issue with the rudder. You'll notice that the rudder works fine, once you get moving fast enough. 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] Animated C172
Rick Ansell writes: Unfortunately I'm not running FGFS ATM as various hardware and OS shufflings need to take place before it becomes worthwhile again. When that's done I might even get PPE to generate a non-zero frame rate! PPE's an impressive piece of work so far, and is great for converting among formats, but it's not usable for building a model from scratch. The currently-useful tools seem to be AC3D or (my preference) Blender, which is free-as-in-beer. I'll try to put together a mini-HOWTO in the next few days; if I don't, *please* feel free to remind me. 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] Animated C172
John Check writes: Awesome! Does gear retraction work? It can -- I have it sort-of working on my local copy of the DC-3, but (1) it's instantaneous (since it's using the /controls/gear-down property), and (2) part of the strut pokes through the top of the nacelle, so I'll have to split it into two, hinged objects. With the properties coming from the FDMs, I'll be able to animate gear and flaps much more smoothly. The fixed gear planes make gear retraction noise Yeah, that's because the state changes right at the start when the sim starts. 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] Animated C172
Tony Peden writes: OK, JSBSim now reports control surface positions. I set up the following properties: /surface-positions/elevator-pos-deg /surface-positions/left-aileron-pos-deg /surface-positions/right-aileron-pos-deg /surface-positions/rudder-pos-deg /surface-positions/flap-pos-deg I believe the sign conventions are the same as those used by FGControls, but holler if they need to be different. Thanks -- this is extremely useful stuff. Is anyone out there keeping or willing to keep an up-to-date catalog of all properties? That's something we should put on the flightgear.org site. 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] Property Access
Tony Peden writes: I know the preferred method of supplying data to properties is by binding or tying the properties to C++ methods. Actually, I've come to the conclusion that it's best just to leave them in the property tree whenever possible, and to bind only where necessary. A lot of stuff, such as control positions, doesn't really need to live in any C++ variable. Since you're copying data from JSBSim to FlightGear anyway, it shouldn't make much difference whether you copy it into the property tree or into a C++ variable. I Right now, I'm avoiding the question altogether and using the pointer and copy technique. This is not as efficient as binding and requires a data member for each property in FGJSBSim, so its something I'd like to get away from doing. Yes, that is an annoyance. Andy Ross just punted the whole question by using the fg(Get|Set)* methods directly, without saving pointers, arguing (reasonably enough) that any extra overhead gets lost during the wait for the graphics hardware to be ready for the next frame. To test this assumption, I hacked my copy of FlightGear to loop through property accesses multiple times and watched the framerate. Here's what I got, using the lower value whenever the framerate fluctuated: 1. No extra accesses: 44fps 2. 500 SGPropertyNode pointer accesses per frame: 43fps (2.3% slowdown) 3. 500 fg(Get|Set)* accesses per frame: 42fps (4.5% slowdown) 4. 1,000 SGPropertyNode pointer accesses per frame: 42fps (4.5% slowdown) 5. 1,000 fg(Get|Set)* accesses per frame: 40fps (9% slowdown) 6. 10,000 SGPropertyNode pointer accesses per frame: 27fps (39% slowdown) 7. 10,000 fg(Get|Set)* accesses per frame: 22fps (50% slowdown) The surprise here is that most of the loss comes not from the map lookup (which is skipped by the SGPropertyNode pointer access) but from the SGPropertyNode::getValue itself: at 10,000 accesses, the first 39% of the overhead comes from getValue, and only the remaining 11% from the map lookup. That's just wrong, but it's also good news, because the map lookup should be easy to fix -- I'm doing a profiling build now to help me hunt down the problem. So far, we're making far fewer than 500 property lookups per frame, so there is no noticable drop, and you may be just as well off using fg(Get|Set)* directly for now. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Interesting link
Go here: http://sicuroengineering.com/ Click on Technology and Tools Look for two familiar tools in their stable of simulation utilities. Jon -- Jon S. Berndt Coordinator JSBSim Project http://jsbsim.sourceforge.net -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
Andy Ross writes: Hrm... I'm not liking the idea of specifying explicit, absolute angles as the interface here. First off is the problem of configuration -- what are the appropriate angles? If we put them in the property interface, then both the FDMs and the model need to know. If we use abstract coordinates, only the model cares. In fact, the model doesn't have to know if the FDM does, and vice-versa -- I can just let my models trust the FDM, and any visual anomalies will indicate an flight-model bug. Also, this ties us to a particular style of surface design. Not all control surfaces simply rotate around a joint. In particular, flaps, slats, spoilers and speedbrakes often have a translational component. Should the FDM worry about this too? Good point. And then there's the fact that YASim cares nothing at all about these numbers. Adding them to the FDM would do nothing but add complexity; there is nothing useful I can do with them. I hadn't realised that YASim didn't know the deflection angles. I'm just as happy either way -- I had thought that the all the FDMs already did know the angles, it wasn't worth making the 3D models recalculate them, but it's not a lot of extra trouble (except for Tony, if he has to change his last checkin). 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
Jim Wilson writes: One thing I did notice is that there seems to be significantly greater CPU overhead when running these models as opposed to some of the msfs models I've tried. When taking off in chase view there's a great deal of interuption in the sound. I notice more interruptions at first, but then the framerate settles down to about the same -- you're right that it seems to be unrelated to the animation (which adds almost no extra overhead -- the model has to be redrawn every frame anyway). Also and this might be a clue, the frame rates run almost double what the same exact view provides with the MDL models I'm using. Yes, I designed the models (especially the C172) for low poly-counts and texture use. So it seems like Dave's models are easier on the card but harder on the CPU. That's strange. One possible problem is the propeller animations -- they use a while loop to get down to 360 degrees, and if the prop has done many rotations, it could take a while. I'll have to do some testing. How fast is your CPU? Note that I tried this without any animation enabled and the result was the same. Higher frame rate but more breaks in the sound (in fact more silence than sound). Strange -- the extra code should be skipped when there are no animated parts. Also noticed the rudder control seems to be broken on the dc3 at the moment. On the 3D model or the YASim aero model? The DC-3 model hasn't implemented the control-surface animations 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] Model Performance and dc3 donuts
Andy Ross writes: The problem is, typical control setups don't have toe brakes on the rudder pedals. So I cheated in the initial configuration and mapped the outer (+/- 0.5-1.0) range of the rudder pedals to the brakes. I thought this was nifty and clever, but David (who spends a lot more time flying it and cares more about the model behavior) didn't like it. The DC-3 is his baby, after all. Here's something I tried a while back -- rebind whatever you're using for brakes (I use the two triggers on my gamepad) to increment the brake by, say, 0.01 rather than setting it to 1.0, and bind the release event to set it to 0.0. That way, the brakes come on a little more gradually, and you can pump the button to avoid full brakes. If you have some spare joystick axes, they'd work great for the brakes. 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
On Tuesday 26 February 2002 10:14 pm, you wrote: Jim Wilson writes: One thing I did notice is that there seems to be significantly greater CPU overhead when running these models as opposed to some of the msfs models I've tried. When taking off in chase view there's a great deal of interuption in the sound. I notice more interruptions at first, but then the framerate settles down to about the same -- you're right that it seems to be unrelated to the animation (which adds almost no extra overhead -- the model has to be redrawn every frame anyway). Also and this might be a clue, the frame rates run almost double what the same exact view provides with the MDL models I'm using. Yes, I designed the models (especially the C172) for low poly-counts and texture use. So it seems like Dave's models are easier on the card but harder on the CPU. That's strange. One possible problem is the propeller animations -- they use a while loop to get down to 360 degrees, and if the prop has done many rotations, it could take a while. I'll have to do some testing. How fast is your CPU? Note that I tried this without any animation enabled and the result was the same. Higher frame rate but more breaks in the sound (in fact more silence than sound). Strange -- the extra code should be skipped when there are no animated parts. Also noticed the rudder control seems to be broken on the dc3 at the moment. On the 3D model or the YASim aero model? The DC-3 model hasn't implemented the control-surface animations yet. All the best, David I noticed that sometimes the dc3 will get into a rotation on the ground sometimes, especially after a reset. Maybe this is what he is seeing. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Model Performance and dc3 donuts
On Tuesday 26 February 2002 10:16 pm, you wrote: Andy Ross writes: The problem is, typical control setups don't have toe brakes on the rudder pedals. So I cheated in the initial configuration and mapped the outer (+/- 0.5-1.0) range of the rudder pedals to the brakes. I thought this was nifty and clever, but David (who spends a lot more time flying it and cares more about the model behavior) didn't like it. The DC-3 is his baby, after all. Here's something I tried a while back -- rebind whatever you're using for brakes (I use the two triggers on my gamepad) to increment the brake by, say, 0.01 rather than setting it to 1.0, and bind the release event to set it to 0.0. That way, the brakes come on a little more gradually, and you can pump the button to avoid full brakes. If you have some spare joystick axes, they'd work great for the brakes. All the best, David Hey David, I was thinking of getting another controller, what was that one you recommended? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
How do I create new animated models? []'s Marcio Shimoda - Original Message - From: David Megginson [EMAIL PROTECTED] To: FlightGear Development [EMAIL PROTECTED] Sent: Tuesday, February 26, 2002 10:52 AM Subject: [Flightgear-devel] Animated C172 Almost all of the major moving surfaces in the C172 are now animated: - propeller - ailerons - flaps - rudder - elevators The nosewheel still doesn't turn, but I'll add that when I get a chance. I'll probably start on the DC-3 first, though. Inevitably, I've got some of the movements backwards. Could someone check and let me know which ones? It's a lot more interesting watching the C172 in autopilot from the outside, now that you can see the surfaces move. 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
[Flightgear-devel] Animated C172
Nice addition
No need for an 'expensive' derivation
of the rotation matrix though as you can
straight forwardly write it out all at once
model.hxx
class FGAircraftModel : public FGSubsystem
{
.
struct Animation
{
enum Type {
None,
Spin,
Rotate
};
string name;
Type type;
ssgTransform * transform;
SGPropertyNode * prop;
float factor;
float position;
sgVec3 center;
sgVec3 axis;
void setRotation();
};
};
model.cxx
FGAircraftModel::read_animation (const SGPropertyNode * node)
{
...
// Get the center and axis
animation.center[0] = node-getFloatValue(center/x-m, 0);
animation.center[1] = node-getFloatValue(center/y-m, 0);
animation.center[2] = node-getFloatValue(center/z-m, 0);
animation.axis[0] = node-getFloatValue(axis/x, 0);
animation.axis[1] = node-getFloatValue(axis/y, 1);
animation.axis[2] = node-getFloatValue(axis/z, 0);
sgNormalizeVec3( animation.axis );
return animation;
}
void
FGAircraftModel::do_animation (Animation animation, long elapsed_ms)
{
switch (animation.type)
{
case Animation::None:
return;
case Animation::Spin:
{
float velocity_rpms =
animation.prop-getDoubleValue() * animation.factor / 6.0;
animation.position += (elapsed_ms * velocity_rpms * 360);
animation.setRotation();
return;
}
case Animation::Rotate:
{
animation.position =
animation.prop-getFloatValue() * animation.factor;
animation.setRotation();
return;
}
default:
return;
}
}
/* Transform to rotate an object around its local axis
* from a relative frame of reference at center -- NHV
*/
void
FGAircraftModel::Animation::setRotation()
{
float temp_angle = -position * SG_DEGREES_TO_RADIANS ;
float s = (float) sin ( temp_angle ) ;
float c = (float) cos ( temp_angle ) ;
float t = SG_ONE - c ;
// axis was normalized at load time
// hint to the compiler to put these into FP registers
float x = axis[0];
float y = axis[1];
float z = axis[2];
sgMat4 matrix;
matrix[0][0] = t * x * x + c ;
matrix[0][1] = t * y * x - s * z ;
matrix[0][2] = t * z * x + s * y ;
matrix[0][3] = SG_ZERO;
matrix[1][0] = t * x * y + s * z ;
matrix[1][1] = t * y * y + c ;
matrix[1][2] = t * z * y - s * x ;
matrix[1][3] = SG_ZERO;
matrix[2][0] = t * x * z - s * y ;
matrix[2][1] = t * y * z + s * x ;
matrix[2][2] = t * z * z + c ;
matrix[2][3] = SG_ZERO;
// hint to the compiler to put these into FP registers
x = center[0];
y = center[1];
z = center[2];
matrix[3][0] = x - x*matrix[0][0] - y*matrix[1][0] - z*matrix[2][0];
matrix[3][1] = y - x*matrix[0][1] - y*matrix[1][1] - z*matrix[2][1];
matrix[3][2] = z - x*matrix[0][2] - y*matrix[1][2] - z*matrix[2][2];
matrix[3][3] = SG_ONE;
transform-setTransform(matrix);
}
// end of model.cxx
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animated C172
On Tue, 2002-02-26 at 19:08, David Megginson wrote: Andy Ross writes: Hrm... I'm not liking the idea of specifying explicit, absolute angles as the interface here. First off is the problem of configuration -- what are the appropriate angles? If we put them in the property interface, then both the FDMs and the model need to know. If we use abstract coordinates, only the model cares. In fact, the model doesn't have to know if the FDM does, and vice-versa -- I can just let my models trust the FDM, and any visual anomalies will indicate an flight-model bug. Also, this ties us to a particular style of surface design. Not all control surfaces simply rotate around a joint. In particular, flaps, slats, spoilers and speedbrakes often have a translational component. Should the FDM worry about this too? Good point. And then there's the fact that YASim cares nothing at all about these numbers. Adding them to the FDM would do nothing but add complexity; there is nothing useful I can do with them. I hadn't realised that YASim didn't know the deflection angles. I'm just as happy either way -- I had thought that the all the FDMs already did know the angles, it wasn't worth making the 3D models recalculate them, but it's not a lot of extra trouble (except for Tony, if he has to change his last checkin). Having JSBSim calculate normalized control surface positions is the hard part -- once that's done the changes to the property tree are not hard. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Model Performance and dc3 donuts
John Check [EMAIL PROTECTED] said: I noticed that sometimes the dc3 will get into a rotation on the ground sometimes, especially after a reset. Maybe this is what he is seeing. TTYL J Yep. It does. Applying both brakes seems to stop it. The rudder to brakes binding doesn't seem to work quite right...not sure why yet. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Profiling run
Wow, good stuff. Skimming through to apply my own intuition: 6.99% ssgEntity::cull_test 5.28% ssgBranch::cull 4.85% ssgVtxTable::draw_geometry 3.42% FGHitList::IntersectLeaf 3.28% FGHitList::IntersectBranch 2.85% ssgVtxTable::getNumVertices 2.71% sgFrustum::contains 1.85% sgdPointInTriangle 1.28% sgdClosestPointToLineDistSquared 1.28% ssgSimpleState::apply These guys are all directly related to the rendering process, and are where we should expect to spend our time. The only odd one I see is ssgVtxTable::getNumVertices. I don't care how many times that's called, how does returning an integer figure in global performance? Maybe it's a profiler interaction. 8.84% sgdMakeNormal This one is notable only because it's so expensive. Sometimes, you just have to normalize something before passing it to OpenGL, and you have to eat the cost. As far as I know, all of our geometry is fixed and we don't use funny scalings. So most stuff shouldn't require per-frame normalization. This looks to me like a good spot to concentrate on; I'll bet most or all of these calls can be eliminated with a little work. 17.40% ssgMakeMipMaps 1.57% ssgSGIHeader::ssgSGIHeader[in-charge] 1.43% ssgSGIHeader::getRow These are clearly related to texture loading. How long did you run your profiler for? If it was just for a few seconds, then these might be showing the time spent in initialization and not in the routine frame-to-frame running of the program. Certainly, parsing and generating textures is going to be expensive at startup. 2.14% calc_magvar This has me stumped too. First, why on earth is it being called so much? I'd think once per frame would be more than sufficient. Second, this is (or should be) an rather cheap computation. A few hundred CPU cycles at most. Weird. 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] Virtual Cockpit!
I spent most of today working on a virtual cockpit interface for the
panel, and I'll be damned, it works!
What the attached patch does is map your panel definition onto a (non
z-buffered) quad in front of your face. You can twist the view around
and see it move in the appropriate ways.
Apply the patch (let me know if folks need help with that step), and
then set the /sim/virtual-cockpit property to true. You can do this
on the command line with --prop:/sim/virtual-cockpit=1, or via the
property picker. Bind it to a key for fast toggling if you like.
The default bindings don't allow for panning the view, so you'll
have to modify yours. These are the mappings to my joystick's hat
switch, for those who need hints:
axis n=6
descView Direction/desc
low
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/view/goal-offset-deg/property
step type=double1.0/step
/binding
/low
high
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/view/goal-offset-deg/property
step type=double-1.0/step
/binding
/high
/axis
axis n=7
descView Elevation/desc
low
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/view/goal-tilt-deg/property
step type=double1.0/step
/binding
/low
high
repeatabletrue/repeatable
binding
commandproperty-adjust/command
property/sim/view/goal-tilt-deg/property
step type=double-1.0/step
/binding
/high
/axis
While the current implementation is happy with just plastering the
panel's notion of screen into the 3D world, this is actually more
general. Each panel can, in principle, have it's own coordinate
system, and you could build a cockpit out of a bunch of them. The
mapping is specified by providing a 3D coordinate for three corners of
the quad the panel should be mapped to; this should be pretty simple
to work with.
All that's needed for a perfectly general solution is a convention on
where to store the information (a cockpit xml file, or put it in the
aircraft -set file, or...), and some work on the panel's coordinate
system conventions (some of which don't coexist very nicely with a
generalized 3D environment). Combine that with a plib model for the
non-panel interior of the cockpit, and we're golden.
I'm actually really pleased with this. It worked better and more
quickly than I could have imagined, and impact on the surrounding code
is quite light -- a few property tests only. But some stuff is still
missing:
+ No equivalent work was done to the HUD, so it still displays
incorrect headings when the view changes. The use of pixel
coordinates deep in the HUD code is going to give me fits doing the
port, I sure. It's not nearly so well put together as the panel
(where I just changed the setup code -- none of the rendering code
changed at all).
+ I forgot that the panel was clickable. :) Input events still have
the screen coordinates, which essentially kills the interactivity
when in virtual cockpit mode. This won't be hard to fix; it's only
broken because I forgot the feature existed.
And one note about the implementation choice: to get away from the
inevitable near clip plane issue, the virtual cockpit renderer simply
disables the z buffer. This means that cockpits built using these
panels need to be z-sorted, which isn't too hard since they are static
geometry. It also means that no two virtual panels can ever be
allowed to interpenetrate. No biggie.
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)
? src/GUI/prop_picker.cxx-patch
Index: src/Cockpit/panel.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.59
diff -u -r1.59 panel.cxx
--- src/Cockpit/panel.cxx 19 Feb 2002 22:54:17 - 1.59
+++ src/Cockpit/panel.cxx 27 Feb 2002 07:26:30 -
@@ -57,7 +57,6 @@
# undef NONE
#endif
-
// Local functions.
@@ -84,10 +83,11 @@
bool
fgPanelVisible ()
{
- return ((current_panel != 0)
- (current_panel-getVisibility())
- (globals-get_viewmgr()-get_current() == 0)
- (globals-get_current_view()-get_view_offset() == 0.0));
+return (fgGetBool(/sim/virtual-cockpit) ||
+ ((current_panel != 0)
+(current_panel-getVisibility())
+(globals-get_viewmgr()-get_current() == 0)
+(globals-get_current_view()-get_view_offset() == 0.0)));
}
@@ -330,19 +330,23 @@
y_offset += y_adjust;
}
- glMatrixMode(GL_PROJECTION);
