On Tuesday 18 January 2005 14:26, Oliver C. wrote: > 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.
The HUDs do something like this, don't they? LeeE _______________________________________________ Flightgear-devel mailing list [email protected] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
