Melchior FRANZ schreef: > We had talked about abstracting out the raw gl-commands into just > one file, and then to use plib wrappers to plug the HUD into the > scene graph. The plib wrappers could eventually get replaced by osg > wrappers. > > The abstraction is still a goal, and so is plugging the HUD into > the scene graph. But I think now that using plib/osg wrappers is > a bad idea. This would prevent us from using some gl features for > absolutely no good reason (e.g. line width, clipping, ...). And > finally, ogl *is* a standard, while neither plib nor osg are. So > why leaving the standard? Raw gl-code can still be plugged into > the scene graph via callbacks, and the only thing that the wrappers > would buy us is management of state changes for performance reasons. > But the HUD code doesn't change that much, and this can be done > manually, too. > > Why exactly would we want to limit ourselves? :-} > > m. > I quite agree with this. The double advantage that you have is that you can use existing rendering code from other packages (e.g. OpenGC) since they boil down to raw OpenGL calls if you take an abstract look (from a GPU point of view). Rendering to texture would allow us to use those glass displays inside virtual cockpits or at least 2D panels, and I know a few aircraft with HUD's that are very similar to displays already constructed. Why reinvent the wheel? It wouldn't be that difficult to make a callback for the HUD every rendering cycle (when neccessary) and render either directly to framebuffer or a texture (which the HUD code doesn't know, it just draws lines, rectangles, text, etc.) My own glass cockpit software does a similar thing with a few tricks. Every gauge file is a DLL (or a SO) containing only one callback routine which does nothing more than rendering the gauge with the given data. It doesn't know where you render it to (only its location in the viewport, which it needs for correct scaling and aspect) and it works great. IMO it works better than the pure OO approch that OpenGC uses, because you can distribute new features in binary form without needing a recompile every time. (Plug-in mechanism)
Bit OT here but a small question: Has FlightGear for the Mac been built for Universal Binary already? I've got a brand new Core Duo Mac Mini here and I've tested it on another Intel box and it just crashes on startup. It ran on a G3 but it was pretty much a slideshow... If all else fails I'll try to make an OSX Intel-only build (since GCC comes standard with OSX) or just switch to the Win32 flavour, which runs fine on my Mini. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
