įrom what I have seen on the forums, a lot of people is struggling to get Ogre working in a QGraphicsView. So, in closing, this particular project, albeit immensely interesting and cool, is done for me. Unless, somehow, it would inherit from QGraphicsView. But this means that this "OgreGraphicsView" wouldn't know when to redraw a QWidget's (or QGraphicsItem's) texture. This is of course horrible design by the Qt people, but understandable, since it's internal. However, the problem here is that QWidget explicitly knows about QGraphicsViews it might be displayed in so that QWidget can let the QGraphicsViews when it changed. through mouse drags) and translate that into simple x/y translations in Ogre. I hoped it would be possible to catch events that tell the widget to move (i.e. I had an idea to implement something that works much like the QGraphicsView and renders QWidgets (or maybe even QGraphicsItems in general) into QPixmaps (which can easily be converted to QImages, which in turn are easy to use as Ogre::Textures). Better use established ways to embed Ogre RenderWindows in Qt widgets. Such intrusive changes just to get some small results in Qt aren't worth it, in my opinion.
OPENGL 4.4 GEDBUGGER NOT SHOWING UPDATE
Pushing/popping the complete opengl state before and after doing either update (on RenderWindow or the QGLWidget) helps a little, but of course causes drawing problems on either the Ogre or Qt side.Īlso, there is currently no way to replace the GLRenderSystem (or whatever it's called, I forget) in a plugin. They both mess up each others opengl state. Turns out, the OpenGL paint engine of Qt expects to own the opengl context. So, I ran into many problems, that's why I abandoned this project shortly after the last message. I'm thinking of letting GLRenderSystem deal with this explicitly such that the GLSupport is instantiated and destroyed at the appropriate time. The lifecycle of GLSupport inside GLRenderSystem is quite complicated, well, at least not very suited for outside management. There is only one problem with unloading the plugins which crashes the program. I'm actually very close to be able to show some pictures with my approach. You just have to make sure access is serialized, but that should be no problem as long as you only call update() from the main Qt thread.
![opengl 4.4 gedbugger not showing opengl 4.4 gedbugger not showing](https://i.stack.imgur.com/utMHM.png)
This is also its biggest advantage: No need to switch GL contexts between Qt and Ogre as they use the same one. No need to wrap it again to make it Qt compatible.
![opengl 4.4 gedbugger not showing opengl 4.4 gedbugger not showing](https://image.slidesharecdn.com/opengldebuggingwgk-141103105631-conversion-gate01/95/opengl-es-debugging-14-638.jpg)
This way, the RenderWindow instance you get back from either Root::initialise() or Root::createRenderWindow() is already a QGLWidget, so you cast it and use it like any other widget. Actually, it's 3c: Use Qt's OpenGL API (QGLWidget, etc) directly to create the GL context used by Ogre later.