Hi, On Saturday 14 January 2006 19:07, Ampere K. Hardraade wrote: > That was a suggestion. I current am not working on any document regarding > the graphic engine, so I have nothing to share. However, I along with > several others, are working on a document regarding the architecture of FG. > > If you have concrete plans, you need to put them in a document so those > people who want to help can understand what you are trying to do, then make > addition or proposal modifications to some of your ideas. Well not that concrete. :)
It is just that I have already a plan in my desk if we want to do that. A plan which has prooven good in an other projekt. I have for example a list of things just required to be done before. I believe it is out of discussion that the ac reader must just work like the plib one does. > The idea is to get the design and analysis done before writing a single > line of code. For a project as big as FlightGear, writing design reports > should not be an option; it should be a must. Well, a scenegraph is a scenegraph - more or less. At least in this direction. There is nothing I know of you can do with plib you cannot do with osg. There are aprioriate callbacks in osg so that you can implement the animation infrastructure like we have it with ssg*. So there is not much design to do in this area. Given that the precautions are are all satisfied, that is - all required loaders for osg work like expected, - we have an additional loader for the scenery files - we have a good tri/quad striper for osg geometries. - we have a short proof of concept to see how this interacts with pui and most important - *we* have *decided* to do that(!) then, I think the plan would be as follows: - build up a very thin envelope around the ssg* calls just taking scenegraph independent datastructure which could be translated to the aprioriate scenegraph. The best case is here that the datatypes are scenegraph independent but fit directly into the ssg functions directly. That is how I designed that vectors this discussion started from. Consequently no copying needs to be done. The envelope calls will be inlined and optimized away. - From that point we will not have any direct ssg call in the sources except in that envelop classes. - Now we can provide a set of envelop classes with osg as backend. - Now see how we can integrate our direct OpenGL calls into that stuff to make it work with both envelopes. - Past that we can play with that and can even easily go back if there are some unsolvable problems (I do not expect them). - If osg turns out the way to go, one can remove the ssg envelopes and may remove the indirections through the osg envelope. - Now you are really free to just use the cool features osg provides. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Mathias Fröhlich, email: [EMAIL PROTECTED] ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel