Hi Werner, no problem, I was just sharing some use cases.
Regarding the embedding use case you mention, if that is QtQuick/qml based, you're most welcome to take a look to the implementation I mentioned in my previous email, hopefully that might helpful for your development. Cheers, Ricky On Mon, Aug 17, 2015 at 6:54 PM, Werner Modenbach < [email protected]> wrote: > 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 eve rything 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 > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
