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. > If a vector description of instruments is the way to go, then you > should look at > using SVG with OpenGL and OSG. The big player here is cairo+glitz, > but the last > time I looked at this it was hard, perhaps impossible, to coax glitz > to draw > into an OpenGL context that it had not created. Perhaps this has > been solved. > Another library is svgl at svgl.sourceforge.net, but I have no idea > if it is > still alive. Any solution that renders to memory using the CPU is > going to be > too slow, IMHO. Yeah, I've also (just) been looking at the state of the art in SVG -> GL rendering. I was hoping to find something reasonably compact, but there's various dead links and so on. We already have some of the components (XML parser) so my preferred approach would be to make something like an osg-svg-kit by borrowing code from a project like svgl, but I really haven't looked at enough code to be sure about that. I'm also pretty wary of SVG as a technology, I've worked on the Mozilla SVG code in the distant past. 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. Anyway, going to play with svgl now. > > > 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 ------------------------------------------------------------------------- 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
