Selon Mathias Fröhlich : > > Hi, > > On Wednesday 26 July 2006 19:20, Melchior FRANZ wrote: > > 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? :-} > Because it is not a limitation but rather a gain. A *well* *done* and *well* > *supported* scenegraph will help you some much more than you probably can > imagine now. > In fact, a proper design - like a well done scenegraph provides - will enable > such features in a much less error prone and more efficient way. > Also a *supported* scenegraph that is developed further will make use of > improovements in OpenGL that an unsupported one like plib's ssg will never > see. ssg forces you to do many things yourselves in a probably less efficient > way with direct OpenGL calls, that can be done with a smarter implementation > without such direct OpenGL commands. > There is nothing in OpenGL you cannot do with osg. But there is nowerdays > nearly everything from current OpenGL features - even some basic ones like > clip planes - that is missing in ssg, so that you need to implement that > yourselves ... > Having that will be much more of a gain that a limitation ... > > So why should we limit ourselves in the long term with ssg?
I agree with Mathias : doing raw ogl call outside the scenegraph requires lots of costly state save and restore if you don't want to see your screen screwed. OSG is extensible and already support far more OpenGL than SSG. I once proposed a compatible ssg extension : http://frbouvi.free.fr/plib/nsssg.html I was able to use it with flightgear without code change except to support the new features ( like multi texturing and environment mapping ). The code still exist but stalled after it was ignored by the plib team and further developments ( like shaders ) were lost in a disk crash. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ------------------------------------------------------------------------- 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
