[osg-users] Qt5 integration

[Riccardo Corsi]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150817/a9cea57d/attachment-0002.htm>