[osg-users] osgQt + OSG 3.6.2 Status

[Wojciech Lewandowski]

Hi Stuart,

I understand my setDrawBuffer / setReadBuffer observation was probably not
the only problem. But I believe this one is genuine problem that should not
be neglected. So I decide to write this small followup and elaborate a bit
to make it clearer. In the meantime I did some more research on
DrawBuffer/ReadBuffer calls made in OSG. [disclaimer]: We use OSG 3.4.0 and
I did not check latest OSG versions. So if anyone uses later 3.6.x he/she
may check if my observations are still valid. I did however, noticed that
plain osgViewer window config setups call camera->setDrawBuffer /
camera->setReadBuffer for main window cams. See
osgViewer\config\SingleWindow.cpp for example (search for setDrawBuffer).
And I did notice that the same is NOT done in osgQT window setup. At least
in OSG 3.4.0 release we use, osgQT does not call setDrawBuffer /
serReadBuffer for camera set in QT window.  And I believe this is a bug.
setDrawBuffer/setReadBuffer should be called for any top window camera.
Because if not, and if you add some other camera which will explicitly or
implicitly invoke glDrawBuffer call with other buffer than the one set by
default in window creation, you are most likely going to see black screen.

Sorry if I am clogging the thread. But just wanted to clarify this. Hope
this may help someone,

Cheers,
Wojtek Lewandowski


niedz., 29 lip 2018 o 23:04 Stuart Mentzer <osgforum at tevs.eu> napisał(a):

> 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
>
>
>
>
>
> _______________________________________________
> 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/20180730/96e67863/attachment.html>