[osg-users] Using osgViewer::GraphicsWindowEmbedded Was: Renderer and SceneView classes

[Doug McCorkle]

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 <mccdo at 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