Re: [Flightgear-devel] John's position on combat simulation;
John Wojnaroski wrote: Martin Spott wrote: Sorry, John, this has nothing to do with selective morality - as you allege. After reading these lines I'd say you have severe difficulties telling the difference between flying and shooting/killing. Ooo, I don't think so. To make understanding it easier: Many/most of the old but also the modern warbirds are fascinating aircraft from a technical as well as from an aviatic point of view - no doubt. Yet this is significantly different from actually performing the shooting at some other aircraft or dropping bombs. Ahhh, so the basis for acrobatic manuevering was...and the reason you need to put 9G's on your body is. Your first point is quite correct, but again fly them to you heart's content and DON'T complain if others wish to do the same and simulate combat. That is all I am saying, Yes, I _do_ domplain ! Here's your missing link: The simple reason that an aircraft was originally _built_ for shooting and dropping bombs doesn't justify to really _perform_ this action in a simulation as well. You're taking a way too simple route here, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Bill Galbraith wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Seifert Sent: Saturday, May 12, 2007 10:38 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] More ideas on dogfighting -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 James Palmer wrote: In your experience, Harald, what has been the approximate ratio of FDM vs Graphics vs remainder code on CPU time? Has anyone done work on clocking the various subroutines in FG to determine this? (Perhaps I underestimate the CPU time required of the FDM?) You could simply run stand-alone JSBSim (http://www.jsbsim.org) to see, how much CPU a FDM needs. I'd guess that Yasim lies in the same range. Nine I think that was investigated a few months ago. JSBSim FDM took only a couple percent of the CPU, or course depending on your hardware and what you were drawing. I don't think it's anything that you need to worry about. BIll I don't have fresh number but the time of a standalone JSBSim takes has nothing to do with the time the FDM takes in FG. First it depends on how many times you run it per second (in FG the default is 120 Hz). Second in addition to the fdm itself we are computing some ground intersection. And since the world geometry is very badly organized in FG this can take some non negligeable time (but we should see a great improvment in the intersection code with the osg branch). Now if the server is doing the FDM computation it's obvious that there is no need to do that 120 times per second because the data can not be send at that rate. How many loops does the mp server need to do per second ? 10 ? 20 ? At that frequency you could handle 100 clients with no problems. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [BUG] FG - CVS - HEAD
Hi, This morning's update of fg-cvs fails to compile under MSVC8 with the following error: error C2491: 'terminate' : definition of dllimport function not allowed Flightgear-cvs\source\src\Main\bootstrap.cxx147 The attached patch fixes it (but it may not be the best way of doing it). Vivian bootstrap.diff Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable
On Saturday 12 May 2007 22:01:42 Matthias Boerner wrote: Hallo Georg, I have done a fresh checkout of OSG, PLIB, SimGear and FlightGear today at 3 pm in the afternoon. Everything compiled without a problem. But I don't realize a drop in frame rates. But in contrast to my last checkout of 24th April I get about 10-20 frames more. So I think everything is fine with OSG. Regards Matthias Well, on this evidence I just done a completed update on OSG/SG/FG... and back I go to 5 fps at KSFO. Also now I do not see 'sea' outside the tile I have - here is the scene at FHAW (Ascention Is. right in the middle of the Atlantic). You will also see I have 13 fps here in the PC - before I used to get upward of 43 FPS here. http://www.nick.ukfsn.org/fg/issue.png Something is wrong. Nick - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] John's position on combat simulation;
Am Sonntag, den 13.05.2007, 07:02 + schrieb Martin Spott: John Wojnaroski wrote: Martin Spott wrote: Sorry, John, this has nothing to do with selective morality - as you allege. After reading these lines I'd say you have severe difficulties telling the difference between flying and shooting/killing. Ooo, I don't think so. To make understanding it easier: Many/most of the old but also the modern warbirds are fascinating aircraft from a technical as well as from an aviatic point of view - no doubt. Yet this is significantly different from actually performing the shooting at some other aircraft or dropping bombs. Ahhh, so the basis for acrobatic manuevering was...and the reason you need to put 9G's on your body is. Your first point is quite correct, but again fly them to you heart's content and DON'T complain if others wish to do the same and simulate combat. That is all I am saying, Yes, I _do_ domplain ! Here's your missing link: The simple reason that an aircraft was originally _built_ for shooting and dropping bombs doesn't justify to really _perform_ this action in a simulation as well. You're taking a way too simple route here, sorry Martin, but you didn't give any argument other than you don't like it. It is perfectly alright and a valuable input to express your concerns and judging from the reactions I think everybody on this list is ready to respect them. Democracy allows each individual the right to pursue his/hers interests as long as nobody is harmed. Same with the GPL. If James likes to implment combat he does nothing wrong. It is simply unfair and by no law, or terms of the GPL justified to flame at him just because you don't like what he wants (or better: thinks about) to do. Regards Detlef Martin. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
I think that was investigated a few months ago. JSBSim FDM took only a couple percent of the CPU, or course depending on your hardware and what you were drawing. BIll I didn't see that one. In any case, I just made a 200 second scripted test run, which took 42 seconds on my 2 GHz clunker. The execution time took about 2% of the actual corresponding real time. Also, I ran JSBSim standalone in realtime mode, and it took about 2% of the CPU. Or, so I thought. I watched the CPU usage when I wasn't running JSBSim, and it was no different: still 2% of the CPU was being used. :-) Jon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable
On Sat 12 May 2007 23:01, Matthias Boerner wrote: Hallo Georg, I have done a fresh checkout of OSG, PLIB, SimGear and FlightGear today at 3 pm in the afternoon. Everything compiled without a problem. But I don't realize a drop in frame rates. But in contrast to my last checkout of 24th April I get about 10-20 frames more. So I think everything is fine with OSG. Regards Matthias Hello Mathias, Your 10-20 frames more, seems to me very poor regarding the comparison, i get from 10 to 15 fps with the recent one and a now with that old one i recover from 60 to 85, which is a huge difference. BTW: with the same FG version built PRE_OSG_PLIB_20061029 i get a lower frame rate from 55 to 75 with every options activated (3D clouds, Shadoww, .) Theses differences indicate that FG OSG could be equivalent to FG PLIB, probably better. That dramatic loss of performance with the lasts OSG version, is not normal. Regards -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New Architecture for Flightgear
Hi, Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. My thoughts are that flightgear divides naturally into four major sub-system modules: a) FDM (jsbsim is already standalone) b) cockpit input and output (ie joysticks/pedals/throttles/switches etc and displays/lights etc) c) external view (with all the graphics rendering for forward/back/sides etc) d) motion system (probably not many users!) The main issue is inter-processor communication between modules ie between modules multi-threaded on multi-processor computers,between modules in processes on same computer,between modules in processes on networked computers. I have been looking at the idea of using some database containing the property lists which would be read and updated asynchronously by the various modules at whatever frame rate is suitable for the module (not necessarily its internal framerate) My first thought was LDAP, although using a directory service as a database is often frowned upon! I am familiar with OpenLDAP and it looks like an LDAP schema can be derived fairly easily from the property list or better still from the XML schema (maybe programs exist to do this already?). There may be problems with data rates etc so maybe it will need MySQL or somesuch but that seems an overkill for the functionality needed. The advantages of the database are that proprietry (ie FG/jsbsim) protocols are not needed as standards already exist and multi-process (many to one and one to many) synchronisation etc is already built in to the database API. Also there are the search facilities and other directory and database functions that can be made use of. Also I have had a look at native XML databases and although it is nice to be able to write/read and search directly in XML, if they are based on JAVA (such as Opensource Xindice), they are pitifully slow compared with what is required (there is some interesting work published on the Web comparing native XML data base with MySQL with all its problems of representing the XML data). We can experiment on various communication ideas without restructuring flightgear by simply running three instance (forget motion system for now!). One instance running FDM with no panel display and no outside view, second instance running no FDM or view and only panel, and third instance running no FDM or panel and only outside view. An advantage of this modularisation and inter-process communication is that as flightgear is multi-platform we can select the optimum platform for each module even utilising RTOS where needed or maybe specialist graphics engines. If anyone has any comments and other ideas etc I would be very interested. cheers Jim - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Hi Jim, Jim Campbell wrote: Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. Indeed, the idea of cutting FlightGear into modules is not a new one and has been floating around way before this nice new arcitecture paper came up that everybody takes as a reference. Using some sort of networked database is a nice start and definitely honours the idea of portability - yet I don't see such thing that is capable of handling data at a rate that meets the requirements of FlightGear. OpenLDAP as well as MySQL are very bad at handling a high rate of concurrent read/write requests - they miss the target by a huge distance, they both are faaar to complex (even MySQL :-) for such a task. Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Martin Spott wrote: Hi Jim, Jim Campbell wrote: Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. Indeed, the idea of cutting FlightGear into modules is not a new one and has been floating around way before this nice new arcitecture paper came up that everybody takes as a reference. Using some sort of networked database is a nice start and definitely honours the idea of portability - yet I don't see such thing that is capable of handling data at a rate that meets the requirements of FlightGear. OpenLDAP as well as MySQL are very bad at handling a high rate of concurrent read/write requests - they miss the target by a huge distance, they both are faaar to complex (even MySQL :-) for such a task. Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) Cheers, Martin. One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Harald. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable
Hello Gerard, Hello Mathias, Your 10-20 frames more, seems to me very poor regarding the comparison, i get from 10 to 15 fps with the recent one and a now with that old one i recover from 60 to 85, which is a huge difference. I get an performance increase from about 80/90 fps to 100/110 fps. My average frame rate is about 90/100. So in my environment which is probably not that different to yours (except hardware) I do not have a performace decrease with OSG that some people and you described here. I don't use any fancy optimization parameters: -march=k8 -O2 -pipe, that's all. What is your environment, and what are your compile parameters? Regards Matthias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] John's position on combat simulation;
Martin Spott wrote: John Wojnaroski wrote: Martin Spott wrote: Sorry, John, this has nothing to do with selective morality - as you allege. After reading these lines I'd say you have severe difficulties telling the difference between flying and shooting/killing. Ooo, I don't think so. To make understanding it easier: Many/most of the old but also the modern warbirds are fascinating aircraft from a technical as well as from an aviatic point of view - no doubt. Yet this is significantly different from actually performing the shooting at some other aircraft or dropping bombs. Ahhh, so the basis for acrobatic manuevering was...and the reason you need to put 9G's on your body is. Your first point is quite correct, but again fly them to you heart's content and DON'T complain if others wish to do the same and simulate combat. That is all I am saying, Yes, I _do_ domplain ! Here's your missing link: The simple reason that an aircraft was originally _built_ for shooting and dropping bombs doesn't justify to really _perform_ this action in a simulation as well. You're taking a way too simple route here, I'm a simple guy... Hmmm, that seems a bit illogical. Without the primary function or purpose for combat the aircraft would not have been built in the first place. So if you feel that combat action, real or simulated, are not justified, don't build the vehicle or item that fulfills it's prime function in the first instance. In other words, why build something if you don't intend to use it for the purpose it was built. John W. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Harald JOHNSEN schreef: Martin Spott wrote: Hi Jim, Jim Campbell wrote: Some discussions have already taken place on JSBsim devel mailing list regards communication between modules of flightgear. Indeed, the idea of cutting FlightGear into modules is not a new one and has been floating around way before this nice new arcitecture paper came up that everybody takes as a reference. Using some sort of networked database is a nice start and definitely honours the idea of portability - yet I don't see such thing that is capable of handling data at a rate that meets the requirements of FlightGear. OpenLDAP as well as MySQL are very bad at handling a high rate of concurrent read/write requests - they miss the target by a huge distance, they both are faaar to complex (even MySQL :-) for such a task. Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) Cheers, Martin. One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Harald. Real-world flight simulation systems, as used in flight training devices, have been using this tactic for decades. A flight simulator as supplied by a commercial producer of training devices, has been split into a set of large functional blocks, each of them consisting of different modules: * Flight dynamics block -- consists of a set of systems that handle everything related to the aircraft's aerodynamic profile and the forces acting upon it. It does know nothing about scenery (aside from terrain elevation data, to detect ground movement), and knows nothing about the aircraft's systems. The only thing it knows about the aircraft is basically a 3D model with aerodynamic description, the position of the A/C's control surfaces and other extensions (landing gear, doors, spoilers), and the user-induced forces on the aircraft (engine thrust). It does a very good job at handling flight dynamics, and is fitted with a heavy CPU. Mathematical power is more important here than memory. * Systems block -- keeps track of everything happening inside the aircraft. From the engines to the air conditioning, everything that can't be connected as real avionics is simulated inside this unit. Most of the aircraft-specific descriptions are found here. * Visual system -- The visual system only needs to receive position and orientation data, and possibly the first and second derivative of it. From that it renders the (usually multichannel) outside view for projection onto the simulator's front screen. All of the scenery data is stored here. These three functional big blocks communicate over a high-speed network. Mostly, the units are built in dual-redundant sets to cope with eventual failure. Most of the cockpit systems in a real simulator consist of real avionics. ARINC buses connect the real aircraft avionics (like the FMC, RMU's, and most of the display systems) to the simulator as if they connected to an actual aircraft. The simulator's systems block takes the place of the aircraft's IRS, GNS, ADC, VOR and other navigation systems. Splitting up FlightGear into multiple functional units is something I'm really voting for. Especially, when you use a well-defined interface for every module. That way you can create a plugin-driven system that is easily extended upon, and could easily be split up physically using multiple machines across a network. I'm more into developing glass cockpits myself, but I'm also interested in creating a complete full-mission flight simulation suite. Especially since that would attract commercial funders (aviation industry companies like CAE, FlightSafety and Boeing) and possibly achieve FAA certification. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Harald JOHNSEN wrote: One should not forget that FG has allready some networking capacity. This alone has allready allowed ppl to split fdm and rendering on several machines. Perhaps there is something to reuse here. Well, we've been driving two 'external' displays on last years LinuxTag exhibition using the 'generic' protocol. We were surprised to encounter a significant performance hit on the master machine serving two clients at 20 Hz. Throttling the thing down to 10 Hz made the whole setup flyable again. Yet this might look different if such master does nothing but FDM output via network, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable
On Sun 13 May 2007 17:41, Matthias Boerner wrote: Hello Gerard, Hello Mathias, Your 10-20 frames more, seems to me very poor regarding the comparison, i get from 10 to 15 fps with the recent one and a now with that old one i recover from 60 to 85, which is a huge difference. I get an performance increase from about 80/90 fps to 100/110 fps. My average frame rate is about 90/100. So in my environment which is probably not that different to yours (except hardware) I do not have a performace decrease with OSG that some people and you described here. I don't use any fancy optimization parameters: -march=k8 -O2 -pipe, that's all. What is your environment, and what are your compile parameters? Regards Matthias Hello Mathias, Right, your FPS has nothing to do with mine The Computer which run FG is: With LInux fedora core 5 Cpu AMD Athlon XP3200 (32 bit) Memory 3 GB DDR dual channel 3200 GPU NVIDIA 7800GS 500MZ Memory 512 Mo DDR3 700MZ AGP 8 driver 1.0-9755 SG built with ./configure --prefix= FG built with /configure --prefix= --with-simgear= --enable-sdl FG-OSG run with --geometry=1800x1440 --bpp=32 --enable-real-weather-fetch --timeofday=afternoon --prop:/sim/startup/save-on-exit=false Nothing else significant BTW: no dual cpu, no PCI-e graphic card Regards -- Gérard - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AN-225 3D-cockpit
Hi all! Im currently working on a 3D-Cockpit for the Antonov AN-225; if someone else does, please tell me for not having two people work on the same thing! I havent found much information about the AN-225 (or the 124), except photos, so please let me know, when you have some knowledge about this a/c (Electrics, Brakes, Hydraulics, speaking Russian, whatever). My Russian got a little rusty (cough...), and so I cant identify all instruments on the cockpit-photos. Would be nice if someone could help, but theres no hurry Ciao, Adrian Viel oder wenig? Schnell oder langsam? Unbegrenzt surfen + telefonieren ohne Zeit- und Volumenbegrenzung? DAS TOP ANGEBOT JETZT bei Arcor: günstig und schnell mit DSL - das All-Inclusive-Paket für clevere Doppel-Sparer, nur 39,85 inkl. DSL- und ISDN-Grundgebühr! http://www.arcor.de/rd/emf-dsl-2 - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote: Now if the server is doing the FDM computation it's obvious that there is no need to do that 120 times per second because the data can not be send at that rate. How many loops does the mp server need to do per second ? 10 ? 20 ? At that frequency you could handle 100 clients with no problems. Harald. As far as I know, the FDM frequency controls the fidelity of the simulation. It has no relationship with the I/O frequency. Since the FDM takes so little CPU power, the amount clients that can be served should be dependent on the bandwidth. Ampere - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
Martin Spott schreef: Well, we've been driving two 'external' displays on last years LinuxTag exhibition using the 'generic' protocol. We were surprised to encounter a significant performance hit on the master machine serving two clients at 20 Hz. Throttling the thing down to 10 Hz made the whole setup flyable again. Yet this might look different if such master does nothing but FDM output via network, Martin. Keep in mind that the Generic protocol is one of the most inefficient for real-time data communication, as it communicates via plain text. If you want something that goes over 100Hz, you need to think of a binary system. For an FDM connecting to a visual system it's basically nothing more than 18 floating point values (x,y,z, rotation xyz and first and second order derivatives for smoothing) resulting in a 72-byte data packet, which is doable. To put it into perspective, the same 18 values would take up at least 200 bytes (characters), not counting newlines and frame separators, as each floating point would need at least 10 characters to be represented at least a bit accurately, and still you have to cope with international issues (comma vs. decimal point) when you're using the generic protocol. Plus a terrible loss in resolution as the max. resolution for a plain text channel can be at most to the 10th decimal place (at least, in standard format) where a double floating point can carry much more accurate data. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Architecture for Flightgear
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin Spott wrote: Personally I think some thing like distributed shared memory might fill the gap. I've been doing some literature research on this topic several years ago, the idea looks pretty promising and different OpenSource implementations already have been around by that time - but I would not like to be the one to debug such a tricky beast :-) A pretty easy and fast implementation could be based on one of the new single threaded, event based HTTP servers like LigHTTPD. The property tree would map nicely to URL space, the data could be stored in memory, by a simple custom handler module. This would take care of concurrency issues and be very fast as HTTP is a simple protocol. Server push could take care of listeners, but obviously tied properties would have to go. But the latter have been a source of problems for modelers anyway, since one cannot attach listeners to them. I wonder if their performance benefit is really worth the hassle. And it would provide HTTP access to properties for free, allowing to dump the correspondent code in FG :) Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGR0Od1QuEJQQMVrgRCBplAKCHzW5h+6LiVWcefbdSFp6YxeN+sACfbHsz f3TynbUWntduxHFugDOwa4s= =Xw/z -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest OT/OSG/SG/FG unusable
Hello Gerard, The Computer which run FG is: With LInux fedora core 5 ok, I have fedora core 6 Cpu AMD Athlon XP3200 (32 bit) Memory 3 GB DDR dual channel 3200 CPU AMD Athlon 64 4000+ (no dual core) Memory 2 GB ECC DDR dual channel 3200 GPU NVIDIA 7800GS 500MZ Memory 512 Mo DDR3 700MZ AGP 8 driver 1.0-9755 GPU NVIDIA 6600GT 500 MHz Memory 128 DDR3 1000MHz PCI-E driver 1.0-9755 SG built with ./configure --prefix= Same with me, except all FG stuff is in my home directory, so I have to use --with-plib, etc. FG built with /configure --prefix= --with-simgear= --enable-sdl I do not use SDL because freeglut is fixed FG-OSG run with --geometry=1800x1440 --geometry=1280x1024 --bpp=32 dito --enable-real-weather-fetch --timeofday=afternoon --prop:/sim/startup/save-on-exit=false I don't use this ones... But: --enable-game-mode and the already mentioned compiler flags. Regards Matthias - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Harald Sent: 13 May 2007 18:19 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] More ideas on dogfighting Ampere K. Hardraade wrote: On Sunday 13 May 2007 03:52, Harald JOHNSEN wrote: Now if the server is doing the FDM computation it's obvious that there is no need to do that 120 times per second because the data can not be send at that rate. How many loops does the mp server need to do per second ? 10 ? 20 ? At that frequency you could handle 100 clients with no problems. Harald. As far as I know, the FDM frequency controls the fidelity of the simulation. It has no relationship with the I/O frequency. If the server does the fdm 100 times per second and send the data 10 times per second it's like if the client was running the fdm at 10 hz. That's why I said it's not needed to run the fdm at more than 10 hz (those numbers are just examples). Since the FDM takes so little CPU power, the amount clients that can be served should be dependent on the bandwidth. I suppose that we run the fdm at 120Hz for a good reason: why could we suddenly accept 10Hz? Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [vtp] Looking for partner in
Reminds me of Terragen- they use the same heightmap and he renderig looks the same! --- Martin Spott [EMAIL PROTECTED] schrieb: Norman Vine wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On http://www.howardzzh.com/research/terrain Hey, apparently these guys had quite some fun :-) The results are impressive ! Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Curtis Olson wrote: Would you be willing to hack/fixup/modify the original script so that it produces correct results directly? The issue is that it combines files with the same cvs log message and commit date, but sometimes a commit spans a couple seconds and so the files can get split up into subgroups. Finally found the time to have a look at the script and hack it :) New sort-cvs-logs.pl is attached and seems to work for me. I hope I didn't overlook something. If any problems occur or you'd like to have something changed, just ell me :) Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGR1b71QuEJQQMVrgRCO12AJsHkwJCI5+Wv0fPsZPjUZPJMjbolACeI3B7 9Axl+kImVyLSwtNeTfw2NmM= =hVkt -END PGP SIGNATURE- sort-cvs-logs.pl Description: Perl program sort-cvs-logs.pl.sig Description: PGP signature - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Harald JOHNSEN wrote: That was in the situation where the MP server does the fdm computation for the client. The 10 hz comes from a ping of 100 ms between the client and the server. I think FDM caculations have to be at a certain rate, independent of how fast the calculated values are consumed because each iteration is based on it's predecessor and the Hz determines the minimum length of any event. For example if an aircraft flies through an air hole for 1/100 of a second, the impact is far less than when the smallest quantity of time is 1/10 of a second. But I don't really know anything about FDMs on the other hand :) Nine -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGR1h+1QuEJQQMVrgRCOg3AJ0eFpfybrtgaJupCKmxl6mfT0GXuQCdE0th 7u0/8ZH/sp59MOHcBsROyJQ= =BDaI -END PGP SIGNATURE- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [vtp] Looking for partner in
On Sunday 13 May 2007 13:52, Martin Spott wrote: Norman Vine wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On http://www.howardzzh.com/research/terrain Hey, apparently these guys had quite some fun :-) The results are impressive ! Martin. We could always simulate topographical features via spherical harmonics. :P Ampere - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
On Sunday 13 May 2007 15:05, Maik Justus wrote: Maybe it is easier, that the clients run their own fdm and the combat-server makes a test of the actual performance of the client against stored values, which could be generated by a script (maximum acceleration, turn rate, speed for several sets of orientation/speed). Maik That wouldn't solve the problem of syncing clients' positions across the entire network. Ampere - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Maik Justus wrote: Does anyone know, which latency between control input and visible reaction is acceptable (== unnoticeable)? I'm unable to cite a qualified source from the top of my head. Yet I remember different people talking and/or writing about not to exceed a delay of approx. 50 ms. As a rough guess think of which FlightGear frame rate you consider as 'flyable' - I'd say 20 fps is the absolute minimum of what people call 'smooth', Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Hi Ampere, yes, but solving this dogfight-only problem by bringing in a general problem for every flightgear user is much worse. Maik Ampere K. Hardraade schrieb am 13.05.2007 21:25: On Sunday 13 May 2007 15:05, Maik Justus wrote: Maybe it is easier, that the clients run their own fdm and the combat-server makes a test of the actual performance of the client against stored values, which could be generated by a script (maximum acceleration, turn rate, speed for several sets of orientation/speed). Maik That wouldn't solve the problem of syncing clients' positions across the entire network. Ampere - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Spott Sent: Sunday, May 13, 2007 4:17 PM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] More ideas on dogfighting Maik Justus wrote: Does anyone know, which latency between control input and visible reaction is acceptable (== unnoticeable)? I'm unable to cite a qualified source from the top of my head. Yet I remember different people talking and/or writing about not to exceed a delay of approx. 50 ms. As a rough guess think of which FlightGear frame rate you consider as 'flyable' - I'd say 20 fps is the absolute minimum of what people call 'smooth', Measuring between a control input and the first response to instruments, visual, or motion base. FAA Advisory Circular AC 120-40B, for Aiplane Simulator Qualification says: Relative responses of the motion system, visual system, and cockpit instruments shall be coupled closely to provide integrated sensory cues 6 These systems shall respond to abrupt pitch, roll and yaw inputs at the pilot's position within 150/300 milliseconds of the time, but not before the time, when the airplane would respond under the same conditions. Visual scene changes from steady state disturbance shall occur within the system dynamic response limit of 150/300 milliseconds but not before the resultant motion onset. [Note: 300 msec for Level A and B, 150 msec for level C and D] FAA AC 120-45A, for Flight Training Devices, requires 150 msec for level 7, and 300 for levels 1 through 6. Military standards are usually 150 msec, sometimes lowered to 100 msec. There is also a requirement that the three outputs be within 50 msecs of each other, and visual can't respond before the motion. Bill - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Soliciting newsletter ideas
Well, once again I am working on a new newsletter for JSBSim. I've taken a sort of rest from that, as I am also producing another newsletter (see: www.aiaa-houston.org/horizons). If anyone has any suggestions on topics I am all ears. Better yet, if anyone can contribute, that's really very _much_ appreciated. Best regards, Jon - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
Maik, These are not dogfight-only problems. These are multiplayer problems which currently are not addressed well in the current multiplayer implementation. On the public servers with high latency, multiplayer flight can be choppy as a plane in your view magically disappears from your right view and reappears in your left view. Also, syncing positions across the entire network allows proper collision detection. I know it is fun to fly the Rascal or some small plane inside another player's Boeing 737, but it is not realistic which seems to be the focus of zeal in this project. Having proper collision detection would allow realistic damage and system failures. In the example above, if the Rascal were to fly into an aileron on the left wing it is likely that the Rascal would be destroyed, but the 737 would only lose operation of the left aileron. The 737 would not be in a desirable situation, but with sufficient piloting skills would be able to land safely anyway. Just some thoughts, Jonathan Wagner Maik Justus wrote: Hi Ampere, yes, but solving this dogfight-only problem by bringing in a general problem for every flightgear user is much worse. Maik Ampere K. Hardraade schrieb am 13.05.2007 21:25: On Sunday 13 May 2007 15:05, Maik Justus wrote: Maybe it is easier, that the clients run their own fdm and the combat-server makes a test of the actual performance of the client against stored values, which could be generated by a script (maximum acceleration, turn rate, speed for several sets of orientation/speed). Maik That wouldn't solve the problem of syncing clients' positions across the entire network. Ampere - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Spott Sent: Sunday, May 13, 2007 5:01 PM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] More ideas on dogfighting Hi Bill, Bill Galbraith wrote: Relative responses of the motion system, visual system, and cockpit instruments shall be coupled closely to provide integrated sensory cues 6 These systems shall respond to abrupt pitch, roll and yaw inputs at the pilot's position within 150/300 milliseconds of the time, but not before the time, when the airplane would respond under the same conditions. [...] Uh, 300 ms response time looks pretty bad to me at a first glance. They already include the time which the 'real' aircraft would need to respond aerodynamically - right ? Personally I'd go crazy in the real Cessna if it would take me one third of a second until the beast starts !! responding to a control movement - this would turn almost every landing at gusty crosswind into a really difficult situation Sorry. I wasn't specific enough (and figured SOMEONE would question what I wrote). That delay is not counting the aircraft aerodynamic delay. In the simulation world, we set up special code for this testing, so that it takes the same path through normal code, it just bypasses the aerodynamic effects and recognizes the step control input, and generates a step output on the three output systems (instruments, visual, motion). Typically, one would also do a throughput analysis, if you have separate computers for various functions (you do on real sims). You look at the control input happened at t=0, but ooo, it just missed a data transfer from the control loading computer to the host, so you have to wait for the next one to come along. The host recognizes the input and generates the output, and sends the signal out to the I/O, visual, and motion computers. Those transfers are usually initiated by the host at the end of a frame, but if they aren't you have to play the game of ooo, I just missed that data transfer, I have to wait for the next one to happen, all the time adding up the delays. If the theorical delay is too great, you don't have a good architecure for something (data transfer, host execution, whatever) and may have to make some changes. Your theorical value should be less than the 150 or 300 msec, since this is the worst that it's allowed to be. You won't always hit the theorical number that you calculate, but hopefully you are less some of the time. Bill - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] More ideas on dogfighting
coupled closely to provide integrated sensory cues 6 These systems shall respond to abrupt pitch, roll and yaw inputs at the pilot's position within 150/300 milliseconds of the time, but not before the time, when the airplane would respond under the same conditions. [...] Uh, 300 ms response time looks pretty bad to me at a first glance. They already include the time which the 'real' aircraft would need to respond aerodynamically - right ? Personally I'd go crazy in the real Cessna if it would take me one third of a second until the beast starts !! responding to a control movement - this would turn almost every landing at gusty crosswind into a really difficult situation Martin, the 300ms figure is really only applicable to a Level A simulator which is basically equivalent to a cockpit procedures trainer with no visuals. BTW, sorry for being such a jerk. You were able to (likely unintentionally) wind me up like a clock-spring connected to a gas turbine. :) g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
