[Flightgear-devel] Initial conditions at reset
I just want to gently push this back to top, since I figured out more strange behaviours which I really dont know the cause of... First, as I didnt notice before, the plane is hovering a few feet above the runway at start as soon as I specify an initial velocity. If I specify the initial velocity as zero, it stands on the ground, just as normal. By using the --notrim option in the command line, it shows up a few inches below the runway (similar as it is when specifiying --fdm=NULL). Whats the reason for this? Could it be somewhee in the trimming code? Second, I m still not seeing clearly in the way the reset is processed... Could anyone give me a hint as to where the FDM is initialized during the reset process? Is the Initialize()-function in the FGState.cpp file still involved at all? And if it is not, where does FG take its starting values from and where could I tell it to load my initial conditions at reset, too? (while running FG with --notrim option) Any thoughts or help are much appreciated indeed. Best, Thomas Hello, I want to start FlightGear with a bunch of Initial Conditions Settings and I noticed that they dont seem to be loaded when restarting the simulator with File-Reset. It rather looks like FG is taking the values for pitch, alpha, and so on off of the last session, i.e. if I crashed the plane almost in a 90 deg angle to the earth and then press reset, it starts with the plane heading towards ground in almost a 90deg angle. By pressing pause at startup and comparing the values in the property tree I indeed figured out that the values are exactly the same. I am using FG 0.9.10 release version and noticed this behaviour with the c172 and f16. I am loading the IC in from an external input file. I therefore modified the code in FGState.cpp, in the Initialize() function with a rather simple routine to read in the values and used the FGIC-SetBlahBlah() method of the FGInitialConditions class in order to save them. All works fine as long as I am NOT specifying --notrim in the command line. As soon as I specify this option, the above described behaviour occurs. Anyone might be able to shed some light in this matter? Where can I find the functions that are responsible for the reset process in the code? Could it be that FG restarts different than its actual starting process is? Thanks a lot for your help. Best, Thomas - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Initial conditions at reset
First, as I didnt notice before, the plane is hovering a few feet above the runway at start as soon as I specify an initial velocity. If I specify the initial velocity as zero, it stands on the ground, just as normal. By using the --notrim option in the command line, it shows up a few inches below the runway (similar as it is when specifiying --fdm=NULL). Whats the reason for this? Could it be somewhee in the trimming code? If you are not trimming, then the aircraft may be placed initially at an inappropriate altitude, considering where it's CG is defined, and where the landing gear are defined to be touching. I'm assuming this is for some JSBSim aircraft. The altitude that the aircraft is initially placed at should be the vertical distance from the CG to the landing gear location. Second, I m still not seeing clearly in the way the reset is processed... Could anyone give me a hint as to where the FDM is initialized during the reset process? Is the Initialize()-function in the FGState.cpp file still involved at all? And if it is not, where does FG take its starting values from and where could I tell it to load my initial conditions at reset, too? (while running FG with --notrim option) Have you looked inside JSBSim.cxx? That's the interface between FlightGear and JSBSim. Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Initial conditions at reset
Thank you for your help Jon, Is there a way to fix this problem with the altitude on the runway? And yes, I am using JSBSim planes. Yes I did take a look in JSBSim.cxx - but without success. I tried to set the initial conditions within the FGJSBSim()-function as well as within the init(9 function - none of it worked. Where should I place it? Best, Thomas [EMAIL PROTECTED] escribió: - Para: FlightGear developers discussions flightgear-devel@lists.sourceforge.net De: Jon S. Berndt [EMAIL PROTECTED] Enviado por: [EMAIL PROTECTED] Fecha: 05/12/2006 13:49 Asunto: Re: [Flightgear-devel] Initial conditions at reset First, as I didnt notice before, the plane is hovering a few feet above the runway at start as soon as I specify an initial velocity. If I specify the initial velocity as zero, it stands on the ground, just as normal. By using the --notrim option in the command line, it shows up a few inches below the runway (similar as it is when specifiying --fdm=NULL). Whats the reason for this? Could it be somewhee in the trimming code? If you are not trimming, then the aircraft may be placed initially at an inappropriate altitude, considering where it's CG is defined, and where the landing gear are defined to be touching. I'm assuming this is for some JSBSim aircraft. The altitude that the aircraft is initially placed at should be the vertical distance from the CG to the landing gear location. Second, I m still not seeing clearly in the way the reset is processed... Could anyone give me a hint as to where the FDM is initialized during the reset process? Is the Initialize()-function in the FGState.cpp file still involved at all? And if it is not, where does FG take its starting values from and where could I tell it to load my initial conditions at reset, too? (while running FG with --notrim option) Have you looked inside JSBSim.cxx? That's the interface between FlightGear and JSBSim. Jon - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs + gaia (google earch client) = moving map
* Melchior FRANZ -- Saturday 25 November 2006 12:41: * Melchior FRANZ -- Thursday 23 November 2006 15:47: Bright future ahead. (Until Google's attorney rings, that is. ;-) Which was yesterday: http://gaia.serezhkin.com/ :-( The good news: the author did the only reasonable thing: he removed Google Earth support and added NASA World Wind support. :-) SF Project page: http://sourceforge.net/projects/gaia-clean/ ChangeLog: http://sourceforge.net/project/shownotes.php?group_id=183522release_id=468497 Homepage: http://gaia.serezhkin.com/ m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to drive the Flight Gear airplanes by radar data
On 12/4/06, 唐勇 wrote: Hi,the Flight Gear can be drived by Keyboard,Mouse,Joystick etc.But my question is that how can I drive the Flight Gear by my ATC radar data.Myradar data contains the flight position(lon,lat,alt) and oritation(pitch,roll,heading).I want to know how to input these data to the Flight Gear,and make many airplanes fly automatically. Thank u very much!!! I have done some work capturing IMU/GPS data from a live UAV and playing it live (or replaying it later) in FlightGear ... optionally with the multiplayer features turned on so we can track the uav in google maps/earth. There are a variety of ways you could pull this off, but here is one suggestion. I have written/adapted a couple utilities that can load a saved data file or read the data in live from a serial port and then pass it along to FlightGear. This code lives in the FlightGear CVS repository under .../source/utils/GPSsmooth/ (the naming of this directory doesn't exhibit a lot of forethought, but that's what it is right now.) If you wanted to use this option, you would mostly likely have to adapt the MIDGsmooth or UGsmooth application to parse your own data format, but everything else should pretty much be the same. If nothing else you can explore this directory to get a few ideas. You could probably reformat the data so it could be loaded and replayed by flightgear directly, but I haven't fiddled with that end of flightgear in a *long* time so someone else might be able to offer more current advice for doing that. Regards, Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on Linux.com
* On 12/4/06, Joe Barr wrote: http://www.linux.com/article.pl?sid=06/11/20/0533247 Now announced on linuxtoday.com. May provoke some comments there: http://www.linuxtoday.com/news_story.php3?ltsn=2006-12-05-025-26-RV-GM-SW m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to drive the Flight Gear airplanes by radar data
Curtis Olson schreef: On 12/4/06, *唐勇* wrote: Hi,the Flight Gear can be drived by Keyboard,Mouse,Joystick etc.But my question is that how can I drive the Flight Gear by my ATC radar data.My radar data contains the flight position(lon,lat,alt) and oritation(pitch,roll,heading).I want to know how to input these data to the Flight Gear,and make many airplanes fly automatically. Thank u very much!!! I have done some work capturing IMU/GPS data from a live UAV and playing it live (or replaying it later) in FlightGear ... optionally with the multiplayer features turned on so we can track the uav in google maps/earth. There are a variety of ways you could pull this off, but here is one suggestion. I have written/adapted a couple utilities that can load a saved data file or read the data in live from a serial port and then pass it along to FlightGear. This code lives in the FlightGear CVS repository under .../source/utils/GPSsmooth/ (the naming of this directory doesn't exhibit a lot of forethought, but that's what it is right now.) If you wanted to use this option, you would mostly likely have to adapt the MIDGsmooth or UGsmooth application to parse your own data format, but everything else should pretty much be the same. If nothing else you can explore this directory to get a few ideas. You could probably reformat the data so it could be loaded and replayed by flightgear directly, but I haven't fiddled with that end of flightgear in a *long* time so someone else might be able to offer more current advice for doing that. Regards, Curt. Wouldn't it be possible to use either the 'Generic' protocol over a socket / serial link or convert the data coming from the ATC console into NMEA format? That way FG can read it without any problems. (I have yet to try my own GPS receiver with FG but I'm certain it will work) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] helplinefoo\nbar/line/help
line statements in a help block are now split at new-lines. So it's no longer necessary to write every line in extra line.../line tags. This should be enough (full example): help titleThis is my little aircraft/title key namec/name desclet attendant make coffee/desc /key line!-- leading spaces aren't stripped yet :-/ -- some meaningless lines /line text some longer text in a scrollbox /text /help Note the use of keyname/namedesc/desc/key for key definitions. Those should *ALWAYS* use such a block, and not informally be mixed into normal text. m. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Linux - Solaris AMD64-SPARC64 interfacing
Hi Vikas, Vikas N Kumar wrote: I tried for a while to build OpenSceneGraph on Solaris 7 with my version of X11 and using GNU compilers but there was something wrong with X11 and using Sun's OpenGL. So I reinstalled Solaris 10 and have now installed the Sun Studio 11 Compilers as well. I will restart compiling everything again -- plib, OpenThreads, Producer and OpenSceneGraph, Simgear and finally FlightGear. You might rest at least one day or so, I'm still waiting for Don Burns to put yet another patch against his Producer 'makedefs' files into CVS, that allows building on SunOS with SunStudio. He already added several changes that I sent him so I think it'll be just a matter of time, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG point lights
Hi Tim, I did not find the time to look into that this weekend. These evenings are my friend. On Thursday 30 November 2006 10:03, Tim Moore wrote: I'm not sure about faster but, as far as I can tell, equivalent. By the way, it would be very nice to have some more timing information available than just the frame rate. I don't know if the easiest way to get there is to move to Producer so we can get its nice rendering stage statistics, wait for Robert to duplicate that in his new osgViewer stuff, do it ourselves, or what. Yep, that must happen at some time that we have that cull and draw times on the screen ... I do not want to remove the old implementation that was happening completely on the GPU in favour to an CPU based one if we end up slower. Anyway, can we keep the old implementation instead of just a plain OpenGL point based one. That means the old one that used triangles that are backface culled and draw points for the front side where two of them are transparent? I don't mind adding the old implementation back in as an option, except for the VASI lights, where it really would have no advantage over the OSG lights. One would lose some features, such as point size scaled by intensity, fading alpha with distance, and blink sequence animations for the approach lights. No, I do not think that we loose such features completely, we just need to implement exactly what we need ourselves. The VASI in the osgSim implementation has some problems. The size of the lights are something that I do not comment on here. The just need to be adjusted somehow. But I have objections in the basic way it is done. We had a smooth transition phase where the lights went smooth from red to white. The osgSim one just switches hard. I do also not see how the osgSim api will allow to change the color of a point in a smooth way. We can just render both in a transition area and hope that blending does our trick - but that is a really bad idea IMO. So especially for the vasi I do definitely want to use an own implementation that has nothing to do with osgSim. Also the current osgSim implemntation does directional lights with a hard switch off when the eye point moves beyond 90 deg to the normal. The previous implementation faded away nicely. That could be done with osgSim's sector but I still wonder if it is then slower... The only place where I can see osgSim as a *real* benefit is for the rabbit time sequences. Given that I would like to have a common appearance for all lights I would favor doing all of them ourselves. Like I stated before in some private mails I would like to have the osg version only as an alternative to the old implementation if it is faster than the GPU/triangle based one. May be not exactly the old implementation but an implementation that does nothing on the CPU but does all lightging decisions on the GPU. I would like to see some comparisons between the two approaches on a low-end machine. You may be overestimating the cost of the CPU based approach and underestimating the costs of triangle approach. As I said in private email, the old approach uses a fairly exotic rendering path -- polygons rendered in point mode with a texture environment -- which very well may be done on the CPU on a low-end machine. I don't think that I overestimate that - we just have plenty of those lights. What we definitely gain if we put such computations onto the GPU is additional CPU time where we can do something we cannot do on the GPU - not yet, but definitely then when we have cull and draw on an other cpu. ... hold on, I see, this also holds if the draw cpu will compute the light intensities instead of waiting for the gpu to do that. In the single threaded case we gain nothing with this argument ... Hmm ... Yes, I think that is a great project, but more work than I have time for right at the moment. It would be good for people to learn about OSG's support for shading programs *hint*hint* :) I will send you my hackery on that today evening. For that we still need some factory methods that will provide now the old implementation or the osg::LightPoint based one and later when I have the time to merge my tests into simgear the shader based one. So we need to he able to decide between implementations based on capabilities of the GPU and settings from the user anyway. Can we set up together such an infrastructure and put the old triangle based approach as other alternative below? We? :) Seriously, I would be happy to look at getting the OpenGL extensions available from OSG and making that available to fg in an elegant way, but goes way beyond to scope of light points, so for now exposing the choice to the user is probably the best way. Automatically benchmarking the user's machine and putting it into slow /fast categories would be an interesting project too. Hmm. I believe that what osg does for us in this area is silently switch of
