R. van Steenbergen wrote: > James Turner schreef: >> Yeah, that's an absolute non-starter, same as the OpenGC code - low >> level OpenGL will not be flexible enough, or efficient in the OSG >> scene-graph, is my perception. I hope Tim Moore will pitch in with his >> opinion on the best way to do the OSG integration, separate camera >> feels like the best choice to me, but I need to think about the details. >> >> James >> > I fear, though, that in some way you are going to have to fall back to > the rendering of very basic geometry (points, lines, rectangles) because > they are the basic make-up of a 2D vector display. Lots of interesting issues here.
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. 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. 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. 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. > > I am thinking about a small 'dumb' GL rendering application that takes > in geometry data in some sort of byte-code from stdin, a file or a > socket, and outputs GL frame buffer data into a block of memory. If it > would be possible to offer that block of memory to OSG as a texture and > tell it to map it onto some surface, we pretty much get what we're > looking for, including the degree of flexibilty required by deck builders. > This tiny app could have other uses as well, as the Blender crew might > be interested into an app that generates pixel data from a raw geometry > stream, maybe incorporating GPU-accelerated rendering. It will be much more efficient to integrate this directly into FlightGear and render to a texture. Otherwise your program and FlightGear will thrash with graphics context switches and you'll have the cost of copying from memory to GPU. Tim ------------------------------------------------------------------------- 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
