Hello Robert,
On Nov 10, 2009, at 8:42 AM, Robert Osfield wrote:
Hi Doug,
On Tue, Nov 10, 2009 at 2:20 PM, Doug McCorkle <mc...@iastate.edu>
wrote:
osgViewer can happily be an
implementation detail if VR juggler is flexible enough to not force
it's own window creation.
Correct, but again, that would assume that the OSG windowing
implementation
is better than what we already have. My personal opinion is that the
windowing implementation in VR Juggler is better but we can
disagree on this
point.
With the next rev of the OSG osgViewer will support both OpenGL 3.x,
OpenGL ES 1.1 and OpenGL ES 2.0, if VR Juggler supported osgViewer
with it's native windowing support then you'd get all this for free.
Without using osgViewer you'd need to implement your own windowing
support for these.
We had OGL 3 context creation in VR Juggler last March.
But... it rather does hobble the OSG in the way you are present
using
the OSG. You don't get access to the more sophisticated threading
models, RTT support, DatabasePager you have wire up yourself...
You are assuming we do not already have these tools....
RTT support in the OSG relies upon the ability to create on FBO and
PBuffers on demand, unless you've implemented your own integration of
PBuffers with the OSG then you'll be missing this capability.
No we have not and I can create an RTT camera without osgViewer.
I believe you can do all this with using osgViewer and you'll get
more
out of the OSG as well. If you want to do windowing yourself then
the
ideal tool would be to create the windows and then using
GraphicsWindow's ability to inherit the parent window to use.
Your comment above is the best option in my opinion but would
require OSG to
become a compile time dependency of VR Juggler. Right now OSG is
included in
1 file of VR Juggler which makes VR Juggler very portable.
I don't thinking using window inheritance would require much more
OSG/VRJuggler glue code than you presently have, it just be different
code. Window inheritance would leave the OSG able to create the GL3
and GLES contexts as well, so you'd get these features for free :-)
Very true but I am willing to pay the price to use a different
windowing API. Again, just another personal preference we can disagree
on.
I think another good option would be to figure out how to make
GraphicsWindowEmbedded work with multiple contexts. If we did this
then we
would have a direct SceneView replacement where all SceneView apps
could
easily migrate to osgViewer.
Once of the goals of GraphicsWindowEmedded is to provide similar
support to that of using SceneView directly, if you aren't able to use
it in this role then it's something I need to look at.
I was incorrect in my statement above. I can create an osgViewer for
every context which would be equivalent to creating an SceneView for
every context. I got some threads crossed in my mind.
Window inheritance is still far more flexible and powerful w.r.t OSG
capabilities so this is the route I'd recommend. SceneView and
GraphicsWindowEmbedded on their own hobble the OSG.
But this is your opinion that they are hobbling OSG. For folks like me
and I am sure some others in the OSG community both of these
interfaces provide a slick and easy way to get a majority of the OSG
support that they need with another software API. This enables the OSG
community to be larger and more active than without these interfaces
in place. I think this is one of the great things about the OSG. I can
grab as much or as little of the OSG as I need too. If I as a
developer am willing to give up some functionality in the OSG in using
these interfaces why should that matter?
Doug
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
