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

Doug McCorkle mccdo at iastate.edu
Mon Nov 9 09:54:56 PST 2009

Hello Robert,

On Nov 9, 2009, at 11:41 AM, Robert Osfield wrote:

> Hi Doug,
> On Mon, Nov 9, 2009 at 3:52 PM, Doug McCorkle <mccdo at iastate.edu>  
> wrote:
>> After looking at both of the suggested examples (osgviewerSDL and
>> osgviewerGLUT) I have a couple of questions. First, with SceneView  
>> we handed
>> off the context ID to OSG, now it looks like we provide context  
>> information
>> to osgViewer through the window's initial position? Is this  
>> correct? Is
>> there anyway to hand off the context ID instead of using the
>> setUpViewerAsEmbeddedInWindow interface? Second, what is the  
>> appropriate way
>> to handle multiple contexts with the  GraphicsWindowEmbedded  
>> interface?
> One of the limits of GrapicsWindowEmbedded is that it can't
> automatically handle multi-threaded, multi-context usage.  You
> potentially could have multipe osgViewer::Viewer each with it's own
> GraphicsWindowEmbedded, and set the ContextID for each
> GraphicsWindowEmbedded by getting the doing
> graphicswindow->getState()->setContextID(i);.

Slick. So this would be very similar to what we are doing now with  
SceneView. Thanks for the insight.
> However, for multi-context work you really are better off using
> osgViewer::GraphicsWindow window inheritance.
>> Third, currently we do our update traversal and cull/draw on two  
>> separate
>> threads, what is the appropriate way to handle this? I do not see a  
>> way to
>> separate these two operations with the examples provided that use  
>> the frame
>> call.
> You can break viewer.frame() down into it' update and rendering
> dispatch components.

Thanks. I will look into this.

> If you use GraphicsWindow inheritance, or native GraphicsWindow
> generation you'll actually get all the threading you are already doing
> for free.
>> Fourth, we currently make calls to SceneView like:
>>        sv->setViewport( );
>>        sv->setProjectionMatrix( );
>>        sv->setViewMatrix( );
> Not much different:
> viewer.getCamera()->setViewport(..);
> viewer.getCamera()->seProjectionMatrix(..);
> viewer.getCamera()->seViewMatrix(..);
>> are these same calls made on the osgViewer camera just like in  
>> SceneView?
>> Fifth, we currently setup the OpenGL matrix stack with calls like:
>>    glPushAttrib( GL_ALL_ATTRIB_BITS & ~GL_TEXTURE_BIT );
>>    glPushAttrib( GL_TRANSFORM_BIT );
>>    glPushAttrib( GL_VIEWPORT_BIT );
>>    glMatrixMode( GL_MODELVIEW );
>>    glPushMatrix();
>>    glMatrixMode( GL_PROJECTION );
>>    glPushMatrix();
>>   //do cull/draw
>>    glMatrixMode( GL_PROJECTION );
>>    glPopMatrix();
>>    glMatrixMode( GL_MODELVIEW );
>>    glPopMatrix();
>>    glPopAttrib();
>>    glPopAttrib();
>>    glPopAttrib();
>> is this still required or is osgViewer hiding this somewhere?  
>> Thanks for the
> You could wrap this all around the viewer.renderingTraversals(); call
> if you want.  It's pretty hacky though doing all the push and pops.
> OpenGL 3.x and OpenGL ES 2.0 don't support such hacks so the days are
> numbered for this type of approach.

Yup. This will be disappearing in our app very soon with our OGL 3  
migration this spring.

> --
> I have to ask, what is the compelling reason to not to use osgViewer
> and role you own?  It does multi-thread, multi-context natively - it
> can do caves, power-walls and much more (such as distortion
> correction), it just a matter of configuring the viewer with the
> appropriate slave Cameras.

Candidly, I think that the VR Juggler configuration and device  
management is better than what is in OSG. I realize that is a personal  
preference but I like the VR Juggler windowing API and hardware  
management and configuration tools and implementation. I also like the  
leanness (it is a word amazingly) of the VR Juggler approach and  
implementation for windowing and device management. Most of what is  
supported in osgViewer I do not need or want. I really like the core  
OSG scenegraph and the file loaders but beyond that we do not need all  
of the event handling, manipulator tools, or other nodekit integration  
that osgViewer provides. We need a flexible scenegraph that we can  
control much of what is going on under-the-hood with windowing and  

Thanks again for the pointers above.


More information about the osg-users mailing list