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

Paul Martz pmartz at skew-matrix.com
Mon Nov 9 09:09:31 PST 2009

Doug McCorkle wrote:
> Hello Robert,
> 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?

My understanding is that you create your own window and context, and 
make them current, then call setUpViewerAsEmbeddedInWindow. (Honestly, 
I'm not cure why osgViewer needs the window size passed as params; it 
seems like osgViewer could just query them from the window system. Maybe 
Robert can elaborate?)

  Second, what is the appropriate
> way to handle multiple contexts with the  GraphicsWindowEmbedded 
> interface?

So, for example, your app opens multiple windows, each with their own 
context, say for a tiled display or CAVE... You only have one View (with 
multiple slave cameras) so it seems like this should work. Robert?

  Third, currently we do our update traversal and cull/draw on
> two separate threads, what is the appropriate way to handle this?

This is a good question. Under the embedded model, you own context 
management, so the osgViewer threading models don't come in to play. I 
think the answer is that you use one thread to call 
Viewer::updateTraversal, and then you fire off concurrent threads to 
execute Viewer::renderingTraversals.

Basically, you need to look at the internals of frame() to see what you 
need to do. (Keep in mind that Viewer derives from ViewerBase, so be 
sure to look at both classes for relevant code).

  I do
> not see a way to separate these two operations with the examples 
> provided that use the frame call. Fourth, we currently make calls to 
> SceneView like:
>         sv->setViewport( );
>         sv->setProjectionMatrix( );
>         sv->setViewMatrix( );
> are these same calls made on the osgViewer camera just like in 
> SceneView?

Pretty much, yes.

  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 help.

I don't think osgViewer would be able to hide it; you can search the 
source code to see what it does. I don't think you have a need to push 
and pop the matrix stack around your draw, unless you have code outside 
of cull and draw that depends on the matrices being set a certain way.

I hope this helps.

More information about the osg-users mailing list