On 4 Aug 2008, at 07:28, R. van Steenbergen wrote: > 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.
I'm not clear what there is to be afraid of :) I mean, of course there needs to be a way to render basic geometry, and there's an issue about how to do that internally - a 'line' could be rendered by hand-written Breshnam code into a texture, it could be an OSG node rendered orthographically, etc, etc. There's many ways to get a 'vector' line on the screen, but they're mostly dictated by the underlying OSG rendering approach we adopt. > 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. This is what I have a problem with - I'm concerned to get something simple and workable behaving with the current panels and systems in FG. So initially I want in-process code, using the existing property tree, panels and scene graph. While something like your approach would give maximum flexibility, it's something we could talk about pursuing once a basic solution that works in FG is established. If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes. 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
