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.



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
Flightgear-devel mailing list

Reply via email to