James Turner schreef: > On 4 Aug 2008, at 10:43, Tim Moore wrote: > >>> Lots of interesting issues here. >>> > > Yep :) > > >> Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the >> existing >> examples we have of a custom glass instrument. The weather radar >> does work in >> FlightGear OSG; there isn't any weather yet, but it can show other >> aircraft >> traffic and is the basis for the ATC radar. od_gauge.cxx uses the >> method that >> would be used for any glass instrument: an osg::Camera that is bound >> to an >> off-screen render target, i.e a texture. The texture can then be >> used anywhere >> in the scene. >> > > Okay, that fits my basic expectations, great. I'll look more closely > at the od_guage as well as the wx_radar. > > >> You can integrate arbitrary OpenGL code with an OSG application. It >> is most >> friendly to setup and change all OpenGL state using OSG's StateSet >> mechanism, >> but even that is not necessary. We use the GUI code from PLIB, which >> doesn't >> know anything about OSG. See the SGPuDrawable class in Main/ >> renderer.cxx for the >> implementation. The one catch is that OSG has a strong notion of >> separation >> between the update of a "scene" and its rendering, and that might >> not play well >> with arbitrary existing OpenGL code. >> > > Also good to know, though purely in terms of sane design I'd want some > better structure than just hacking up low-level GL calls I think. I > was aware the OSG could wrap arbitrary GL code, I'd just forgotten it > was that easy. Silly me. > A cockpit display doesn't require *arbitrary* GL calls, only the ones related to drawing geometry and transformation are useful. Most special API calls like the ones found in GLU aren't even used. And I don't think basic geometry and transformation would be difficult to map. > I'm also very aware that even for a stand-alone cockpit-display > running full-screen, many elements can be drawn much cheaper as a > texture than as SVG graphics. It's not as aesthetically pure as > specifying everything in pure vector formats, but I'd be happy to use > a mixture of simple vector graphics and bitmap textures to start with, > and the replace the textures with vector art once there's a suitable > renderer. > Err, come on... Compared to a full scene graph, rendering a full-vector graphics cockpit display is like rendering the desktop for most contemporary graphics cards. Textures have their uses (as bitmaps), but they aren't the way to go when emulating vector graphics when you have GPU cycles to spare. My software runs pure vector and it runs smoothly even on a 7-year-old Celeron without a 3D card. And for the record, that's on Windows 2000. >> A moving map is a different beast. It would make sense to implement >> that as a >> scene graph in its own right with its own pager. That would require >> a change in >> current fg architecture to use a CompositeViewer instead of a single >> Viewer, but >> we're contemplating that anyway. >> > > Yep, I agree, moving map is a much harder problem, and not something > I'm going to worry about in the short term. > > James I did a moving map with complete navigation database and flight plan support in one file for my OpenRJ project (see a previous post), and it's about 300-400 lines of code total, including the surrounding MFD's. So a separate scene graph can work if that's what you want but it is not really neccessary.
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
