[osg-users] Qt5 integration

Werner Modenbach Werner.Modenbach at texion.eu
Mon Aug 17 09:54:17 PDT 2015


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 <riccardo.corsi at kairos3d.it> 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
><robert.osfield at gmail.com>
>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 <alistair at mve.com> 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
>>> osg-users at lists.openscenegraph.org
>>>
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>>
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>osg-users mailing list
>osg-users at lists.openscenegraph.org
>http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150817/58c95755/attachment-0003.htm>


More information about the osg-users mailing list