Re: [Flightgear-devel] Serious simmer
Maik Justus schreef: > Hi Ron, > Robin van Steenbergen schrieb am 22.09.2007 02:14: > >> No, my original issue was to make external instrumentation possible over >> the network, not on a single PC with 6 monitors on it. >> > I think this is already possible within flightgear now. The only missing > feature (if I remember correctly), is the switching off of the > 3D-rendering of the surrounding, which is not necessary when rendering a > panel only. But this should not be a big problem at all. As a ugly hack > just use an empty scenery on the panel rendering machines. > Will network-linking of FG sessions synchronise ALL of the aircraft's property data, thus also syncing radio, instrument and cockpit data? For the visuals, only the basic 6DOF are needed, but is there also a way to keep everything inside the A/C's panels up to date all the time? That would get us a good start. Switch off the 3D rendering (as per Curt's instruction) and get 2D panels on the panel rendering machines. But we are going to need some good 2D panels, aside from the 3D cockpits already out there. Redundant FDM's is not a really neccessary step yet. I know that on some professional sims, all of the data is exchanged through a 'push' mechanism instead of a pull-style one. If one functional unit were to be stop sending data, the standby will immediately take over, as it was already receiving and processing data meant for the FDM system (it was only not transmitting data back). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
On 9/22/07, Maik Justus <[EMAIL PROTECTED]> wrote: > > I think this is already possible within flightgear now. The only missing > feature (if I remember correctly), is the switching off of the > 3D-rendering of the surrounding, which is not necessary when rendering a > panel only. But this should not be a big problem at all. As a ugly hack > just use an empty scenery on the panel rendering machines. We can already switch off rendering of the 3d scene. 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 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Hi Ron, Robin van Steenbergen schrieb am 22.09.2007 02:14: > No, my original issue was to make external instrumentation possible over > the network, not on a single PC with 6 monitors on it. I think this is already possible within flightgear now. The only missing feature (if I remember correctly), is the switching off of the 3D-rendering of the surrounding, which is not necessary when rendering a panel only. But this should not be a big problem at all. As a ugly hack just use an empty scenery on the panel rendering machines. > Distribute the > computing power, allowing more processing power for the flight dynamics > and visuals and a flexible instrument setup. > > Take a real simulator as an example: The flight dynamics are run from a > system that does only that -- flight dynamics. Same issue here, the rendering need to be switched off, but the machine needs the scenery for scenery interaction. As a first step you can reduce the visibilty of the surrounding to a minimum, minimize the window and use no 3D-model of the aircraft. > Pure math that is, and > it's mostly done as a double redundant unit instead of a single one. > ... > My ultimate goal is to model a flight deck after the professional sims > -- each part of the simulator is dedicated to a system. This adds both > redundancy and flexibility -- if a system crashes, it doesn't take the > entire simulator with it as is the case with FS2004 based setups. The > data exchange doesn't stop, because it isn't tied to a single 'master' > unit -- if one unit should cease to respond (function), the rest of the > system is notified and possibly another unit or a hot standby might take > over. I think the redundant fdm on more than one machine is not supported by flightgear. But I think, that the implementation of this feature is much to much work compared with the result. Spending some time in a stable hardware should be much easier. (If flightgear crashes on one machine due to a software bug it will probably crash on the second machine, too. But the community works on avoiding and fixing such bugs.) > ... My proposal for the project would be to create a working framework for > 2D instruments, suitable for cockpit builders. The system would be > similar, if not identical in functionality, to X-Panel for X-Plane users > Wat's about programming an interface for X-Panel to flightgear? > (I would like to give you a URL but some fool took down the X-Panel > pages, every Google hit turns 404), which allows X-Plane instruments to > be displayed on a different system (or multiple). As for glass cockpits > go, an example is either OpenGC or Project Magenta, but both of these > have the design of their displays hard-coded, what I would really like > to see is that GC or steam panels could be designed in a WYSIWYG > graphics environment, and interactive script added later. SVG has > specifications for that. > The built-in interface in flightgear should be capable to fulfill all your request. Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
AJ MacLeod schreef: > Your original issue was, I think, a desire to have different parts of > the FG > 3d environment (including instruments) displayed on different screens, on a > PC with multiple graphics cards and monitors. As far as I can see, it's > already possible, with no extra coding, even for fully 3d cockpits. You can > already set your viewpoint(s) anywhere relative to the a/c, facing any > direction at any zoom level. You can have multiple views of any part of the > same aircraft. Of course it should be even simpler now that we're using > OSG... there was some mention in a thread in June (Impressions from LinuxTag) > of using four osgViewer "cameras" configured in preferences.xml to output > displays from one instance of FG. > > Mind you, I haven't seen the promised instructions materialise... it would be > nice to see those - did they get onto the wiki when I wasn't looking? > > The one instrumentation-related thing that we definitely lack at the moment > is > a really flexible method of implementing "glass cockpit" displays within FG. > Fortunately, it's not something that affects the type of aircraft I'm most > interested in ;-) > > Cheers, > > AJ > No, my original issue was to make external instrumentation possible over the network, not on a single PC with 6 monitors on it. Distribute the computing power, allowing more processing power for the flight dynamics and visuals and a flexible instrument setup. Take a real simulator as an example: The flight dynamics are run from a system that does only that -- flight dynamics. Pure math that is, and it's mostly done as a double redundant unit instead of a single one. The only data the FDM machine will output is that relevant to flight dynamics. That's basically all of the position data and 2 levels of derivatives of it (thus including forces on the airframe). Other systems, mostly composed of real-world avionics, pick up on that data and generate the relevant instrumentation, either as an image or as a control signal for a real aircraft instrument. Mind you, most flight deck builders, including the FS200x users, do not use a single machine for all the work. More and more of FS is ripped out of the FS logic, leaving only the raw FDM and visual data up to that system. All of the system logic is done "outboard" communicating with FS over a network link. The only downside of this, is that FS panels themselves are defined in "gauges" (DLL files) which can never be used outboard because of Microsoft's closed API. There are some really good payware aircraft on the market with tremendous levels of realism, but they are all limited to that one system running FS, so they are not suitable for cockpit builders. Mind you, most of my ideas ARE targeted at glass cockpits, which are mostly composed of vector based graphics. (Historically, aircraft even had vector-driven CRT's before the flat panel era.) If glass cockpits are built up of bitmap-based graphic material, it will look ugly and unrealistic. The Citation in FG, for example, has a very clear and visible display for the PFD/ND, but you can immediately see that it doesn't look like "glass". Most cockpit builders will want 2D displays since most of it is hidden behind paneling. Only a few display elements are revealed, and these should look like they belong there. You don't want to be looking 'through' the display glass at some piece of 3D cockpit, you will want to be looking AT the display glass because it is part of the cockpit hardware. Everything will have to look flat. My ultimate goal is to model a flight deck after the professional sims -- each part of the simulator is dedicated to a system. This adds both redundancy and flexibility -- if a system crashes, it doesn't take the entire simulator with it as is the case with FS2004 based setups. The data exchange doesn't stop, because it isn't tied to a single 'master' unit -- if one unit should cease to respond (function), the rest of the system is notified and possibly another unit or a hot standby might take over. Likewise, if another aircraft is being simulated, the only thing that needs to change (in principle) is the system logic and flight model, instead of needing a hard simulator reset. My proposal for the project would be to create a working framework for 2D instruments, suitable for cockpit builders. The system would be similar, if not identical in functionality, to X-Panel for X-Plane users (I would like to give you a URL but some fool took down the X-Panel pages, every Google hit turns 404), which allows X-Plane instruments to be displayed on a different system (or multiple). As for glass cockpits go, an example is either OpenGC or Project Magenta, but both of these have the design of their displays hard-coded, what I would really like to see is that GC or steam panels could be designed in a WYSIWYG graphics environment, and interactive script added later. SVG has
Re: [Flightgear-devel] Serious simmer
On Friday 21 September 2007 18:15:56 Robin van Steenbergen wrote: > For example as comparison, FS2004, as well as the FG instrument system, > use stacked bitmap images which have arrangements defined in an XML > file. Actually, the FG instrument system doesn't necessarily use stacked bitmap images at all. At the moment we have a superbly flexible scheme that allows us to construct fully 3d gauges in as much detail as we want; we can use hand-drawn textures or photo-based ones as we need, and can handle all sorts of odd shapes and motions without having to resort to dodgy graphics tricks (which we can also do, if we desire.) Of course, some models (particularly older ones) do use flat stacked bitmap instruments, and it's that flexibility to choose what best suits a particular application which is a very large part of what makes FG great. > Why not make an application that does that externally? In the long > run, if OpenGL is used as a rendering API, it could also be used to > render vector-based images as well. OK - why make an application that does it externally? Sounds like extra complexity which achieves almost nothing that can't be already done. Yes, SVG instruments sound great for some applications; lots of us use SVG to draw the faces for some of our instruments, before exporting to bitmaps at a suitable resolution. But not for all of them by any stretch of the imagination; I see no gain at all for fully 3d instruments using photo-based textures, for example. The only minuscule gain I can see with SVG is that of being able to scale some instruments to ridiculous, larger than life sizes without any jaggies. I can't think of any valid reason to want to, but can already do that anyway, by choosing suitable resolution for the main face texture of a 3d instrument (pretty much all of mine should easily scale to greater than real life size without looking any worse) > I'm targeting a generic audience, > from a Cessna flyer to a 744 or 787 pilot. Keep the actual graphics out > of the program code, but the rendering in there. That doesn't make much sense to me, perhaps I've missed your point altogether :) Also, unless I'm mistaken, you're suddenly limiting us to "flat" instruments? Lots of (particularly vintage) instrumentation is very far from flat, and we can already handle that very well. > For speed, you could reduce this to a VM-based architecture, with the > instruction set corresponding to OpenGL rendering commands and the data > in memory being the A/C data pulled out of a simulator like FG, FS2004 > or PS1, hence almost a full ARINC661 implementation. I'm sure you know that you can already pull any data out of the property tree that you might need, so no changes required there. > On the hardware front, each DU could be driven by their own TFT display > (portrait) and a Mini-ITX form factor board on the back. MiniITX boards > have LVDS connections on board, and are powerful enough to run 2D > graphics. If a DU fails, the network code could be programmed to detect > that and let another DU take over. Some of the intelligence could be > transferred from FG to the external applications and interface logic, > while still keeping FG up to date on any changes, through the property > system. This sounds like something that is already possible (and already done) with FG. Your original issue was, I think, a desire to have different parts of the FG 3d environment (including instruments) displayed on different screens, on a PC with multiple graphics cards and monitors. As far as I can see, it's already possible, with no extra coding, even for fully 3d cockpits. You can already set your viewpoint(s) anywhere relative to the a/c, facing any direction at any zoom level. You can have multiple views of any part of the same aircraft. Of course it should be even simpler now that we're using OSG... there was some mention in a thread in June (Impressions from LinuxTag) of using four osgViewer "cameras" configured in preferences.xml to output displays from one instance of FG. Mind you, I haven't seen the promised instructions materialise... it would be nice to see those - did they get onto the wiki when I wasn't looking? The one instrumentation-related thing that we definitely lack at the moment is a really flexible method of implementing "glass cockpit" displays within FG. Fortunately, it's not something that affects the type of aircraft I'm most interested in ;-) Cheers, AJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Vivian Meazza schreef: > Obviously someone who keeps right up-to-date with FG, and reads our > website > :-). Try this: > > http://www.flightgear.org/Projects/ > > John Wojnaroski is particularly active in this field > > Vivian > I know about the OpenGC project, but that'ts not really what I was looking for. ARINC661, for example, has a clear separation between the display graphics and the rendering engine. The ARINC661 instruments are based on SVG vector-based artwork, compiled into byte code (purely for size issues). The display units 'run' this byte code and convert it into the appropriate image. Problem with OpenGC: The display graphics are hard-coded in the source code of the project, and currently only Boeing-related. No Airbus, no Honeywell, and definitely no steam gauges. For example as comparison, FS2004, as well as the FG instrument system, use stacked bitmap images which have arrangements defined in an XML file. Why not make an application that does that externally? In the long run, if OpenGL is used as a rendering API, it could also be used to render vector-based images as well. I'm targeting a generic audience, from a Cessna flyer to a 744 or 787 pilot. Keep the actual graphics out of the program code, but the rendering in there. For speed, you could reduce this to a VM-based architecture, with the instruction set corresponding to OpenGL rendering commands and the data in memory being the A/C data pulled out of a simulator like FG, FS2004 or PS1, hence almost a full ARINC661 implementation. On the hardware front, each DU could be driven by their own TFT display (portrait) and a Mini-ITX form factor board on the back. MiniITX boards have LVDS connections on board, and are powerful enough to run 2D graphics. If a DU fails, the network code could be programmed to detect that and let another DU take over. Some of the intelligence could be transferred from FG to the external applications and interface logic, while still keeping FG up to date on any changes, through the property system. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Robin van Steenbergen > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of > Sent: 21 September 2007 04:03 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Serious simmer > > > Ampere K. Hardraade schreef: > > I have seen far more serious simmers. :P > > > > Ampere > > > That basically translates as: We really want some pictures of that! > > All of that guy's sim is MSFS-based with third party add-on > instruments, > and all of the monitors on his desk are run from a single PC. > > If FG is going to be used in home cockpits (Which I REALLY am > in favor > of) we need some way to get the instruments currently in FG out in an > external application, which can run a 2D panel on a separate > monitor. FG > of course already has the possibility of exporting data over > the network > and linking copies for visuals (--external-fdm) but I'm not > sure to what > extent all of the instruments will follow in the slaved FG copy. The > most important instrument you will have to run offboard > except the basic > six are engine gauges, radio and possibly map navigation. > > Making a decent (preferably OpenGL, vector-based) framework for FG > panels would be a good development step, and it need not > neccesarily be > in the FG branch. As long as it follows the FG spec for the current > instruments it will work, and we might be able to add > XML-based vector > artwork for glass cockpits later (SVG instrument rendering, > anyone?). We > could borrow some ideas from ARINC661 here. The project would > be similar > to X-Panel, already developed for X-Plane, so PanelGear might be a > suitable name? > Obviously someone who keeps right up-to-date with FG, and reads our website :-). Try this: http://www.flightgear.org/Projects/ John Wojnaroski is particularly active in this field Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Ampere K. Hardraade schreef: > I have seen far more serious simmers. :P > > Ampere > That basically translates as: We really want some pictures of that! All of that guy's sim is MSFS-based with third party add-on instruments, and all of the monitors on his desk are run from a single PC. If FG is going to be used in home cockpits (Which I REALLY am in favor of) we need some way to get the instruments currently in FG out in an external application, which can run a 2D panel on a separate monitor. FG of course already has the possibility of exporting data over the network and linking copies for visuals (--external-fdm) but I'm not sure to what extent all of the instruments will follow in the slaved FG copy. The most important instrument you will have to run offboard except the basic six are engine gauges, radio and possibly map navigation. Making a decent (preferably OpenGL, vector-based) framework for FG panels would be a good development step, and it need not neccesarily be in the FG branch. As long as it follows the FG spec for the current instruments it will work, and we might be able to add XML-based vector artwork for glass cockpits later (SVG instrument rendering, anyone?). We could borrow some ideas from ARINC661 here. The project would be similar to X-Panel, already developed for X-Plane, so PanelGear might be a suitable name? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
On Wednesday 19 September 2007 22:45, Jon S. Berndt wrote: > Check this out. Serious simmer: > > http://mysite.verizon.net/antonioe/index.html > > Jon I have seen far more serious simmers. :P Ampere - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Serious simmer
Check this out. Serious simmer: http://mysite.verizon.net/antonioe/index.html Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
