On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: > On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: > > On January 17, 2005 02:25 pm, Paul Surgeon wrote: > > > We already have too many "empty" 3D models in FG without working FMCs, > > > FMSs, ECAMs, NDs, etc. > > > > > > Paul > > > > It will be nice if you can implement these systems, perferablely by Nasal > > so that they can be flexible. > > Running Nasal code in the rendering loop to do tons of work would not be a > very good idea in my opinion. > I've looked through an A320 FCOM manual and it would take many thousands of > lines of C++ to accomplish a half functional aircraft. > I don't think Nasal is the tool for the job. > > What I would need to create a aircraft with glass cockpits is : > > 1. > A way to code self rendering OpenGL intruments. i.e. The renderer loops > through the intruments and lets them do their own rendering. > > 2. > A central processing "blackbox" that contains all the logic for the > aircraft that also get's updated in the rendering loop. > The blackbox will simulate/handle the hydraulic and electrical systems, > generate and feed the display data to the intruments, handle the logic for > failures, receive input from all the simulated aircraft sensors and cockpit > switches, etc. > There are far too many aircraft specific systems than could ever be handled > by FG properly. An aircraft like this is a simulation of its own. > > How would I model for instance the ECAM switching on an A340 at the moment? > The switches are located on the center pedestal but the displays are on the > center panel. Would I have to add them to the properties tree? > How do I control the logic of those switches? If there is a failure I must > be able to override those switch settings and display the failure without > changing the position of the switch. Then the pilot must be able to > acknowledge and override (yet again) those failures on the display. How do > I tell the PFD or ND to display the ECAM screens? (This can be done on real > Airbus aircraft) > How do I close solenoid X if switch A is in postion Z but hydraulic > pressure is between 1000 and 1500 psi and there is a failure on the blue > hydraulic system? > FlightGear cannot and should not ever have to handle all these aircraft > operating procedures. > > 3. > A generic communications bus that can be used to hook instruments/switches > and the blackbox together. Using a handful of sockets is not a good way to > do it and properties maybe be a bit messy and I would require hundreds of > them. > > Unfortunately this is going to sit on the backburner for a long time as > it's tons of work to implement, I'm already too busy with other projects > and I doubt anybody else would be willing to tackle it in the near future. > > Paul >
Is it possible to implement a sort of virtual screen (like a texture but vector driven not bitmap driven) inside the Flightgear Window that can be put anywhere in the flightgear 3d world, for example inside of a cockpit as a instrument display. Flightgear should then offer this screen to outside applications and do the rendering but the commands what should be rendered is given by the outside application which are running outside of flightgear? The commands that are sent to flightgear should be simple 2d vector primitives, to make sure that this solution is flexible enough to display everything. FlightGear receives the 2d vectors primitives and put those on a virtual screen inside the FlightGear 3d world. For example a screen display in the cockpit. Doing it this way would allow to do the complexity of such glass cockpits outside of flightgear. And if we change atlas from bitmap to vector graphics we could just sent from atlas the 2d primitives that flightgear could than render on a virtual screen inside flightgear. As a 2d vector describing language we could use SVG. FlightGear then needs only a SVG parser that puts the visuals on a screen inside flightgear. There are allready SVG libarys available that do render SVG primitives in OpenGL, maybe we could use such a library instead of writing an own SVG parser. Take a look at this one: http://svgl.sourceforge.net/ What do you think about such a solution? Is this possible? Best Regards. Oliver C. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
