Hi James, I haven't looked into osg+qt integration since a while so I might not be aware of the latest features available.
>From my point of view the most desired feature is to be able to integrate a qt scene (a GUI layout or a browser/pdf/svg viewer widget) inside an osg driven application smoothly - i.e. without the need of a Qt application to run as main thread loop, but hiding it as a "slave" somewhere in an osg module/node, to make those widget pluggable in a "regular" osg application. Instead if you're interested, a while ago I coded an integration to render with osg inside a QtQuick+QML application. Basically the solution implements a custom QtQuick node which renders an osgViewer scene to an FBO, and then copies the FBO contents back to the Qt context, to make it available in the qt/qml scenegraph which renders the widgets. The osgQuickNode uses a separate OpenGL context, not to interfere with the one used by Qt for its own scene rendering. All the code is here: https://github.com/rickyviking/qmlosg If you have questions about the implementation feel free to write me. Ricky On Mon, Aug 17, 2015 at 12:54 PM, Robert Osfield <[email protected]> wrote: > HI Alistair, > > I'm not familiar with Qt5/QQuck2 so can't comment on the Qt side, so have > to defer to others on this. > > On the OSG side osgViewer is designed specifically to handle a thread per > graphics context/window - it's a core feature of how osg::GraphicsContext, > osg::GraphicsThread are designed and implemented. If Qt5 requires a thread > per window then this is a model that osgViewer can be capable of handling > since it's inception (well before Qt5), the only question would be to how > to integrate the threading in synchronization operations that Qt5 is > forcing upon the set up with the way that the OSG manages things. Perhaps > subclassing from osg::GraphicsThread might be one approach or other classes. > > I don't know if the other direction might be possible - stop Qt trying to > do everything that the OSG can already do perfectly without it. > > Robert. > > On 17 August 2015 at 09:48, Alistair Baxter <[email protected]> wrote: > >> As you are no doubt aware, James, we've been looking into this sort of >> integration ourselves. QQuick 2 integration is part of our goal, although >> we hadn't been planning direct interaction between QML and out osg scenes, >> since we have a separate data model. Although if such a thing existed, and >> were sufficiently convenient to use, then we might be interested in >> integrating it in a similar way to how we use the existing 3D osg >> manipulators. We've never really been interested in QWidgetImage, we only >> ever used it to try and get round a window composition issue on OSX. >> >> Our main concern at the moment is that we need a multi-window viewer. Due >> to the way Qt 5 has a separate opengl render thread per Window, this has >> meant reimplementing a significant chunk of OSGCompositeViewer in order to >> get it to work at all, and we are discovering a variety of >> thread-synchronisation issues. >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
