Re: [osg-users] Qt5 integration
On 17 Aug 2015, at 17:33, Riccardo Corsi riccardo.co...@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 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___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt5 integration
On 17 Aug 2015, at 09:48, Alistair Baxter alist...@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___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Qt5 integration
On 18 Aug 2015, at 09:44, John Vidar Larring john.larr...@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 http://doc.qt.io/qt-5/qopenglwidget.html: Adding a QOpenGLWidget http://doc.qt.io/qt-5/qopenglwidget.html 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 http://doc.qt.io/qt-5/qopenglwindow.html with QWidget::createWindowContainer http://doc.qt.io/qt-5/qwidget.html#createWindowContainer(). This is a modern alternative to QGLWidget and is faster than QOpenGLWidget http://doc.qt.io/qt-5/qopenglwidget.html 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 http://doc.qt.io/qt-5/qopenglwidget.html. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Android osgPlugins
On Sun, Aug 23, 2015 at 7:22 PM, Christian Kehl christian-k...@web.de wrote: Thanks for the explanation - never digged so much into the linker behaviour because usually libraries generate shared or static libraries consitently. This way into the Java sandbox and how to link dependency code for it was new to me. Still, in this case it was the only way I could make it work. This isn't really an Android or Java specific issue, it is an idiosyncracy of the GNU linker. I think the problem happens only when you are taking a static library (.a) and trying to convert it to a shared library (.so). This is possible in Linux (and Android), however, it involves relinking - and that is where things go wrong. If you don't tell the linker to include the whole archive (.a) file, it will optimize the unused code away. In extreme cases it will happily create a shared library that has no code inside ... Trying to link the OSG plugins (shared libraries) using static dependencies is similar use case - the linker included only symbols that were used by the rest of the plugin, but had no idea that it should include also symbols that are only needed by other modules after the shared library was loaded in memory. That is, IMO, a compilation bug - each module should be linked with everything it needs and not rely on the presence of a(nother) shared library at runtime to bring in those 3rd-party dependencies (I think it was zlib in your case). E.g. DLL compilation in Windows will fail for such unresolved symbols. In Linux it passes, because the linker allows late binding by default, assuming that the undefined symbols will be resolved at runtime by the dynamic linker. J. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] DDS textures not loading on Mac OSX and the latest trunk(3.5.0)
Hi, I had modified the code to just ignore all loaded mipmaps in a few of the plugins to fix it, but everything work in older versions of OSG. The code is so different now, it's hard to tell what change triggered the problem. David -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64879#64879 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
