Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
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 Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver C. schrieb: > > 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? In principle it is possible to set up the current OpenGL context to draw to an limited area and allow a plug in to render there. But - probably - the better solution is to have the plugin code to render to an off screen texture and use that dynamic texture as an instrument. I guess that that would be faster (no big changes in viewports, etc) and create higher quality graphics (z buffer fighting, etc.) > 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. This is a totally different kind of problem. If the "plugin" is written in C/C++ it should use OpenGL (OpenGL is fine as a 2D library and there's no need to slow it down by wrapping it). If the "plugin" is writen in NASAL then NASAL would need an OpenGL like extension. That is - I guess - not hard to do. But - I guess - it'll be too slow when the graphics gets complex. I think the best would be, to add the OpenGL extension to NASAL (for flexibility) *and* write the more complex things in native C/C++ and add those to NASAL as well. > Doing it this way would allow to do the complexity of such glass cockpits > outside of flightgear. As long as the interface to FGFS is clear and easy it doesn't matter where the code lives. > 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. Atlas is basically vector graphics. It tries really hard to generate the bitmaps... > 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. Atlas can already create SVG. (Or it could when I added the SVG output a few years ago...) > 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. I don't think that that sould be a good solution. It would be *much* better to use the geometry data that FGFS has already loaded to the graphics hardware as it needs it for scenery. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7T/WlhWtxOxWNFcRAiQsAKCJqY6Q7E2gsS2Az03sUc53m1KolwCeN7SO lVMlMQ+XsB8E9b5VaWeOJ0M= =ojF9 -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380 - Virtual Screen inside Flightgear driven by SVG commands?
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
