[osg-users] osgQt + OSG 3.6.2 Status

[Stuart Mentzer]

Circling back to my original issue, I got my OSG Qt viewer widget running with OSG 3.6.2 and osgQt by moving all the GL-related boilerplate after the main window show() call happens. I'm not sure what changed in Qt or osgQt to require this but this could be useful for other osgQt users.

Wojtek: thanks. I was already doing
camera->setDrawBuffer(GL_BACK)
but that does seem to be another thing that we didn't used to need. Maybe the osgQt docs should collect these migration tips.

A minor annoyance remains that I didn't have before: the OSG viewer is in a tab widget and I have to setCurrentWidget to a different tab and then back on to the OSG widget tab to get the OSG model to appear. No explicit repaint, updateGL, etc. calls worked.

On a related note, I got a tip to use

Code:
QApplication::setAttribute(Qt::AA_DontCheckOpenGLContextThreadAffinity, true);


to allow use of multithreading in Qt 5. It does allow things to run but I'm not sure if this is safe. Thoughts?

As far as the lively Qt discussion, I think you are all correct. Qt is probably the best cross-platform GUI framework we have AND it is deeply flawed. QML is nifty for mobile/etc GUIs but it is causing the C++ side to be neglected. Qt3D is getting pretty good but may not be up to serious visualization applications out of the box yet. E.g., I'll have to write a manipulator to get close to OSG's great trackball. Our application is well-layered so that we can easily keep experimenting in a Qt3D branch while using OSG for production builds. I hope that osgQt will keep up with Qt and that solutions for the integration and multithreading can be found. Maybe we can get more involvement from the Qt devs -- they are certainly aware and supportive of the OSG integration.

Cheers,
Stuart

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74418#74418