James Turner schreef: > 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. > What I'm suggesting is to make an abstraction for that so that display designers do not need to worry about the OSG code itself, but just define where their lines, points, rectangles, and text will go and the underlying engine will do the rest. Whether this is sent over the network or just stored in a file isn't really an issue -- it can go either way. I am personally in favor of orthographic 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 > My approach wouldn't be sending the pixel surfaces (like video) over a network, but sending the low-level geometry that would result in pixel data. The rendering into the actual framebuffer would be done by the receiving application, this would also allow abstraction over different display engines (fx. for Windows developers who may prefer Direct3D or GDI+), so my idea is to make a VM-like structure with instructions like "draw line", "draw polygon", "translate", "rotate" etc. and a stack-based architecture. These instructions could be executed locally (acting on properties) or sent over a network for remote display, or saved to a file for delayed rendering.
A property-based display in an OSG viewer could also be a good idea, though, but it has a minor downside of decreased flexibility, since you're placing part of the instruments' intelligence in the client. But it might be a simpler solution in the short term -- and since the property interface is well documented, it wouldn't be hard to connect that to other flight simulation packages as well. ------------------------------------------------------------------------- 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
