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

Reply via email to