Integrating Ogre and Qt via QGraphicsScene: widgets hidden

[Ralith]

I'm attempting to use Ogre in a Qt application and with Qt widgets embedded in its context. To do this, I'm deriving a class from QGraphicsScene and overriding the drawBackground function to call renderOneFrame on my Ogre root. Ogre is associated with the QGLWidget backing the relevant QGraphicsView by manually creating a render window with currentGLContext set to true once Qt has established the context. Somehow, Ogre either draws on top of or prevents the drawing of the Qt widgets normally drawn after drawBackground is called; if I call renderOneFrame, the widgets simply do not appear, while if I call, say, glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT) instead, the background gets cleared to the appropriate glClearColor and the Qt widgets draw normally. Interestingly, if I call renderOneFrame and then call glClear as described above, the clear happens but the Qt widgets do not appear to be drawn afterwards.

I have tried decomposing the renderOneFrame call into a variety of lower level forms, the most minimal of which being calling update(false) on my RenderWindow, but all have had the same effect; the Ogre rendering takes over and none of the Qt widgets meant to be drawn into the context are visible. How can I cause Ogre to allow the Qt widgets to be drawn into the context?

[trnrez]

This link might help with getting Ogre and Qt to work together. I'm pretty sure they don't do it the way you are going about it but maybe it will help you get started in the right direction.

http://www.ogre3d.org/forums/viewtopic.php?f=11&t=45709

[jacmoe]

QTOgreFramework doesn't work on Linux, though. (Not on my Linux, anyway).
Why are you using a QGraphicsScene and not a QGLWidget directly?
Works a treat, and with D3D as well.

-> http://www.ogre3d.org/wiki/index.php/QtOgre

[starseeker]

The idea is to follow this approach for ordinary Qt widgets inside an OpenGL QGLWidget: http://doc.trolltech.com/qq/qq26-openglcanvas.html, and have Ogre also use that same OpenGL context. Per PolyVox in that thread, the Qt widgets are simply being drawn on top of the Ogre window - that's almost certainly not enough for what we'll be wanting to do.

Somehow, it seems multiple calls to Ogre's renderOneFrame are stomping all over the OpenGL context and wiping out the display of the Qt widgets, or rather something it is calling is doing this. (Since the plain update call does the same thing.) The idea would be to draw the Ogre frame the same way glClear is clearing the background - leave the widgets alone and update the rest - but how to achieve this isn't immediately clear. Some idea of what the frame update is doing/assuming would be helpful - perhaps some sort of Qt redraw trigger needs to be added after a call to renderOneFrame? Or is it related to what's being done in this discussion?

[jacmoe]

How about the other way around?
Letting QT render in the Ogre RenderWindow instead?
It's possible to issue raw OpenGL, if needed.

[starseeker]

Hmm. Are you suggesting creating an Ogre Qt backend, distinct from the OpenGL and raster backends? Or start up Qt, have Qt start ogre and use the OpenGL context created by Ogre as it's OpenGL rendering context?

[jacmoe]

If we're talking about letting QT Widgets being rendering in Ogre, that would be a natural approach.
If not, I lost you.

[Ralith]

Hmm. Are you suggesting creating an Ogre Qt backend, distinct from the OpenGL and raster backends? Or start up Qt, have Qt start ogre and use the OpenGL context created by Ogre as it's OpenGL rendering context?

The problem with this approach is that it breaks away from the framework Qt has for doing this sort of thing. As far as I can tell, there's no straightforward way to get Qt to handle externally created contexts, let alone entire root windows. It would be much cleaner to use the GraphicsScene system, which uses the existing Qt code for rendering into OpenGL, as I'm currently attempting to, if there is only some way to prevent Ogre from itself preventing the Qt widget rendering. There must be something that Ogre's doing, some call that it's making, which is causing it to either be drawn on top of or entirely preventing the drawing of the Qt widgets, and so there must in kind me some way to undo whatever it is that Ogre is doing.

In particular, it's worth noting that a single call to renderOneFrame in the first frame of the context's rendering does not make the widgets invisible for all future renders; whatever it is that Ogre does is somehow undone between frames, probably by the Qt rendering system; just not in time to allow widgets to render normally for that first frame. Clearly, Ogre doesn't permanently modify the context's state; whatever it's doing can be undone, and if I can find out what it is and how to explicitly undo it immediately after calling renderOneFrame, I expect the Qt widgets would then render normally.

So that leaves the question: What is it that Ogre's doing to interfere with Qt's rendering, and how can it be undone?

[Karan]

There may be another way to render Qt widgets in Ogre: Use QPixmap::grabWidget() to render the widget into a QPixmap. Then convert the QPixmap to a QImage (that's cheap when the raster graphicssystem is used, because then QPixmap then uses QImage by default).
The QImage can then be converted to an Ogre Texture and rendered on a screen-aligned quad. Doesn't sound very fast because of the conversion every frame, but it would also work with Direct3D.

A way to speed things up may be to do the Qt rendering and conversion in a separate thread and only update the GUI every other frame if that takes too long.

[Ralith]

That seems like an incredibly inelegant, and possibly badly performing, workaround when Qt already provides the complete machinery to render to OpenGL, with only this one conflict with Ogre, probably resulting from some assumption Ogre makes that nothing else will be using the context. If this conflict can be resolved, the whole system would work together very cleanly through the mechanisms that Qt already implements. Such a resolution obviously isn't impossible.

[jacmoe]

What's the problem with the code Assaf posted in the topic you linked to?
If that doesn't work, I don't think QT is capable of cooperating with Ogre.

[Karan]

Sure it's inelegant for OpenGL, but I want something that also works with Direct3D and where you can place widgets in the 3D scene (e.g. on walls). And you're not the first one who has problems with rendering Qt and Ogre into the same context...

[Ralith]

Assaf's code looks like it might be worth a try if all else fails, but again the issue is that it forces me to abandon a lot of the convenient mechanisms Qt provides to do this sort of thing automatically. Admittedly, I'm not entirely sure how much more work it is to do manually what the QGraphicsScene does automatically, but it's certainly not ideal, and doesn't seem like it should be necessary. I suppose it might be the only option, though, if I can't work out how Ogre's interfering with things.

Bear in mind, though, that raw OpenGL calls do seem to work after the Ogre render call without any special handling, at least so far as glClear; the widgets just don't show up afterwards. I'm a bit concerned that I might implement Assaf's approach only to encounter exactly the same issue, though.

[outburstx]

Ralith,

I am having the exact same issue as you.
Did you ever end up solving this problem?