Hi Ricky, I understand your point of view here. But I think there are multiple use cases. If I understand your approach well you intend having a 3d rendering app with some nice qt based features. On the other hand we are developing a lot of software in the textile environment and 3d simulation of the fabric is just an optional add-on. So the main aspect in our case is having a geometry managed embedded window showing an ist scene. So for us James's contribution is just what we need. As I said before, there are many scenarios for interacting qt and osg.
On 17. August 2015 18:33:46 MESZ, Riccardo Corsi <[email protected]> wrote: >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
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
