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
