On Saturday 29 July 2006 14:28, Frederic Bouvier wrote:
> Vassilii Khachaturov wrote :
> >> 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, is the code you refer to newer than the state-of-the art plib, or
> > does it require an excessive merge? maybe you could fork plib into a
> > simgear subdir and have a configure option to pick it up, if chosen?
>
> This code was written in summer 2004 and left untouched since then. But
> I am afraid plib didn't changed that much too.
> Code is here :
> http://frbouvi.free.fr/plib/
Hmm, I don't know if it is better to improove ssg and take it into our tree or
if we should leave that work to somebody specialized to scenegraphs.
Given the good work of Robert Osfield, Don Burns et. al. for osg. I tend to
spend our work switching over to osg instead of redoing that ourself ...
I have thought often about a thin scenegraph abstraction layer for some
structural nodes. That could help us much when we need/want to switch to an
other scenegraph. At least for a transition time we could have a ssg and an
osg version in parallel without disturbing people willing to have the settled
down and feature complete ssg build.
Later such a layering could be beneficial if Redmond decides to cut OpenGL
support completely like they tried several times in the past.
... I am curious what this years siggraph brings.
I think of abstractions for Group/Transform nodes. Just to be able to plug
together the scenegraph from flightgear's sources.
Animations are scenegraph specific and shoudl be scenegraph specific.
Animations will just need a pointer to a property. The aprioriate scenegraph
callback objects/code can be entirely scenegraph specific and does not need
to be abstracted. That code is only installed in the model scenegraph as a
postprocessing step to model loading.
What we will need is some cairo/glitz like 2d api to draw the HUD and do some
MFD's. I believe that this is even more apprioriate for such rendering areas
like issuing raw OpenGL commands.
With such an abstraction we are open to map that to an immediate more
rendering pass to a texture or if this is used to build up a part of the
scenegraph in case we do not have RenderTexture available.
... btw: I fear that osg already has way better render to texture code that
will find a kind of off screen buffer on almost every graphics card ...
Also Camera nodes must be accessible from within flightgear.
Whenever we need an other direct access to the scenegraph we can extend the
abstraction layer.
For those struggling with performance issues with abstraction layers, I can
only tell that almost everything is done directly on the scenegraph. For
example the performance critical cull and draw operations will not even know
that there is an abstraction layer. Animations will be scenegraph specific
and therefore not critical. Plugging together the scenegraph at load time
will have some theoretical penalty that I doubt that it is measurable.
Implementing that will be possible without branching and without the burden to
do regular merges. It is designed from ground up to be able to do that.
We can incrementally refactor what we have with ssg and provide the aprioriate
abstractions that can definitely be used with osg and most probably be used
with DirectX (Fred, you you have experience with DirectX?).
As a first step I would like to refactor some code heading to that goal. You
can alternatively call that cleanup, cleanup that is most likely sensible
anyway. And such cleanup is the origin of that thread.
Greetings
Mathias
-------------------------------------------------------------------------
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
