Drawing standard widgets using a custom paint engine

[Waywocket]

If I understand correctly, you just want to embed an external window (of OGRE origin) into your application. In that case what is the point of using it as a viewport of a graphics view?

Because I want to render a graphics scene as an overlay in OGRE (specifically to a dynamic texture drawn as an overlay material), effectively providing an OGRE GUI using Qt (even better if it becomes possible to draw widgets in a graphics view), hopefully allowing Qt to deal with the input handling. The reason for this is that none of the GUI (or input handling) libraries for OGRE are anywhere near the standard of Qt.

I would just draw other widgets straight on top of the OGRE widget, which works, only that wouldn't allow for alpha compositing which is something I need.

[wysota]

Because I want to render a graphics scene as an overlay in OGRE

I don't think it will work. The OGRE widget is not a real Qt widget, so Qt can't paint over it. It doesn't have access to its contents or anything...

I would just draw other widgets straight on top of the OGRE widget, which works, only that wouldn't allow for alpha compositing which is something I need.

Again, is it possible to force OGRE to draw into some memory buffer or image? Or maybe you can pass OpenGL context from a QGLWidget to OGRE and ask it to paint using it?

[Waywocket]

I don't think it will work. The OGRE widget is not a real Qt widget, so Qt can't paint over it. It doesn't have access to its contents or anything...

I was under the impression that the customised paint engine would cover this. Possibly I'd need to make my own painter as well though - I can't find anything in the documentation which says what components need to be able to read from the widget, and the description for implementing a new paint device says only that you need to implement an appropriate paint engine - in fact, I can't find any mention of any component needing to be able to read the contents of a widget, except for potentially its paint engine.

Bear in mind again that the existing OGRE window, onto which I can successfully draw using my dedicated paint engine, becomes somehow hidden as soon as it is used as the graphics view viewport, and this is all I'm really concerned about at the moment, even if it ultimately transpires that I can't draw usefully on to it.

Again, is it possible to force OGRE to draw into some memory buffer or image?

Probably, but the performance problems incurred would make this infeasible, since you'd need to read data back from the frame buffer, which is intolerably slow on systems with dedicated graphics memory (ie. most of them). (Either that or do all the rendering in software, which would be even worse.)

For this reason, I don't believe that the QGLWidget does this, so I don't believe it should be necessary. I wonder if QGraphicsView contains code to deal specifically with QGLWidgets (don't think so though).

Or maybe you can pass OpenGL context from a QGLWidget to OGRE and ask it to paint using it?

This idea hadn't occurred to me, and there's some chance it might be possible, thanks.

[wysota]

I was under the impression that the customised paint engine would cover this. Possibly I'd need to make my own painter as well though

Not a painter - a paint device and it can't inherit QWidget - that's the main problem.

I can't find anything in the documentation which says what components need to be able to read from the widget, and the description for implementing a new paint device says only that you need to implement an appropriate paint engine - in fact, I can't find any mention of any component needing to be able to read the contents of a widget, except for potentially its paint engine.

Yes, but you won't be painting on the widget, so you won't be able to mix any QWidget and OGRE code other than that which uses QPainter.

Bear in mind again that the existing OGRE window, onto which I can successfully draw using my dedicated paint engine, becomes somehow hidden as soon as it is used as the graphics view viewport, and this is all I'm really concerned about at the moment, even if it ultimately transpires that I can't draw usefully on to it.

Your graphicsview would probably become awfully slow. I think it would be better if you made a real overlay - apply a graphicsview with a regular viewport over the OGRE widget. You'll just have to make the graphicsview and its viewport transparent.

Probably, but the performance problems incurred would make this infeasible, since you'd need to read data back from the frame buffer, which is intolerably slow on systems with dedicated graphics memory (ie. most of them). (Either that or do all the rendering in software, which would be even worse.)

With modern cards it should be possible to use pixel buffers or some simmilar technique (I'm not an expert on that so I can't tell you more).

For this reason, I don't believe that the QGLWidget does this, so I don't believe it should be necessary. I wonder if QGraphicsView contains code to deal specifically with QGLWidgets (don't think so though).

The difference is that you want to paint behind Qt's back and with QGLWidget that's not the case. The only possibility I see is to share the GL context between the widget and the OGRE engine.

[Waywocket]

I think we may be having a misunderstanding here, so for the moment I'm going to give up and try learning all there is to learn about creating new widgets and see if that helps me understand what's happening.
(Just discovered also that there's no non-hacky way of even getting at the OpenGL context of a QGLWidget, which is a little disappointing. I guess they figured since it wouldn't work identically on all platforms then it shouldn't be allowed at all)
Thank you for your time, either way .

[pdolbey]

Something like

#IFDEF Q_OS_WIN
HGLRC rc = wglGetCurrentContext();
#ELSE
GLXContext rc = glXGetCurrentContext();
#ENDIF

#IFDEF Q_OS_WIN
HGLRC rc = wglGetCurrentContext();
#ELSE
GLXContext rc = glXGetCurrentContext();
#ENDIF

To copy to clipboard, switch view to plain text mode 

in the intializeGL() or paintGL() methods of a QGLWidget will probably get the necessary rendering contexts. I've proved the Windows leg first with an OpenCascade OpenGL viewer - the alternate piece is the logical extension for X11.

Pete

[Waywocket]

Thanks for that tip; I'll look into it at some point.

[Waywocket]

That did indeed work, and I've managed to make a subclass of QGLWidget which embeds Ogre as its background, allowing me to use Qt paint calls on top of an Ogre context, with alpha compositing, and to use this as a QGraphcsView viewport - using the bare minimum of Xlib and GLX calls to glue it all together .
I might post a bit more on this once it's tidied up, but on the other hand I kind of doubt anybody will care...

[high_flyer]

oh, we care!

[pdolbey]

I care too, especially as you've just tested a line of code that I couldn't.

Pete

[Waywocket]

Well I've got a simple Ogre widget, and a corresponding GraphicsView widget, along with a couple of subclasses for those implementing some more demonstrative functionality, and finally a simple demo app, mixing Qt and CEGUI (not sure why you'd want to in reality, but anyway...)

If you're not interesting in building the Ogre demo, the most important bit of code to look at is probably in QOgreGLWidget::initializeGL().

The idea is to get Ogre to use an existing window (which requires that you know its XVisualInfo), and to switch between QGLWidget and Ogre GLXContexts at the appropriate times so neither find themselves in an unexpected state.

The final point is to ensure that both Ogre and Qt don't try to swap buffers; I let Qt do it so that the QGLWidget can get a chance to draw over the window after Ogre's done with that frame.

Apologies for the roughness; I got bored of tidying it all up :P.

Also, I think there was something else I was planning to add to this post, but it's two in the morning so I'll see if I remember tomorrow...
Edit: I think it might have been that there's a bug in Ogre which this triggers. Nothing desperate - you get X Errors when the widget is destroyed; I've provided a patch.

(Just noticed that CEGUI widgets, including the mouse cursor, are resized along with the window. Text correctly manages to remain the same size though and I'm performing the resize notifications to CEGUI in the same place, so I don't see what's wrong. Guess I must have missed something.)

[desert]

I've been doing some research and this is the closest i've found on Qt+OGRE shared OpenGL rendering.

But have you found a way to share the context instead of switching? Context switching might be costly. Have you read about

params["externalGLContext"] = Ogre::StringConverter::toString( ((unsigned long)(glXGetCurrentContext()) ) );
mRenderWindow = mOgreRoot->createRenderWindow("View", width(), height(), false, &params);

params["externalGLContext"] = Ogre::StringConverter::toString( ((unsigned long)(glXGetCurrentContext()) ) );
mRenderWindow = mOgreRoot->createRenderWindow("View", width(), height(), false, &params);

To copy to clipboard, switch view to plain text mode 

Im doing this but seems OGRE insists on creating a new context.