-----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
