Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-29 Thread Vassilii Khachaturov
 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?

V.


-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-29 Thread Frederic Bouvier
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/

-Fred

-- 
Frédéric Bouvier
http://frfoto.free.fr Photo gallery - album photo
http://www.fotolia.fr/p/2278  Other photo gallery
http://fgsd.sourceforge.net/  FlightGear Scenery Designer



-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-29 Thread Mathias Fröhlich
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-28 Thread Vassilii Khachaturov
FWIW, the current precipitation rendering code is raw-gl-based as well,
not even done with proper branching via ssg; we just have a special call
to its rendering from within the renderer. I am currently working on
texturing-based precipitation which needs multitexturing, and naturally it
can't be done fully above ssg w/o raw gl codes since multitexturing is not
supported in ssg. My plan is to first achieve a sensible visual
effect/performance, (at which point a demo patch will be posted over to
the list with a call to you texture artists for better textures for rain,
snow. and hail) then ssgify it properly to make sure the gl state is
managed in a coordinated way between the precipitation code and the other
ssg-based one (a milestone for another patch), and, finally, fix the
culling issues (so that we no longer rain into underground etc.)

Currently I am having some nasty visual artifacts which make the whole
thing look worse than the GL_LINES based current code; I am getting 25-33%
FPS drop here on various nvidia cards (33 on older ones, 25 on better
ones). I might be able to improve the FPS drop though, as I have some GL
optimization tricks unused yet. Nevertheless, since the FPS impact is no
longer negligible (like it's in the lines-based code), it means that there
will be a configurable rendering option to stay with the GL_LINES based
old code for those who don't want the penalty, although I won't guarantee
a runtime-switchable (i.e., you need to reload fgfs). For cards w/o the
multitexturing capability, it's automatically going to be using the old
precipitation code.

Vassilii


-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-28 Thread Frederic Bouvier
Selon Mathias Fröhlich :


 Hi,

 On Wednesday 26 July 2006 19:20, Melchior FRANZ wrote:
  We had talked about abstracting out the raw gl-commands into just
  one file, and then to use plib wrappers to plug the HUD into the
  scene graph. The plib wrappers could eventually get replaced by osg
  wrappers.
 
  The abstraction is still a goal, and so is plugging the HUD into
  the scene graph. But I think now that using plib/osg wrappers is
  a bad idea. This would prevent us from using some gl features for
  absolutely no good reason (e.g. line width, clipping, ...). And
  finally, ogl *is* a standard, while neither plib nor osg are. So
  why leaving the standard? Raw gl-code can still be plugged into
  the scene graph via callbacks, and the only thing that the wrappers
  would buy us is management of state changes for performance reasons.
  But the HUD code doesn't change that much, and this can be done
  manually, too.
 
  Why exactly would we want to limit ourselves?  :-}
 Because it is not a limitation but rather a gain. A *well* *done* and *well*
 *supported* scenegraph will help you some much more than you probably can
 imagine now.
 In fact, a proper design - like a well done scenegraph provides - will enable
 such features in a much less error prone and more efficient way.
 Also a *supported* scenegraph that is developed further will make use of
 improovements in OpenGL that an unsupported one like plib's ssg will never
 see. ssg forces you to do many things yourselves in a probably less efficient
 way with direct OpenGL calls, that can be done with a smarter implementation
 without such direct OpenGL commands.
 There is nothing in OpenGL you cannot do with osg. But there is nowerdays
 nearly everything from current OpenGL features - even some basic ones like
 clip planes - that is missing in ssg, so that you need to implement that
 yourselves ...
 Having that will be much more of a gain that a limitation ...

 So why should we limit ourselves in the long term with ssg?

I agree with Mathias : doing raw ogl call outside the scenegraph requires lots
of costly state save and restore if you don't want to see your screen screwed.
OSG is extensible and already support far more OpenGL than SSG.

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

--
Frédéric Bouvier
http://frfoto.free.fr Photo gallery - album photo
http://www.fotolia.fr/p/2278  Other photo gallery
http://fgsd.sourceforge.net/  FlightGear Scenery Designer

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-28 Thread Melchior FRANZ
* Frederic Bouvier -- Thursday 27 July 2006 08:30:
 I agree with Mathias : doing raw ogl call outside the scenegraph requires lots
 of costly state save and restore 

And as I said: the HUD doesn't do many state changes.



 if you don't want to see your screen screwed. 
 OSG is extensible and already support far more OpenGL than SSG.

Yes, but that's the whole point: we use SSG. And dumbing the HUD down
to SSG niveau only to make it smart again with OSG is silly. I think
about simple things like glLineWidth. To make that work with SSG
one would probably have to write ssg nodes *and* then to implement
the missing capabilities with callbacks, using raw code again. So we
end up where we started, just with a lot of superfluous extra work.
I'd prefer pragmatism to politics here.

But then again: show me the code. Maybe it's easy enough ...  :-)

m.

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-27 Thread Melchior FRANZ
* Mathias Fröhlich -- Wednesday 26 July 2006 22:49:
 Because it is not a limitation but rather a gain. A *well* *done* and *well* 
 *supported* scenegraph will help you some much more than you probably can 
 imagine now.

You completely miss the point: we are using ssg! There was no
decision made to switch to osg. So, if we switch to ssg wrappers
first, we lose capabilities, that we may or may not get back later.

I don't accept that and object.



 In fact, a proper design - like a well done scenegraph provides 

You miss the point. We are using ssg!



 So why should we limit ourselves in the long term with ssg?

Fact is: we are using ssg. We may or may not switch to osg later.
There has *no* decision been made, so we can't rip out stuff now
that osg may provide later. The way to go is:

 - formal decision to switch to osg (or at least to start working on it)
 - generate osg branch in cvs
 - parallel development

In the osg branch you can do with the HUD what you like. But not
in the current, *SSG* branch.

m.

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-27 Thread Mathias Fröhlich

Melchior,

On Thursday 27 July 2006 09:58, Melchior FRANZ wrote:
 * Mathias Fröhlich -- Wednesday 26 July 2006 22:49:
  Because it is not a limitation but rather a gain. A *well* *done* and
  *well* *supported* scenegraph will help you some much more than you
  probably can imagine now.

 You completely miss the point: we are using ssg! There was no
 decision made to switch to osg. So, if we switch to ssg wrappers
 first, we lose capabilities, that we may or may not get back later.

 I don't accept that and object.

  In fact, a proper design - like a well done scenegraph provides

 You miss the point. We are using ssg!

  So why should we limit ourselves in the long term with ssg?

 Fact is: we are using ssg. We may or may not switch to osg later.
 There has *no* decision been made, so we can't rip out stuff now
 that osg may provide later. The way to go is:

  - formal decision to switch to osg (or at least to start working on it)
  - generate osg branch in cvs
  - parallel development

 In the osg branch you can do with the HUD what you like. But not
 in the current, *SSG* branch.

I believe that you miss the point.
The point is that we can, without loosing features, with a sensible design, 
prepare getting rid of ssg. As allmost allways, building sensible structures 
is a win even if no switch will happen.
Just blocking that is not a good idea.

... did you ever look at the sceens of csp.sf.net?

 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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-27 Thread Melchior FRANZ
* Mathias Fröhlich -- Thursday 27 July 2006 18:15:
 I believe that you miss the point.

That may be ...


 The point is that we can, without loosing features, with a sensible design, 
 prepare getting rid of ssg. As allmost allways, building sensible structures 
 is a win even if no switch will happen.

Sure. As I said: I'm still in favor of abstracting where possible,
and of switching to OSG (when it has been officially decided!).

I just won't drop raw gl-* commands when there is no replacement in
ssg. This would be at least a temporary loss that is not justified.
You said you have a lot of OSG transition work on your HD already,
which is fine. This is a *hard* piece of work, and we will all profit
from it. BUT: I don't disassemble fgfs in *CVS* now, when the propsed,
better replacement is on *your HD* only. You can get hit by a
lightning or run over by the proverbial bus, and all we have is a
broken fgfs in *CVS*, with none of your improvements available.



 Just blocking that is not a good idea.

I'm not blocking a good idea. I'm demanding a correct handling
of the whole matter. (A) discussion, (B) decision, (C) branching,
(D) entering the shiny world of osg.


 
 ... did you ever look at the sceens of csp.sf.net?

occasionally, yes. I also have osg/head here and love to look at
the stunning examples. And *still* I won't cripple the HUD code 
(even more) because of that.  :-P

m.

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-27 Thread Melchior FRANZ
* Melchior FRANZ -- Thursday 27 July 2006 18:31:
 (A) discussion, (B) decision, (C) branching, (D) entering the shiny
 world of osg. 

BTW: I would check this branch out, test it, and try to help, although
I'm afraid that I can't do much. The whole scene graph thing isn't my
thing, as you may have noticed.  ;-)

Meanwhile I'm reading the ssg documentation ... once again ...

m.


-- 
I could be wrong, of course. But I'm never wrong.  -- Linus TORVALDS

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-26 Thread Robin van Steenbergen
Melchior FRANZ schreef:
 We had talked about abstracting out the raw gl-commands into just
 one file, and then to use plib wrappers to plug the HUD into the
 scene graph. The plib wrappers could eventually get replaced by osg
 wrappers.

 The abstraction is still a goal, and so is plugging the HUD into
 the scene graph. But I think now that using plib/osg wrappers is
 a bad idea. This would prevent us from using some gl features for
 absolutely no good reason (e.g. line width, clipping, ...). And
 finally, ogl *is* a standard, while neither plib nor osg are. So
 why leaving the standard? Raw gl-code can still be plugged into
 the scene graph via callbacks, and the only thing that the wrappers
 would buy us is management of state changes for performance reasons.
 But the HUD code doesn't change that much, and this can be done
 manually, too.

 Why exactly would we want to limit ourselves?  :-}

 m.
   
I quite agree with this. The double advantage that you have is that you 
can use existing rendering code from other packages (e.g. OpenGC) since 
they boil down to raw OpenGL calls if you take an abstract look (from a 
GPU point of view). Rendering to texture would allow us to use those 
glass displays inside virtual cockpits or at least 2D panels, and I know 
a few aircraft with HUD's that are very similar to displays already 
constructed. Why reinvent the wheel? It wouldn't be that difficult to 
make a callback for the HUD every rendering cycle (when neccessary) and 
render either directly to framebuffer or a texture (which the HUD code 
doesn't know, it just draws lines, rectangles, text, etc.)
My own glass cockpit software does a similar thing with a few tricks. 
Every gauge file is a DLL (or a SO) containing only one callback routine 
which does nothing more than rendering the gauge with the given data. It 
doesn't know where you render it to (only its location in the viewport, 
which it needs for correct scaling and aspect) and it works great. IMO 
it works better than the pure OO approch that OpenGC uses, because you 
can distribute new features in binary form without needing a recompile 
every time. (Plug-in mechanism)

Bit OT here but a small question: Has FlightGear for the Mac been built 
for Universal Binary already? I've got a brand new Core Duo Mac Mini 
here and I've tested it on another Intel box and it just crashes on 
startup. It ran on a G3 but it was pretty much a slideshow...
If all else fails I'll try to make an OSX Intel-only build (since GCC 
comes standard with OSX) or just switch to the Win32 flavour, which runs 
fine on my Mini.

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-26 Thread Melchior FRANZ
* Robin van Steenbergen -- Wednesday 26 July 2006 19:43:
  Rendering to texture would allow us to use those 
 glass displays inside virtual cockpits

This possibility has already been dismissed, with good arguments.
Render-to-texture support isn't guaranteed on all graphics cards.
And, frankly, the results that I got so far weren't exactly great.
(I had a working render-to-texture HUD instrument and a test HUD
face in the bo105.)



 It wouldn't be that difficult to make a callback for the HUD every
 rendering cycle (when neccessary)

That's what I thought. Just plug a child-less plib (or osg or whatever)
scene graph node into the graph, with a render callback, and let that draw
the HUD with raw gl-commands. Advantage: glSetLineWidth(), glClipPlane(),
etc. etc.  :-)



 Bit OT here but a small question: Has FlightGear for the Mac been built 
 for Universal Binary already?

Yes, I think so. And I'm sure google knows more.  :-) 

BTW: the new HUD has seen some nice (IMHO :-) changes recently. There's
an aiming reticle (according to mil-std-1787b) with adjustable outer cirlce,
label boxes work and can now have arrows etc. Try this command line with
fgfs/cvs if you are curious (courtesy Curt :-):

  $ fgfs --aircraft=NTPS --prop:sim/hud/visibility\[1\]=1 
--prop:sim/hud/visibility\[0\]=0

More to come (gun-cross, waterline-mark, ...)

m.

-
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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel


Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers

2006-07-26 Thread Mathias Fröhlich

Hi,

On Wednesday 26 July 2006 19:20, Melchior FRANZ wrote:
 We had talked about abstracting out the raw gl-commands into just
 one file, and then to use plib wrappers to plug the HUD into the
 scene graph. The plib wrappers could eventually get replaced by osg
 wrappers.

 The abstraction is still a goal, and so is plugging the HUD into
 the scene graph. But I think now that using plib/osg wrappers is
 a bad idea. This would prevent us from using some gl features for
 absolutely no good reason (e.g. line width, clipping, ...). And
 finally, ogl *is* a standard, while neither plib nor osg are. So
 why leaving the standard? Raw gl-code can still be plugged into
 the scene graph via callbacks, and the only thing that the wrappers
 would buy us is management of state changes for performance reasons.
 But the HUD code doesn't change that much, and this can be done
 manually, too.

 Why exactly would we want to limit ourselves?  :-}
Because it is not a limitation but rather a gain. A *well* *done* and *well* 
*supported* scenegraph will help you some much more than you probably can 
imagine now.
In fact, a proper design - like a well done scenegraph provides - will enable 
such features in a much less error prone and more efficient way.
Also a *supported* scenegraph that is developed further will make use of 
improovements in OpenGL that an unsupported one like plib's ssg will never 
see. ssg forces you to do many things yourselves in a probably less efficient 
way with direct OpenGL calls, that can be done with a smarter implementation 
without such direct OpenGL commands.
There is nothing in OpenGL you cannot do with osg. But there is nowerdays 
nearly everything from current OpenGL features - even some basic ones like 
clip planes - that is missing in ssg, so that you need to implement that 
yourselves ...
Having that will be much more of a gain that a limitation ...

So why should we limit ourselves in the long term with ssg?

   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.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel