[osg-users] Qt5 integration

[James Turner]

Hi,

I’ve been re-working the osgQt code to fit the Qt5 windowing model closer - I have a basic proof of concept working, which I will clean up and publish shortly. This provides an osgViewer backed by a QWindow; so the widget and opengl module dependency is gone, the only Qt5 modules needed are Gui and Core.

A QWindow can be embedded in a traditional widget based application using QWidget::createWindowContainer; I will create an example of this approach as part of my submission. (And the performance of this approach is the same as the old QGLWidget inside GraphicsWindowQt).

What I’d like to know, is what other uses cases are relevant for people:

- I could re-create QWidgetImage, but using QWidget::render and avoiding any reliance on QGraphicsScene or QGraphicsProxy. If people have uses cases for QWidgetImage, that would be good to know. Especially, are you embedding ‘a few buttons’ or entire application layouts? Correctly handling keyboard focus is obviously something that’s been difficult in the current code and I expect to be similarly awkward.

- QtQuick2 integration; I’ll create a custom QQ2 item which renders OSG via a framebuffer. This will allow an OSG scene to be integrated with QQ2 UI, with reasonable performance. I would welcome any input from people who need this, and your particular requirements, especially the API for binding the osg Scene to the QML item. But, see the next point:

- I /hope/ to create a GraphicsWindowQtQuick which allows the common case of an OSG scene, with a QQ2 scene overlaid. This has some complexities to support the different OSG threading models and context lifetime, but it feels like such a common and desirable use case it’s worth spending time on.

- does anyone have a use for an equivalent of QWidgetImage for QtQuick2? I.e a chunk of QQ2 content displayed as a texture.

My intention would be to have any new classes live alongside the existing Qt4 support, since I don’t want to touch that code at all, for fear of regressing some aspect of the Qt4 support which someone may be relying upon in existing code.

If you have thoughts in this area, interesting requirements which might guide my approach, or test-case you can share, please let me know. I will definitely be doing the basic pieces outlined above, but whether I work on the QWidgetImage piece in particular depends very much on what response I get.

Kind regards,
James Turner

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[michael kapelko]

Hi.

As for me, I simply use Qt integration to display Viewer, no special thing.

Looking forward to your release.

[Alistair Baxter]

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.

[Robert Osfield]

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.

[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

[Werner Modenbach]

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 <riccard...@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....@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 eve rything that the OSG can already do perfectly without it.

Robert.

On 17 August 2015 at 09:48, Alistair Baxter <alis...@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-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[John Vidar Larring]

Hi James,

I've attempted to update the osgQt code to use the new QOpenGLWidget rather than the deprecated QGLWindow currently subclassed, but I've hit a snag with the the order of when when QOpenGLContext is created and when CompositeViewer expects it to be available (Probably a silly mistake that I'm overlooking). Have you had to restructure the osgQt::GraphicsWindow or osgQt::GLWindow class and the osgViewerQt example in any way to get your implementation to work? 

Also, I would like to know why you chose to use QOpenGLWindow rather QOpenGLWidget considering the Qt documenation below.

From http://doc.qt.io/qt-5/qopenglwidget.html:

Adding a QOpenGLWidget into a window turns on OpenGL-based compositing for the entire window. In some special cases this may not be ideal, and the old QGLWidget-style behavior with a separate, native child window is desired. Desktop applications that understand the limitations of this approach (for example when it comes to overlaps, transparency, scroll views and MDI areas), can use QOpenGLWindow with QWidget::createWindowContainer(). This is a modern alternative to QGLWidget and is faster than QOpenGLWidget due to the lack of the additional composition step. It is strongly recommended to limit the usage of this approach to cases where there is no other choice. Note that this option is not suitable for most embedded and mobile platforms, and it is known to have issues on certain desktop platforms (e.g. OS X) too. The stable, cross-platform solution is always QOpenGLWidget.

Would love to see / contribute / comment on your osg qt5 integration. 

Best  regards,

John

--
This email was Anti Virus checked by Astaro Security Gateway. http://www.sophos.com


--
This email was Anti Virus checked by Astaro Security Gateway. http://www.sophos.com

--

 


John Vidar Larring | Senior Developer

ChyronHego Norge AS - Sandakerveien 114a, 0484 Oslo, Norway
Office. +47 2279 7030 - Mobile.+47 4889 9795 - www.chyronhego.com

[Riccardo Corsi]

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

[James Turner]

On 17 Aug 2015, at 09:48, Alistair Baxter <alis...@mve.com> wrote:

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.

Alistair, we might need to have an in-depth chat about this, and I have some other folks I can ask about it, but there’s no correlation between QOpenGLContext (and its associated thread) and QWindow, at least as I understand it.

But, I’m unfamiliar with the CompositeViewer, can you outline (in private email if needs be) what structure you are trying, and where it’s going wrong? (I believe you know my work email if that’s easier, I won’t start the clock since this education time project for me… ;)

Kind regards,

James

[James Turner]

On 17 Aug 2015, at 17:33, Riccardo Corsi <riccard...@kairos3d.it> wrote:

Thanks Ricky.

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.

As someone else pointed out, this is a less common scenario for what I’m trying to support. What I care more about is people who want to use Qt for the thing it’s good at, and integrate OSG within it. So they typically want menus, dialogs etc from QWidgets or QQ2 (potentially including Qt Quick Controls). That’s the use case I’m focusing on for now.

Hiding Qt introduces a lot of complexity and also trades that rather detailed, tailored Qt event loops on each platform, for the rather basic ones in each of the GraphicsWindow subclasses. 

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.

The solution you propose of a custom QtQuick node rendering OSG is definitely interesting to me, and I would guess your code is likely 90% the same as what I would write, so with your permission I might attempt to merge it with my submission, once I have time to review it.

Kind regards,

James

[James Turner]

On 18 Aug 2015, at 09:44, John Vidar Larring <john.l...@chyronhego.com> wrote:

I've attempted to update the osgQt code to use the new QOpenGLWidget rather than the deprecated QGLWindow currently subclassed, but I've hit a snag with the the order of when when QOpenGLContext is created and when CompositeViewer expects it to be available (Probably a silly mistake that I'm overlooking). Have you had to restructure the osgQt::GraphicsWindow or osgQt::GLWindow class and the osgViewerQt example in any way to get your implementation to work? 

I’ve had to restructure osgViewerQt a little, because I didn’t try to get the CompositeViewer working yet.

Also, I would like to know why you chose to use QOpenGLWindow rather QOpenGLWidget considering the Qt documenation below.

From http://doc.qt.io/qt-5/qopenglwidget.html:

Adding a QOpenGLWidget into a window turns on OpenGL-based compositing for the entire window. In some special cases this may not be ideal, and the old QGLWidget-style behavior with a separate, native child window is desired. Desktop applications that understand the limitations of this approach (for example when it comes to overlaps, transparency, scroll views and MDI areas), can use QOpenGLWindow with QWidget::createWindowContainer(). This is a modern alternative to QGLWidget and is faster than QOpenGLWidget due to the lack of the additional composition step. It is strongly recommended to limit the usage of this approach to cases where there is no other choice. Note that this option is not suitable for most embedded and mobile platforms, and it is known to have issues on certain desktop platforms (e.g. OS X) too. The stable, cross-platform solution is always QOpenGLWidget.

My personal take is that the QOpenGLWidget approach is inferior to the QOpenGLWindow+createWindowContainer approach, because of the slightly rapid way it was introduced, and the tradeoffs it makes in composting the different elements. However, this is subjective, and I will cheerfully support both, because as the documentation you pasted notes, there are cases where each approach is better or worse.

Note that from my understanding, the QOpenGLWidget approach will effectively force OSG into single threaded mode, becuase tge API gives no control over when makeCurrent is called, or which thread paintGL is called on. (But I need to check this with some colleagues and lazlo who created the code). In contrast my QWindow-based approach supports all the OSG threading modes directly.

I expect to end up with three different window options:

- osgQt::GraphicsWindowQt5 - gives you a QWindow, can be embedded with createWindowContainer or used standalone

(QtGui dependency only)

- osgQt::GraphicsWidget - gives you a QOpenGLWidget

(QtWidget dependency)

- osgQt::GraphicsWindowQtQuick - gives a window similar to QQuickWindow/QQuickView which can have a QML file setSource()-ed on it

(QtGui + QtQuick2 dependency)

I have the first case done, will work on the second and third cases now, before worrying about QWidgetImage and other less common forms of integration.

Kind regards,

James

[John Vidar Larring]

Hi James,

Thanks for your in depth answer.  Please let me know it there's any way that I can contribute (E.g. testing on CentOS 6).

Best regards,

John

--

[John Vidar Larring]

Hi James,

While you attention is directed towards integrating Qt5 and OSG, have you considered the use case for offscreen rendering? In the osg::Viewer module, there are PixelBufferWin32 and PixelBufferX11 classes that implements the osg::GraphicsContext abstract class for offscreen pixelbuffer rendering on respective platforms. Ref.:

http://trac.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a00342.html

A potential osgQt::PixelBufferQt could implement  osg::GraphicsContext using QOpenGLContext (http://doc.qt.io/qt-5/qopenglcontext.html#QOpenGLContext) in conjunction with QOffscreenSurface (http://doc.qt.io/qt-5/qoffscreensurface.html). This would be useful for applications providing batch rendering services.

What are your thoughts on this?

Best regards,

John

--

 

[Riccardo Corsi]

Hi James,

sorry for the late reply!

Please, feel free to review and merge my code, let me know if you need clarifications.

Ricky