[osg-users] cant clear background in composite viewer

[Morné Pistorius]

Hi guys,

I am having trouble clearing the background on a composite viewer. I
have a composite viewer derived from QGLWidget to which I add and
remove views dynamically. The viewports are automatically tiled into a
number of rows and columns inside the viewer window to make the best
use of the available space, with a small gap between each view.

My problem is that I can't clear the background of the composite
viewer when I add/remove views. For example, if I had 4 views tiled
in a 2x2 matrix, and remove one view, I my tiler keeps two views in
the top row and 1 in the bottom row with an empty square where the
fourth view was. Although the fourth view was removed, I still see
some data drawn from the last frame that the removed viewer displayed.
Also, the gaps between the views shows garbage. I attached two
screenshots showing the problem.

Is there something that I could call on the composite viewer to clear
the entire window? It could also be a Qt problem, since the composite
viewer is derived from QGLWidget. If I resize the window after
removing the fourth view, then the background is cleared. I tried
calling repaint()/paintGL() on the QtWidget, but that didn't help.

I would appreciate pointers from people who have successfully used
composite viewers with Qt before.

Thanks a lot!

Morne

[Robert Osfield]

Hi Morne,

This isn't a bug, rather a limitation of using camera's to clear the
background colour of the graphics context. If your camera's don't
cover the whole window then you have tell the GraphicsContext to do a
clear - something it doesn't do by default for efficiency reasons - as
the vast majority of apps have camera's covering the whole graphics
context.

The osgcamera example has an example of enabling the clear of the
GraphicsContext. It's simply a case of doing a
window->setClearMask(..) and window->setClearColor(..);

Robert.

> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Morné Pistorius]

Hi Robert,

Thanks for the info. I had a look at the osgcamera example and
changed my code to call

getGraphicsWindow()->setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f));
getGraphicsWindow()->setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

in the constructor of my derived osgViewer::CompositeViewer. This
clears the viewer to green, but now none of my views show up inside
the composite viewer, the whole viewer is just green. When I add a
view, it is created like this:

osgViewer::View * pView = new osgViewer::View;
osg::Camera * pCamera = pView->getCamera();

pCamera->setGraphicsContext( getGraphicsWindow() );
pCamera->setClearColor( osg::Vec4( 0.05, 0.05, 0.2, 1.0 ) ) ;

addView( pView );

...compute viewport dimentions, etc...

pCamera->setViewport( new osg::Viewport( Left, Bottom ,
BestWindowWidth, BestWindowHeight ) );
pCamera->setProjectionMatrixAsPerspective( 30.0f, double(
BestWindowWidth ) / double( BestWindowHeight ), 1.0f, 10000.0f );

It is as if the call to clear the viewer comes after the call to
render the views and I just see the cleared result. Removing the
setClearColor/setClearMask in the constructor shows my views again.

Is it necessary to create a new GraphicsContexts for the cameras as in
the osgcameras example? I tried that, without success, so I guess I
must be missing something else. Attached is what I see.

Thanks again for the help!

Regards,
Morne

[Robert Osfield]

Hi Morne,

I'm rather perplexed that it didn't just work. The clear of the
graphics context/window should be done before everything else runs,
the construction order should have no effect on this as it's a feature
hard-wired into GraphicsContext. Is there a chance that you've
disabled the clear of the colour and depth buffer for the cameras?

Robert.

On Tue, Jan 27, 2009 at 11:18 AM, Morné Pistorius

[Morné Pistorius]

Not intentionally, no. I added

pCamera->setClearMask( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

to the camera attached to the view just to make sure, but it didn't
change anything. It sounds like a bug then, I will try and recreate
it in a simple example.

Cheers,
Morne

On Tue, Jan 27, 2009 at 11:36 AM, Robert Osfield

[Morné Pistorius]

Hello again Robert,

I modified the osgcompositeviewer example and setClearMask() works as
expected when creating a new graphics context with proper traits, etc.

I suspect my problem comes from using the graphics context created by
osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass
to my cameras) in our Qt app. It will take a bit of time to test my
theory, because I didn't build OSG with Qt support and need a proper
Qt install. I will do this now and see if I can reproduce the error
in osgviewerQt. I just thought I would mention it, maybe this hint
could shed some light on the problem.

Cheers,
Morne

On Tue, Jan 27, 2009 at 11:43 AM, Morné Pistorius

[Robert Osfield]

HI Morne,

Ahh the missing bit of the jigsaw - that fact that you are using
GraphicWindowEmbedded is key. The GraphicsContext::swapBuffers() is
normally what does the swap buffers and then calls
GraphicsContext::clear(), with GraphicsWindowEmbedded::swapBuffers()
it's a non op, because there is no way it can do a swap buffers as it
doesn't actually know about a real graphics context.

What you'll need to do in your own QT code is call
GraphicsContext::clear() explicitly after the swap buffers or prior to
calling frame()/renderingTraversals();

Robert.

On Tue, Jan 27, 2009 at 12:44 PM, Morné Pistorius

[Morné Pistorius]

Hi Robert,

As I expected, the problem lies with using a GraphicsWindowEmbedded.
I was able to reproduce the bug in oagviewerQt by adding

viewerWindow->getGraphicsWindow()->setClearColor(osg::Vec4f(0.0f,1.0f,0.0f,1.0f));
viewerWindow->getGraphicsWindow()->setClearMask(
GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT );

to the composite viewer. Attached is the example recreating the bug.

Cheers,
Morne

On Tue, Jan 27, 2009 at 12:44 PM, Morné Pistorius

[Jean-Sébastien Guay]

Hi Morné,

> I suspect my problem comes from using the graphics context created by
> osgViewer::GraphicsWindowEmbedded (this is the graphics context I pass
> to my cameras) in our Qt app.

You really shouldn't be using GraphicsWindowEmbedded even in a Qt app.
This is constraining you to single threaded use of OSG, and thus you're
not using your hardware to its full potential. Plus you're getting
problems because the way GraphicsWindowEmbedded works is not what you
expect.

Check out the osgviewerqt example (the --QOSGWidget part) to see how to
use a regular GraphicsWindowWin32/GraphicsWindowX11/GraphicsWindowCarbon
in conjunction with Qt. It's pretty simple, and will give you a tangible
benefit in performance in the end.

J-S
--
______________________________________________________
Jean-Sebastien Guay jean-seba...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/

[Morné Pistorius]

Hi Robert, J-S

As always, thanks again for the help, it is greatly appreciated.

I was able to solve this issue by calling

void VOSGTiledViewer::paintGL()
{

getGraphicsWindow()->setClearMask( GL_COLOR_BUFFER_BIT |
GL_DEPTH_BUFFER_BIT );

getGraphicsWindow()->clear();
getGraphicsWindow()->setClearMask( 0 );
frame();
}

If I don't reset the clearmask before calling frame, I don't see my
views, but the above solution gets met out of the hole. I will have a
look again at using QWidget - I went with the EmbeddedWindow approach
because we are only using OSG in single threaded mode (by design) and
it seemed simpler. Although, things like this might point to that
being false economy, maybe I need to redesign :)

Cheers,
Morne

[Robert Osfield]

Hi Morne,

Thanks for the example. This isn't a bug though, it's a limitation of
using GraphicsWindowEmbedded, just like you can't use
GraphicsWindowEmbedded for doing multi-threading or using it with
multiple windows, or having pbuffers used in the scene.

GraphicsWindowEmbedded is very limiting, only intended for basic
windowing integration, for full functionality you need to use a full
GraphicsWindow implementation. There isn't much we can do to make
GraphicsWindowEmbedded work in the same way as a full GraphicsWindow,
as it'll require the ability to know about the underlying graphics
context, and to do this you end up having to implement a full
GraphicsWindow so it ceases to be this super easy to use class that
you can use off the shelf.

For most serious graphics apps you'll need to use a full
GraphicsWindow implementation, as JS mentions, even in the case of QT
it uses the window inheritance feature of GraphicsWindow enables you
to use QT and all of the full functionality of OSG.

Robert.

On Tue, Jan 27, 2009 at 1:45 PM, Morné Pistorius