On Tuesday 05 August 2003 17:23, Curtis L. Olson wrote: > Hi, > > I just wanted to float an idea on the list and see if anyone had any > comments. This isn't an official proposal and I'm not chomping at the > bit to make a change. It's just an idea I find interesting to think > about and I'd like to get some sort of feedback/comments if any one > has any. > > plib/ssg has served us well and when we jumped on board the plib > bandwagon, it was the best thing available in terms of performance, > robustness, stability, features, etc. > > However, in the last couple years, the scene graph portion of plib has > developed very slowly; meanwhile projects like "Open Scene Graph" > (http://openscenegraph.org/) and "OpenSG" (http://www.opensg.org) seem > to be roaring ahead with support for many of the newer graphics tricks > and effects. > > I'm even talking about "simple" things like "multitexturing" which > isn't exactly a new concept (i.e. it's been supported by > hardware/opengl since the voodoo-1 days.) Plib unfortunatley has no > support for multitexturing. These other scene graphs do, and also > support things like "imposters" which is the technique often used for > 3d clouds. > > At the risk of tainting the discussion I will say that from my > investigation, "Open Scene Graph" seems to be the better choice. > There are people here locally that use it, and I know that other > flightgear developers have used it as well. It seems to support all > the platforms that we currently support. No one I've talked to seems > to know much about OpenSG and the one web link I found > (http://sgi.felk.cvut.cz/~pavlicm/Dipl/sw.htm) seems to put Open Scene > Graph ahead in terms of performance (based on a single test which > doesn't say too much actually.) > > It would probably be a large job to convert everything in > simgear/flightgear over to use a new scene graph, but it may give us > many more options for moving forward with new and better graphic > effects. There will certainly be ramifications that we won't discover > until it's too late to go back. > > One proposal I've heard has been to try to build a "scene graph > independent" layer (i.e. our own generic scene graph API that could > translate calls into any of the actual scene graph api's, but I'd like > to avoid that based on performance concerns and also the point here is > not to write to the lowest common denominator, we want to be able to > push forward with newer graphic effects.) > > Any other thoughts/comments? > > Thanks, > > Curt. > -- > Curtis Olson IVLab / HumanFIRST Program FlightGear Project > Twin Cities curt 'at' me.umn.edu curt 'at' flightgear.org > Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
What native object formats would be supported? If we stuck with the .ac object format then we're going to be limited to one texture per object anyway. I'd like to switch to a more versatile object format but that's going to require new modelling/texturing s/w and the skills to use them. I don't think this will be a show stopper but it's going to take some time to transition, especially if the models needs to be converted. LeeE _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
