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/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
