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


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
Flightgear-devel mailing list

Reply via email to