Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Werner, On Tue, 11 Sep 2018 at 12:02, Werner Modenbach wrote: > My integration is dated April 2013 and I didn't need any changes since then. It might not have any issues with the usage case you have, but it doesn't necessarily mean that it will work with all usage cases. One area that broke causing problems for some users was when render to texture was used with a Qt/OSG application. The OSG would set/reset OpenGL glRead/DrawBuffer state based on the values set up for the osg::Camera. All the src/osgViewer/config implementation correctly set the Camera::setDrawBuffer/setReadBuffer() values for single and double buffer windows rather than leave as defaults. You may be able to get away with not setting the Camera::setDrawBuffer/ReadBuffer settings if you don't use render texture, but even then you are still leaving a bit dangerously, you are basically running with "uninitialzed" values. In the osgQt repo we fixed things so that the examples do correctly set up the osg::Camera, but we can't fix 3rd party code that is living out there in user applications, the best we can do is discuss the issue. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Werner,
We share the same belief around Qt.
Concerning your implementation, it's not clear how you integrate the OpenGL
window into Qt. If you are willing to share a simple application that
demonstrates your setup that would be a nice start to understand and
discuss your approach ?
Recent versions of Qt5 use OpenGL to render many UI components and thus it
is not unfrequent to have many OpenGL context created inside an
application. It is my understanding that QOpenGLWidget and QOpenGLWindow
manage to make these OpenGL context handling transparent.
The main difference between these two is that the QOpenGLWidget is rendered
inside a ImageBuffer or something like that and that the QOpenGLWindow
mimics the Qt4's QGLWidget we were used to allowing QuadBuferring etc.. But
being a Window lots of the Widget inherited things have to be implemented
(mostly UI events).
Regards
--
nǝıɥʇɐƜ
On Tue, 11 Sep 2018 at 13:02, Werner Modenbach
wrote:
> Hi Mathieu,
>
> thanks for your support for OSG/Qt integration. I think there are really
> many people using OSG together with Qt.
> Qt is just great for building multi environment user interfaces.
> But there is one thing I don't really understand. There is some discussion
> sometimes about difficulties in this integration.
> My integration is dated April 2013 and I didn't need any changes since
> then.
>
> class Cl_3D_OsgViewer_QT : public QWidget, public osgViewer::Viewer {...
>
> It works without any problems with every version of Qt since that time.
> So where is the problem?
>
> OK, I'm not using VS 20xx but Qt Creator and g++ instead. Maybe that makes
> the difference. But in this case
> it isn't really a problem of Qt integration but a VS problem.
> I see that some people tend integrating OSG into QOpenGLWindow. In my
> opinion this is a stony way
> because Qt GL wasn't that stable and finally decided since many years now.
> So things change frequently
> and this is always causing headache for keeping integrations running.
>
> On the other hand I think there is nothing more developed and stable than
> QWidget.
> If someone needs help send me a PM and I'm willing to share my integration
> class.
>
> - Werner -
>
> Am 10.09.2018 um 18:42 schrieb Mathieu MARACHE:
>
> Back from holidays...
>
> Community support is thin when considering OpenSceneGraph with Qt. I am
> currenlty the only maintainer of osgQt because I have a software using it
> and I didn't want the project to be tossed out.
>
> The Qt4 way of doing things with legacy osgQt (that was droped from
> OpenSceneGraph) doesn't fit well with the Qt5 way of doing things. Since
> Qt5.7 there are even incompatibilities (black screens, etc.).
>
> Qt4 support is getting difficult, even debian is dropping Qt4 (
> https://wiki.debian.org/Qt4Removal).
>
> In anticipation I have proposed to drop Qt4 and concentrate only on Qt5.
> Robert only asked to keep the Qt4 version around and make it clear which
> version of osg compiles with which version/branch of osgQt.
>
> There is a feature branch (since Feb '18) of the Qt5 way of doing things
> awaiting testing and validation from the community. This is the code I use
> in my application which was crafted by paid support from KDab's Mike Krus
> (from which I had authorization to open source).
>
> https://github.com/openscenegraph/osgQt/tree/feature/osgQOpenGL
>
> Regards
> --
> nǝıɥʇɐƜ
>
>
> On Mon, 30 Jul 2018 at 17:07, Robert Osfield
> wrote:
>
>> On Mon, 30 Jul 2018 at 15:59, Andrew Cunningham wrote:
>> >
>> > Back on the original topic :)
>> >
>> > This is a really simple QtOSGWidget that I used as a starting point for
>> an OSG widget in a QDialog. Simple and works fine.
>> >
>> > https://github.com/vicrucann/QtOSG-hello
>>
>> Just had a quick look at the code. It only works "fine" because there
>> it's a trivial example, it's buggy. Please compare to the the
>> osg::Camera setup in the osgQt master and see if you can see the
>> error, in this example. If you can then you'll be able to spot what
>> to fix in your own programs.
>>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> ___
> osg-users mailing
> listosg-users@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Mathieu,
thanks for your support for OSG/Qt integration. I think there are really
many people using OSG together with Qt.
Qt is just great for building multi environment user interfaces.
But there is one thing I don't really understand. There is some
discussion sometimes about difficulties in this integration.
My integration is dated April 2013 and I didn't need any changes since then.
classCl_3D_OsgViewer_QT:publicQWidget,publicosgViewer::Viewer{...
It works without any problems with every version of Qt since that time.
So where is the problem?
OK, I'm not using VS 20xx but Qt Creator and g++ instead. Maybe that
makes the difference. But in this case
it isn't really a problem of Qt integration but a VS problem.
I see that some people tend integrating OSG into QOpenGLWindow. In my
opinion this is a stony way
because Qt GL wasn't that stable and finally decided since many years
now. So things change frequently
and this is always causing headache for keeping integrations running.
On the other hand I think there is nothing more developed and stable
than QWidget.
If someone needs help send me a PM and I'm willing to share my
integration class.
- Werner -
Am 10.09.2018 um 18:42 schrieb Mathieu MARACHE:
> Back from holidays...
>
> Community support is thin when considering OpenSceneGraph with Qt. I
> am currenlty the only maintainer of osgQt because I have a software
> using it and I didn't want the project to be tossed out.
>
> The Qt4 way of doing things with legacy osgQt (that was droped from
> OpenSceneGraph) doesn't fit well with the Qt5 way of doing things.
> Since Qt5.7 there are even incompatibilities (black screens, etc.).
>
> Qt4 support is getting difficult, even debian is dropping Qt4
> (https://wiki.debian.org/Qt4Removal).
>
> In anticipation I have proposed to drop Qt4 and concentrate only on
> Qt5. Robert only asked to keep the Qt4 version around and make it
> clear which version of osg compiles with which version/branch of osgQt.
>
> There is a feature branch (since Feb '18) of the Qt5 way of doing
> things awaiting testing and validation from the community. This is the
> code I use in my application which was crafted by paid support from
> KDab's Mike Krus (from which I had authorization to open source).
>
> https://github.com/openscenegraph/osgQt/tree/feature/osgQOpenGL
>
> Regards
> --
> nǝıɥʇɐƜ
>
>
> On Mon, 30 Jul 2018 at 17:07, Robert Osfield > wrote:
>
> On Mon, 30 Jul 2018 at 15:59, Andrew Cunningham > wrote:
> >
> > Back on the original topic :)
> >
> > This is a really simple QtOSGWidget that I used as a starting
> point for an OSG widget in a QDialog. Simple and works fine.
> >
> > https://github.com/vicrucann/QtOSG-hello
>
> Just had a quick look at the code. It only works "fine" because there
> it's a trivial example, it's buggy. Please compare to the the
> osg::Camera setup in the osgQt master and see if you can see the
> error, in this example. If you can then you'll be able to spot what
> to fix in your own programs.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
>
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Mathieu MARACHE writes: > Back from holidays... > > Community support is thin when considering OpenSceneGraph with Qt. I > am currenlty the only maintainer of osgQt because I have a software > using it and I didn't want the project to be tossed out. > > The Qt4 way of doing things with legacy osgQt (that was droped from > OpenSceneGraph) doesn't fit well with the Qt5 way of doing > things. Since Qt5.7 there are even incompatibilities (black screens, > etc.). > > Qt4 support is getting difficult, even debian is dropping Qt4 > (https://wiki.debian.org/Qt4Removal). > > In anticipation I have proposed to drop Qt4 and concentrate only on > Qt5. Robert only asked to keep the Qt4 version around and make it > clear which version of osg compiles with which version/branch of > osgQt. > Dropping Qt4 seems sensible, as almost nobody is going to start learning Qt from version 4 (Qt downloads point directly to version 5 since long time ago). Experienced developers can easily find a tag/branch pointing to whichever older version they want. > > There is a feature branch (since Feb '18) of the Qt5 way of doing > things awaiting testing and validation from the community. This is the > code I use in my application which was crafted by paid support from > KDab's Mike Krus (from which I had authorization to open source). > > https://github.com/openscenegraph/osgQt/tree/feature/osgQOpenGL > Thanks a lot for this! -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Back from holidays... Community support is thin when considering OpenSceneGraph with Qt. I am currenlty the only maintainer of osgQt because I have a software using it and I didn't want the project to be tossed out. The Qt4 way of doing things with legacy osgQt (that was droped from OpenSceneGraph) doesn't fit well with the Qt5 way of doing things. Since Qt5.7 there are even incompatibilities (black screens, etc.). Qt4 support is getting difficult, even debian is dropping Qt4 ( https://wiki.debian.org/Qt4Removal). In anticipation I have proposed to drop Qt4 and concentrate only on Qt5. Robert only asked to keep the Qt4 version around and make it clear which version of osg compiles with which version/branch of osgQt. There is a feature branch (since Feb '18) of the Qt5 way of doing things awaiting testing and validation from the community. This is the code I use in my application which was crafted by paid support from KDab's Mike Krus (from which I had authorization to open source). https://github.com/openscenegraph/osgQt/tree/feature/osgQOpenGL Regards -- nǝıɥʇɐƜ On Mon, 30 Jul 2018 at 17:07, Robert Osfield wrote: > On Mon, 30 Jul 2018 at 15:59, Andrew Cunningham wrote: > > > > Back on the original topic :) > > > > This is a really simple QtOSGWidget that I used as a starting point for > an OSG widget in a QDialog. Simple and works fine. > > > > https://github.com/vicrucann/QtOSG-hello > > Just had a quick look at the code. It only works "fine" because there > it's a trivial example, it's buggy. Please compare to the the > osg::Camera setup in the osgQt master and see if you can see the > error, in this example. If you can then you'll be able to spot what > to fix in your own programs. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
On Mon, 30 Jul 2018 at 15:59, Andrew Cunningham wrote: > > Back on the original topic :) > > This is a really simple QtOSGWidget that I used as a starting point for an > OSG widget in a QDialog. Simple and works fine. > > https://github.com/vicrucann/QtOSG-hello Just had a quick look at the code. It only works "fine" because there it's a trivial example, it's buggy. Please compare to the the osg::Camera setup in the osgQt master and see if you can see the error, in this example. If you can then you'll be able to spot what to fix in your own programs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Back on the original topic :) This is a really simple QtOSGWidget that I used as a starting point for an OSG widget in a QDialog. Simple and works fine. https://github.com/vicrucann/QtOSG-hello -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74426#74426 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
On Mon, 30 Jul 2018 at 11:00, Wojciech Lewandowski wrote: > I find your response as rather harsh and wonder why it hits me. Thats why I > feel the need to reply. My response is blunt because I'm frustrated that despite my best efforts to community clearly to the community and asking *specifically* that Qt users pay attention, it's passed by. There is public record both on the ML/forum and in the githib histories for osgQt. People are wasting their own time, mine and other peoples time by not paying attention when announcements directed at then get ignored. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi, Robert I find your response as rather harsh and wonder why it hits me. Thats why I feel the need to reply. Sigh So it's good you guys are getting somewhere. Sorry, we don't use 3.6 yet and haven't seen this announcement. And I am glad its fixed in 3.6 already. Its a pity I doubled your effort. But when I saw my problem and started debugging it I was not aware it will bring me to our custom QT window creation because at first it looked like osgEarth REX internal issue. In fact I was not even aware our main window is made as QT window (pleasures of agile working environment ;-). So when I finally went through 3 days of debugging I decided to write about my observations because it sounded like black screen issue mentioned in this thread and was hoping to save that debugging time for others. Unfortunately I cannot say it will fixe QT issues others may have, as it was a specific problem with custom QT integration code loosely based on osgQT from OSG 3.4.x. So my proposition was also rather loose. I just decided to let people know about it in hope it may help someone. It's not an OSG bug in 3.6.2, it's a bug in your Qt code that was hidden > from view due to an old bug in the OSG that when fixed revealed the lack > of proper setup code in custom OSG/Qt integration. Exactly. This was a bug in our custom code based on osgQT from 3.4. Unfortunately I was not involved in making this custom code but had to integrate new osgEarth REX engine and debuging the issue brought me there. If you have custom integration then there isn't anything that osgQt dev's > or myself can do other than ask you to pay attention when we announce > fixes and ask you to fix you Yes, I fixed our custom code by adding setDrawBuffer/setReadBuffer lines. But I found it and fixed it myself so didn't expect you to do anything about it. I posted my observations in this thread because wanted to share the knowledge I gained through long debuging sessions. Cheers, Wojtek Lewandowski pon., 30 lip 2018 o 10:09 Robert Osfield napisał(a): > Hi Wojtek, > > On Mon, 30 Jul 2018 at 08:53, Wojciech Lewandowski > wrote: > > 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 i > f 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. > > Sigh So it's good you guys are getting somewhere. The sad thing > is that you are re-inventing the wheel w.r.t the issue. > > A few months back I investigated a bug that some osgEarth/Qt users > were seeing and it was down to missing setRead/setDrawBuffers() a bug > that had lingered long in the code, bit only recently highlighted > because of fixes to the core OSG. I made the fix to osgQt and the > osgEarth team fixed their Qt example. I made a very clear public > announcement called for the attention of all Qt users that they should > add setDrawBuffer/setReadBuffer(). There isn't anything more I could > have done. > > Please go back to my announcement thread. It's not an OSG bug in > 3.6.2, it's a bug in your Qt code that was hidden from view due to an > old bug in the OSG that when fixed revealed the lack of proper setup > code in custom OSG/Qt integration. If you have custom integration > then there isn't anything that osgQt dev's or myself can do other than > ask you to pay attention when we announce fixes and ask you to fix you > code. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Wojtek, On Mon, 30 Jul 2018 at 08:53, Wojciech Lewandowski wrote: > 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 i f 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. Sigh So it's good you guys are getting somewhere. The sad thing is that you are re-inventing the wheel w.r.t the issue. A few months back I investigated a bug that some osgEarth/Qt users were seeing and it was down to missing setRead/setDrawBuffers() a bug that had lingered long in the code, bit only recently highlighted because of fixes to the core OSG. I made the fix to osgQt and the osgEarth team fixed their Qt example. I made a very clear public announcement called for the attention of all Qt users that they should add setDrawBuffer/setReadBuffer(). There isn't anything more I could have done. Please go back to my announcement thread. It's not an OSG bug in 3.6.2, it's a bug in your Qt code that was hidden from view due to an old bug in the OSG that when fixed revealed the lack of proper setup code in custom OSG/Qt integration. If you have custom integration then there isn't anything that osgQt dev's or myself can do other than ask you to pay attention when we announce fixes and ask you to fix you code. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
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 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@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
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@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Joshua, I fully agree with you. We are developing commercial software and started with plenty of years ago. About 10 years ago we started to use osg and embedded osg view into a qt widget based on the osg-qt project at that time. It worked smoothly since then. Now we are on the latest releases of osg and qt and we never had to touch our embedding class. The only thing I am missing is the compatibility of threading. But we can live with that and I'm not limited in threading inside qt. Qt is great for development of cross platform user interfaces and frees me of Microsoft related usage of system interfaces. During all those many years there were only 2 cases where something didn't work as expected. But we could debug and fix it due to open source. So we are happy with the combination of qt and osg. Both are reliable, stable and have excellent features in their field. Werner On 27. Juli 2018 19:19:17 MESZ, Joshua Tree wrote: >I have to chip in here. Qt is the most reliable, industry standard UI >for C++, period. In part this success is due to the moc >autogeneration, which could get you out of SFINAE madness. > >Now, there are huge firms that adopted Qt for decades and run multi >billion dollars systems on it. > >That said, the Qt source is online and you can modify it as you wish to >test a solution. It is puzzling to me how this is still a pending and >recurrent issue for over a decade and a half I follow OSG. > > > I have used Qt and OSG back in 2003, 15 years ago with success. > >> On Jul 27, 2018, at 12:03 PM, Robert Osfield > wrote: >> >> Hi Andrew, >> >>> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham >wrote: >>> I would agree QT is not perfect but on the flip-side >>> - It is the 'last man standing' of x-platform UI's. >> >> This is down to the weakness of the alternatives rather as much as >the >> strength of Qt. >> >>> - It's actively developed using the latest C++11/14 standards and >supported by both a commercial organization and a robust LGPL community >> >> Will they get rid of the non standard C++ extensions and >pre-compiling nonsense? >> >>> - Is has a new lease of life through PyQT5 and PySide being the >'de-facto' way to build Python based desktop UI's. >>> - QML is quite interesting >> >> There is simply too much pushed into Qt over the years. The lack of >> focus on the core functionality hurts it. >> >> I say this from experience, we've pushed too much functionality into >> the OpenSceneGraph distribution over the years, I can see the >> mistakes, but with backwards compatibility being an important factor >> for end users it's not easy to just make radical changes. >> >> What the computer industry is a nice neat, small C++11 UI library >with >> good hooks to building scripting integration on top of. >> >>> I don't know why QT and OSG seem to fight each other so much, but it >seems a PITA to get things working properly as the OP and I have both >found mysterious issues popping up that require trips into the debugger >and the QT and OSG source. I had to advocate for OSG as other >developers were keen to use QT3D instead. >> >> OSG integration with 3rd party windowing toolkits has generally been >> pretty straight forward - once the basics have been written it >doesn't >> take much to update and keep things working. >> >> Our experience with Qt is not like this at all. X11, Win32 they've >> been pretty rock solid for way over a decade now. OSX has required >> jumping through a hoops because Apple doesn't care about developers >as >> much as it cares about vendor lock-in. >> >> Over the years the OSG hasn't added extra burden on the 3rd party >> windowing toolkits, it's exactly the same as it has always been, just >> create a GL context and allow the OSG to call makeCurrent() and >> swapBuffers and we are pretty well done. It *should* be simple. It >> is requires is the 3rd party windowing toolkit not to screw around >> with things. It's Qt screwing around with things that is breaking >> things, they have lost sight of what the Windowing API should be >doing >> and trading on the toes of application develop codes/3rd party SDK's >> like the OSG. >> >> Qt *is* broken in this respect. It really should be down to the Qt >> support to help you work out how to fix this. >> >> -- >> >> It terms of thinking about migrating away from OpenSceneGraph to >Qt3D, >> this might solve the Qt integration issue, but it just further >cements >> the lock-in to Qt, you'll end up tied to their future success or >> failures. >> >> The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if >> you really want to migrate to another scene graph then it should be >> Vulkan based if you want it to be future proofed. Qt3D might be >> ported to Vulkan, but it'll still be tied to Qt and all the baggage >> that goes with it. >> >> Modern computing should be based around well designed and >> functionality focused components that can be mixed and matched as to >> the
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi, I have just investigated the issue with OSG view set in QT window and osgEarth REX engine which resulted in completely black screen. This was probably different problem, but it sounds bit like yours so I decided I will share my observations. Maybe it will help someone. What I found to be an issue in our case was a missing call when setting our main view camera : main_camera->setDrawBuffer( GL_BACK ) This call makes sure the glDrawBuffer is set to main window BACK buffer before drawing main view frames. In my case REX engine was setting up RTT camera (without Color attachment) which swtiched DrawBuffer to GL_NONE. And main window was not restoring it before drawing the frame. So the effect was a completely black screen. I suspect similar problem may happen not only with osgEearth REX but with any RTT camera (without color attachments like shadowmap cameras). When I added above line while setting main camera problem vanished. I hope this may help somebody. With classic OSG Viewer this call is made inside SceneView ctor when setting up the camera. I believe our app also set up SceneView with QT window at startup but somehow DrawBuffer setting was later reverted/discarded. You may check if this hints helps you. Cheers, Wojtek Lewandowski sob., 28 lip 2018 o 11:51 Robert Osfield napisał(a): > ?!?! gmail just sent the email mid sentence > > > That exactly the same can be said for the OSG. Doesn't mean > > Mean't to say: > > On Sat, 28 Jul 2018 at 10:20, Robert Osfield > wrote: > > > Now, there are huge firms that adopted Qt for decades and run multi > billion dollars systems on it. > > The exactly the same can be said about the OSG. It's widely used for > decades on serious extensive kit. > > However, this doesn't mean that OSG isn't flawless and can't be improved > upon. > > With modern C++ with have opportunities to do a number of things far > more cleanly that previously possible. This applies to the scene > graphs just as much UI's. > > The future of C++ application development will be better served by > successors to the OSG and Qt. > > Right now such successors are just embryonic ideas, or nuggets of > prototypes. For current application development which need cross > platform widgets may be best served by Qt, same as the graphics > application development may be bested served by the OSG. Current > applications will be around for many years to come so Qt and OSG will > need to be maintained. > > For my own part I'm committed to maintaining the OSG. For 3.6.x I > moved osgQt out of the core to allow members of the OSG community who > have the need for Qt support and the expertise to know how to maintain > it the ability to make decisions, implementation solutions and provide > proper maintenance for it - something I can't do personally as I don't > have the Qt expertise, nor the time. > > This thread is a bit worrying as despite me handing the keys over to > osgQt development to the community doesn't yet seem to be able to > resolve all the problems by themselves. Yes the source code to both > Qt, osgQt and the OSG are all available, but unless developers step up > things don't happen. This suggest perhaps we need a bit more > motivated manpower from the Qt/OSG community to help push osgQt > forward. So if you feel passionate about Qt then please step forward > and help out. > > -- > > As a little prod for the long term future. With UI's and 2D rendering > API adopting scene graph internally (by this I don't mean Qt3D) and > more UI/2D rendering being done down on the GPU there is a possible > convergence. Could one have a scene graph that is general purpose > enough to be used directly to do 2D UI's as well as 3D real-time > graphics? Could one implement the UI as an add on to the core scene > graph, just a you'd made a game engine or image generator that builds > ontop of a scene graph?? > > So... I'm writing a new scene graph, yes I'm focused on it being used > for 3D, but I'm aware that Vulkan does compute just as nicely as it > does 3D, and it also works just fine for 2D too. If you can have a > scene graph just work as a compute graph, as well as 3D rendering > graph then 2D rendering is also just another subset. Could an > enterprising engineer build a fully function UI ontop of it? Maybe. > > Even if it doesn't come to pass for my VSG work, this is how I feel we > should all be thinking about the future - we should be thinking out of > the box, thinking about where we could get it if we strive for it, > rather than settling for the status quo. Yes yes the OSG and Qt are > impressive in a number of ways, but they have but of all encompassing > monsters that are at there peak. Better solutions will follow on, if > they don't the computer industry is failing to progress as it should. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org >
Re: [osg-users] osgQt + OSG 3.6.2 Status
?!?! gmail just sent the email mid sentence > That exactly the same can be said for the OSG. Doesn't mean Mean't to say: On Sat, 28 Jul 2018 at 10:20, Robert Osfield wrote: > > Now, there are huge firms that adopted Qt for decades and run multi billion > > dollars systems on it. The exactly the same can be said about the OSG. It's widely used for decades on serious extensive kit. However, this doesn't mean that OSG isn't flawless and can't be improved upon. With modern C++ with have opportunities to do a number of things far more cleanly that previously possible. This applies to the scene graphs just as much UI's. The future of C++ application development will be better served by successors to the OSG and Qt. Right now such successors are just embryonic ideas, or nuggets of prototypes. For current application development which need cross platform widgets may be best served by Qt, same as the graphics application development may be bested served by the OSG. Current applications will be around for many years to come so Qt and OSG will need to be maintained. For my own part I'm committed to maintaining the OSG. For 3.6.x I moved osgQt out of the core to allow members of the OSG community who have the need for Qt support and the expertise to know how to maintain it the ability to make decisions, implementation solutions and provide proper maintenance for it - something I can't do personally as I don't have the Qt expertise, nor the time. This thread is a bit worrying as despite me handing the keys over to osgQt development to the community doesn't yet seem to be able to resolve all the problems by themselves. Yes the source code to both Qt, osgQt and the OSG are all available, but unless developers step up things don't happen. This suggest perhaps we need a bit more motivated manpower from the Qt/OSG community to help push osgQt forward. So if you feel passionate about Qt then please step forward and help out. -- As a little prod for the long term future. With UI's and 2D rendering API adopting scene graph internally (by this I don't mean Qt3D) and more UI/2D rendering being done down on the GPU there is a possible convergence. Could one have a scene graph that is general purpose enough to be used directly to do 2D UI's as well as 3D real-time graphics? Could one implement the UI as an add on to the core scene graph, just a you'd made a game engine or image generator that builds ontop of a scene graph?? So... I'm writing a new scene graph, yes I'm focused on it being used for 3D, but I'm aware that Vulkan does compute just as nicely as it does 3D, and it also works just fine for 2D too. If you can have a scene graph just work as a compute graph, as well as 3D rendering graph then 2D rendering is also just another subset. Could an enterprising engineer build a fully function UI ontop of it? Maybe. Even if it doesn't come to pass for my VSG work, this is how I feel we should all be thinking about the future - we should be thinking out of the box, thinking about where we could get it if we strive for it, rather than settling for the status quo. Yes yes the OSG and Qt are impressive in a number of ways, but they have but of all encompassing monsters that are at there peak. Better solutions will follow on, if they don't the computer industry is failing to progress as it should. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
On Fri, 27 Jul 2018 at 18:19, Joshua Tree wrote: > > I have to chip in here. Qt is the most reliable, industry standard UI for > C++, period. In part this success is due to the moc autogeneration, which > could get you out of SFINAE madness. > > Now, there are huge firms that adopted Qt for decades and run multi billion > dollars systems on it. That exactly the same can be said for the OSG. Doesn't mean > That said, the Qt source is online and you can modify it as you wish to test > a solution. It is puzzling to me how this is still a pending and recurrent > issue for over a decade and a half I follow OSG. > > > I have used Qt and OSG back in 2003, 15 years ago with success. > > > On Jul 27, 2018, at 12:03 PM, Robert Osfield > > wrote: > > > > Hi Andrew, > > > >> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham wrote: > >> I would agree QT is not perfect but on the flip-side > >> - It is the 'last man standing' of x-platform UI's. > > > > This is down to the weakness of the alternatives rather as much as the > > strength of Qt. > > > >> - It's actively developed using the latest C++11/14 standards and > >> supported by both a commercial organization and a robust LGPL community > > > > Will they get rid of the non standard C++ extensions and pre-compiling > > nonsense? > > > >> - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' > >> way to build Python based desktop UI's. > >> - QML is quite interesting > > > > There is simply too much pushed into Qt over the years. The lack of > > focus on the core functionality hurts it. > > > > I say this from experience, we've pushed too much functionality into > > the OpenSceneGraph distribution over the years, I can see the > > mistakes, but with backwards compatibility being an important factor > > for end users it's not easy to just make radical changes. > > > > What the computer industry is a nice neat, small C++11 UI library with > > good hooks to building scripting integration on top of. > > > >> I don't know why QT and OSG seem to fight each other so much, but it seems > >> a PITA to get things working properly as the OP and I have both found > >> mysterious issues popping up that require trips into the debugger and the > >> QT and OSG source. I had to advocate for OSG as other developers were keen > >> to use QT3D instead. > > > > OSG integration with 3rd party windowing toolkits has generally been > > pretty straight forward - once the basics have been written it doesn't > > take much to update and keep things working. > > > > Our experience with Qt is not like this at all. X11, Win32 they've > > been pretty rock solid for way over a decade now. OSX has required > > jumping through a hoops because Apple doesn't care about developers as > > much as it cares about vendor lock-in. > > > > Over the years the OSG hasn't added extra burden on the 3rd party > > windowing toolkits, it's exactly the same as it has always been, just > > create a GL context and allow the OSG to call makeCurrent() and > > swapBuffers and we are pretty well done. It *should* be simple. It > > is requires is the 3rd party windowing toolkit not to screw around > > with things. It's Qt screwing around with things that is breaking > > things, they have lost sight of what the Windowing API should be doing > > and trading on the toes of application develop codes/3rd party SDK's > > like the OSG. > > > > Qt *is* broken in this respect. It really should be down to the Qt > > support to help you work out how to fix this. > > > > -- > > > > It terms of thinking about migrating away from OpenSceneGraph to Qt3D, > > this might solve the Qt integration issue, but it just further cements > > the lock-in to Qt, you'll end up tied to their future success or > > failures. > > > > The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if > > you really want to migrate to another scene graph then it should be > > Vulkan based if you want it to be future proofed. Qt3D might be > > ported to Vulkan, but it'll still be tied to Qt and all the baggage > > that goes with it. > > > > Modern computing should be based around well designed and > > functionality focused components that can be mixed and matched as to > > the needs of the applications. One stop shop SDK's and vendors that > > try to give you solutions for a wide range of functionality will give > > you lowest common denominator solutions rather than best of breed. > > > > This philosophy isn't Qt specific, but is something that I feel > > developers should bare in mind when considering what tools to use and > > deeply they should tie themselves to them. > > > > Robert. > > ___ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org >
Re: [osg-users] osgQt + OSG 3.6.2 Status
I have to chip in here. Qt is the most reliable, industry standard UI for C++, period. In part this success is due to the moc autogeneration, which could get you out of SFINAE madness. Now, there are huge firms that adopted Qt for decades and run multi billion dollars systems on it. That said, the Qt source is online and you can modify it as you wish to test a solution. It is puzzling to me how this is still a pending and recurrent issue for over a decade and a half I follow OSG. I have used Qt and OSG back in 2003, 15 years ago with success. > On Jul 27, 2018, at 12:03 PM, Robert Osfield wrote: > > Hi Andrew, > >> On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham wrote: >> I would agree QT is not perfect but on the flip-side >> - It is the 'last man standing' of x-platform UI's. > > This is down to the weakness of the alternatives rather as much as the > strength of Qt. > >> - It's actively developed using the latest C++11/14 standards and supported >> by both a commercial organization and a robust LGPL community > > Will they get rid of the non standard C++ extensions and pre-compiling > nonsense? > >> - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' >> way to build Python based desktop UI's. >> - QML is quite interesting > > There is simply too much pushed into Qt over the years. The lack of > focus on the core functionality hurts it. > > I say this from experience, we've pushed too much functionality into > the OpenSceneGraph distribution over the years, I can see the > mistakes, but with backwards compatibility being an important factor > for end users it's not easy to just make radical changes. > > What the computer industry is a nice neat, small C++11 UI library with > good hooks to building scripting integration on top of. > >> I don't know why QT and OSG seem to fight each other so much, but it seems a >> PITA to get things working properly as the OP and I have both found >> mysterious issues popping up that require trips into the debugger and the QT >> and OSG source. I had to advocate for OSG as other developers were keen to >> use QT3D instead. > > OSG integration with 3rd party windowing toolkits has generally been > pretty straight forward - once the basics have been written it doesn't > take much to update and keep things working. > > Our experience with Qt is not like this at all. X11, Win32 they've > been pretty rock solid for way over a decade now. OSX has required > jumping through a hoops because Apple doesn't care about developers as > much as it cares about vendor lock-in. > > Over the years the OSG hasn't added extra burden on the 3rd party > windowing toolkits, it's exactly the same as it has always been, just > create a GL context and allow the OSG to call makeCurrent() and > swapBuffers and we are pretty well done. It *should* be simple. It > is requires is the 3rd party windowing toolkit not to screw around > with things. It's Qt screwing around with things that is breaking > things, they have lost sight of what the Windowing API should be doing > and trading on the toes of application develop codes/3rd party SDK's > like the OSG. > > Qt *is* broken in this respect. It really should be down to the Qt > support to help you work out how to fix this. > > -- > > It terms of thinking about migrating away from OpenSceneGraph to Qt3D, > this might solve the Qt integration issue, but it just further cements > the lock-in to Qt, you'll end up tied to their future success or > failures. > > The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if > you really want to migrate to another scene graph then it should be > Vulkan based if you want it to be future proofed. Qt3D might be > ported to Vulkan, but it'll still be tied to Qt and all the baggage > that goes with it. > > Modern computing should be based around well designed and > functionality focused components that can be mixed and matched as to > the needs of the applications. One stop shop SDK's and vendors that > try to give you solutions for a wide range of functionality will give > you lowest common denominator solutions rather than best of breed. > > This philosophy isn't Qt specific, but is something that I feel > developers should bare in mind when considering what tools to use and > deeply they should tie themselves to them. > > Robert. > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Andrew, On Fri, 27 Jul 2018 at 17:14, Andrew Cunningham wrote: > I would agree QT is not perfect but on the flip-side > - It is the 'last man standing' of x-platform UI's. This is down to the weakness of the alternatives rather as much as the strength of Qt. > - It's actively developed using the latest C++11/14 standards and supported > by both a commercial organization and a robust LGPL community Will they get rid of the non standard C++ extensions and pre-compiling nonsense? > - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' > way to build Python based desktop UI's. > - QML is quite interesting There is simply too much pushed into Qt over the years. The lack of focus on the core functionality hurts it. I say this from experience, we've pushed too much functionality into the OpenSceneGraph distribution over the years, I can see the mistakes, but with backwards compatibility being an important factor for end users it's not easy to just make radical changes. What the computer industry is a nice neat, small C++11 UI library with good hooks to building scripting integration on top of. > I don't know why QT and OSG seem to fight each other so much, but it seems a > PITA to get things working properly as the OP and I have both found > mysterious issues popping up that require trips into the debugger and the QT > and OSG source. I had to advocate for OSG as other developers were keen to > use QT3D instead. OSG integration with 3rd party windowing toolkits has generally been pretty straight forward - once the basics have been written it doesn't take much to update and keep things working. Our experience with Qt is not like this at all. X11, Win32 they've been pretty rock solid for way over a decade now. OSX has required jumping through a hoops because Apple doesn't care about developers as much as it cares about vendor lock-in. Over the years the OSG hasn't added extra burden on the 3rd party windowing toolkits, it's exactly the same as it has always been, just create a GL context and allow the OSG to call makeCurrent() and swapBuffers and we are pretty well done. It *should* be simple. It is requires is the 3rd party windowing toolkit not to screw around with things. It's Qt screwing around with things that is breaking things, they have lost sight of what the Windowing API should be doing and trading on the toes of application develop codes/3rd party SDK's like the OSG. Qt *is* broken in this respect. It really should be down to the Qt support to help you work out how to fix this. -- It terms of thinking about migrating away from OpenSceneGraph to Qt3D, this might solve the Qt integration issue, but it just further cements the lock-in to Qt, you'll end up tied to their future success or failures. The future of scene graphs isn't OpenGL/OpenGL ES, it's Vulkan, so if you really want to migrate to another scene graph then it should be Vulkan based if you want it to be future proofed. Qt3D might be ported to Vulkan, but it'll still be tied to Qt and all the baggage that goes with it. Modern computing should be based around well designed and functionality focused components that can be mixed and matched as to the needs of the applications. One stop shop SDK's and vendors that try to give you solutions for a wide range of functionality will give you lowest common denominator solutions rather than best of breed. This philosophy isn't Qt specific, but is something that I feel developers should bare in mind when considering what tools to use and deeply they should tie themselves to them. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
robertosfield wrote: > > Personally I think Qt is broken in a number of ways. It's really time > that the computer industry had a C++11 based cross platform Windowing > API so we can all dump Qt, > I would agree QT is not perfect but on the flip-side - It is the 'last man standing' of x-platform UI's. - It's actively developed using the latest C++11/14 standards and supported by both a commercial organization and a robust LGPL community - Is has a new lease of life through PyQT5 and PySide being the 'de-facto' way to build Python based desktop UI's. - QML is quite interesting I don't know why QT and OSG seem to fight each other so much, but it seems a PITA to get things working properly as the OP and I have both found mysterious issues popping up that require trips into the debugger and the QT and OSG source. I had to advocate for OSG as other developers were keen to use QT3D instead. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74404#74404 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
On Thu, 26 Jul 2018 at 22:34, Stuart Mentzer wrote: > > Hi Andrew, > > I had no luck despite trying many variations. I had to put this work aside > for a while with the plan to circle back and check for osgQt updates now and > then. But if someone adds some ideas here I'll try them. > > > To be honest I'm experimenting with Qt3D (feels a little dirty ;-). I know I > won't get OSG performance out of it but the reduced Qt integration, Qt5, > multithreading, and packaging hassles might make this a viable alternative > soon. Qt3D has its own headaches, of course, and is still fairly immature. > Maybe I can join a support group for OSG users with a wandering eye. > I have no Qt expertise so can't help with the specifics, but the fact that you are consider Qt3D because Qt is breaking integration with 3rd party OpenGL tools is a major red flag. All the OSG needs is for a Windowing API is for the makeCurrent() to work then for it to no interfere with with OpenGL state in some uncontrolled way. My guess Qt could be doing something with OpenGL state. Personally I think Qt is broken in a number of ways. It's really time that the computer industry had a C++11 based cross platform Windowing API so we can all dump Qt, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Andrew, I had no luck despite trying many variations. I had to put this work aside for a while with the plan to circle back and check for osgQt updates now and then. But if someone adds some ideas here I'll try them. To be honest I'm experimenting with Qt3D (feels a little dirty ;-). I know I won't get OSG performance out of it but the reduced Qt integration, Qt5, multithreading, and packaging hassles might make this a viable alternative soon. Qt3D has its own headaches, of course, and is still fairly immature. Maybe I can join a support group for OSG users with a wandering eye. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74396#74396 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Stuart, If you resolve this please let us know. As a data point , I had a lot of trouble with OSG 3.4.1 and QT 5.7 and the "black" window problem. I only resolved it with some experimentation and I am still not sure why it worked. Andrew -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74395#74395 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Thanks for the outline. I will work through this and experiment with my code. If I learn anything interesting/useful I'll post it. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74360#74360 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
I'm no code guru (more like a hacker), but I'll post what I do if it makes sense and helps. Had to hand-type this as my code is on a different PC and I couldnt copy. You'll probably see some typos and short cuts. My setup is in a class called OSGDataViewer which double inherits a view base class (pretty much a QMainWindow) and a CompositeViewer. I define a osgQt::GraphisWindowQt* m_gw member along with all my manipulators, rootnode hud etc in this OSGDataViewer class. In my constructor, I call a method initializeOSG() which does the following: setThreadModel(osgViewer::Viewer::SingleThreaded); osg::ref_ptr cam0 = this->createCamera(x(), y(), height(), "Main Camera", false); //more on createCamera in a bit. x,y,width,height comes from qmainwindow QWidget* GLWidget = m_gw->getGLWidget(); //finally set my central widget this->setCentralWidget(GLWidget); I then setup a cam1 which is my hud camera. I'll post if you want to see it. Next I set up my root node, depthPartitionNode, and others. finally, I'll call another local method: addNewView(cam0.get(), rootnode.get(), "MainView") //i'd call this with cam1 also. This method is described below also finally, my difference scene manipulators are created and i'd do something like the following: this->getView(0)->setCameraManipulator(m_keyswitchManipulator.get()) I'd also setup callbacks as example: this->getView(1)->getCamera()->setFinalDrawCallbac(w_WinCapCallback.get()) here is my createCamera method: osg::Camera* OSGDataViewer::createCamera(int x, y, w, h, name...) osg::ref_ptr ds = osg::DisplaySettings::instance(); ds->setMaxNumberOfGraphicContext(20) osg::ref_ptr traits = new osg::GraphicsContext::Traits; traits->readDISPLAY if (traits->displayNum<0) traigs->displayNum=0; traits->windowName = name traits->. x=x y=y width=w alpha = ds->getMinimumNumberAlphaBits stencil = ds->getMinimumNumStencilBits() windowDecoration = false doubleBuffer = true; sampleBuffers = ds->getMultiSamples samples = ds->getNumMultiSamples traits->inheritedWindowData = new osgViewer::GraphicsWindowWin32::WindowData((HWND)QWidget::winID()); osgQt::GraphicsWindowQt *GWQ; if (!m_gw) traits->sharedContext = 0; GWQ = new osgQt::GraphicsWindowQt(traits.get()) GWQ->createNewContextID else traits->sharedContext = m_gw GWQ = new osgQt::GraphicsWindowQt(traits.get()) GWQ->createNewContextID(); GWQ->setName(name) osg::ref_ptr camera = new osg::Camera() camera->setGraphicsContext(GWQ); QWidget* GLWidget = GWQ->getGLWidget(); GLWidget->setAttribute(Qt::WA_PaintOnScreen) . WA_NoSystemBackground WA_OpaquePaintEvent WA_DeleteOnClose GLWidget->setAttribute(Qt::ClickFocus) camera->setClearColor(... camera->setViewPort(new osg::Viewport(0, 0, traits->width, traits->height)) camera ->setLODScale(3.0) camera->setProjectionMatrixAsPerspective(.. osg::StateSet* stateset = camera->getOrCreateStateSet() stateset->setGlobalDefaults() return camera.release() here is my addNewView method: void OSGDataViewer::addNewView(osg::Camera* camera, osg::Node* scene, string viewname) osgVIewer::View* view = new osgVIewer::View; view->setCamera(camera) view->adddEventHandler(new osgGA::StateSetManipulator(view->getCamera()->getOrCreateStateSet())) view->addEventHandler(new osgVIewer::ThreadingHandler) ::WindowSizeHandler) ::StatsHandler) view->setLightingMode(osg::View::SKY_LIGHT) view->getDatabasePaer()->setUnrefImageDataAfterApplyPolicy(true, valse) this->addView(view) view->setSceneData(scene); Hope this is as clear as mud! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74359#74359 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Robert, Yes, I'm aware of the examples and osgQtWidgets runs fine with my builds. But none of them match how we have used osgQt in the past with a single-view class derived from osgQt::GLWidget and osgViewer and a GraphicsWindowQt. And there are no examples for the new osgQOpenGL approach. My viewer code works fine in OSG 3.4.1 on Windows and Linux but doesn't work with 3.6.2 and the current osgQt master, and I'm not sure where the problem lies. Cheers, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74358#74358 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Hi Stuart, On Tue, 17 Jul 2018 at 23:14, Stuart Mentzer wrote: > Thanks for the info @davisjamesf. I wish I knew what secret sauce was needed > to get this running. I'll keep trying and maybe I'll have luck with some > future osgQt release. > > If you or anyone have some example code for a single view class derived from > osgQt::GLWidget and osgViewer (or a better design) that can display a scene > using current osgQt + OSG 3.6.2 that should get me started. There are examples in osgQt: $ ls osgQt/examples/ osgqfont osgQtBrowser osgQtWidgets osgviewerQt I have just test osgQt master against OpenSceneGraph-3.6 branch (same as 3.6.2) and it works OK for me. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
Thanks for the info @davisjamesf. I wish I knew what secret sauce was needed to get this running. I'll keep trying and maybe I'll have luck with some future osgQt release. If you or anyone have some example code for a single view class derived from osgQt::GLWidget and osgViewer (or a better design) that can display a scene using current osgQt + OSG 3.6.2 that should get me started. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74354#74354 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt + OSG 3.6.2 Status
This is probably nothing more than a data point of things working, but I had no issue compiling/running OSG 3.6.2 and osgQt (qt 5.10 on windows 10 using VS 2017) and Linux (Cent OS7 / gcc 4.8.5). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74350#74350 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgQt + OSG 3.6.2 Status
Hi, I'm looking for info on the status of osgQt for OSG 3.6.2. I tried using the osgQt git master code with my OSG 3.6.2 + Qt 5.11.1 Windows build but I get a black OSG widget with our application, which works fine with OSG 3.4.1. I tried a number of variations with no luck. I also tried the new osgQOpenGL code but without examples I couldn't get it working correctly. If either of these osgQt approaches are working with OSG 3.6.2 for anyone else it would be helpful to get any usage tips. Once we have a compatible osgQt we plan to post the OSG 3.6.2 + osgQt Windows binaries to our company site like we do for 3.4.0 and 3.4.1. Thanks, Stuart -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74345#74345 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
