[osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes
mccdo at iastate.edu
Tue Nov 10 07:00:56 PST 2009
On Nov 10, 2009, at 8:42 AM, Robert Osfield wrote:
> Hi Doug,
> On Tue, Nov 10, 2009 at 2:20 PM, Doug McCorkle <mccdo at iastate.edu>
>>> 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
>> 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
> 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
>>> 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
>>> out of the OSG as well. If you want to do windowing yourself then
>>> 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
>> 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
>> 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?
More information about the osg-users