Hi Morne, I've been able to reproduce the rendering issue with CompositeViewer with no View's using your modified example, and rather than dive into QT code that I'm not so familiar with I thought I'd recreate a similar usage of CompositeViewer in the osgcompositeviewer example.
I've now start coding up additions but have come unstuck in trying to work out how to create an CompositeViewer which has its own window that it renders to without there being any Camera's assigned to the viewer, as without any views you don't have any cameras, and it's the camera's that hold the references to the graphics windows, so there is no way to actually specify the type of viewer setup your propose, without changing to quite a different model. In your QT example you have a window that is created for you, and an graphics context assigned to it, then you assign this to viewer, even if you didn't assign it to a viewer you would have a window. Also if your delete all the views you'd still have the window as the window is owned by Qt rather than by the viewer. This makes the set up quite different than a standard osgViewer based viewer that owns everything. The way to replicate the QT viewer setup would be to keep a reference to the GraphicsWindow in the application main loop, so that even when you remove all the views you still keep the window alive. Once all the views were removed the viewer itself wouldn't know about the GraphicsWindow so it wouldn't be able to do any. This would mean that the application main loop would need to step in an do it's own clear and swap buffers on the GraphicsWindow while the viewer was inactive without a view to render. I guess a similar viewer.frame() by pass could be done in the QT case for when the viewer has no views. The other approach might be to create an empty View that does nothing, has no scene, but at least has a Camera with the GraphicsWindow assigned to it. It's viewport could be zero sized so would be litte more than a non op, and you have have the GraphicsWindow do the clear each frame for you. This approach why a bit inelegant would probably prevent the problems you are seeing, and would just require an additionally couple of lines of set up code at the creation time, thereafter you'd just ignore this extra View. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org