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.


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