On Mon, Oct 19, 2009 at 2:01 PM, Samuel Rødal <[email protected]> wrote: > Ryan McDougall wrote: >> >> ---------- Forwarded message ---------- >> From: Ryan McDougall <[email protected]> >> Date: Mon, Oct 19, 2009 at 1:24 PM >> Subject: Qt with Ogre3D >> To: [email protected] >> >> >> Hello, >> >> No'am from Nokia suggested I try out this list, so if I'm off topic, >> let me know! >> >> I am trying to integrate Qt with Ogre3D in order to supply the game >> UI. I am following the example set here: >> >> http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ >> >> However instead of QGLWidget, I am using an OgreWidget: >> http://github.com/sempuki/code/tree/master/qt-ogre-test-2/ >> >> However, as anticipated, I get flicker. Any advice how to reduce this? >> >> Will 4.6 improve interactions between Qt and 3D programs? >> >> I've built and tested on linux, but I've included windows binaries to >> make it easier for windows developers if you want to try building it >> yourself. > > First of all, OgreWidget should probably inherit QGLWidget, otherwise I > don't see how Ogre / Qt are going to be able to render to the same OpenGL > context. I don't know Ogre so I'm not sure how to get it to render to an > existing OpenGL context, but I guess there should be a way? > > It's important that Ogre's rendering is only triggered from > QGraphicsView::drawBackground(), so that Qt can draw the graphics scene on > top of what Ogre draws. Also, Ogre should not call glSwapbuffers as this > will be done by Qt when the painting is done. > > Qt 4.6 adds QPainter::beginNativePainting() and > QPainter::endNativePainting() which you should use to surround non-QPainter > rendering code, so in 4.6 drawBackground should look something like this: > > void MyGraphicsView::drawBackground(QPainter *painter, const QRectF &) > { > painter->beginNativePainting(); > static_cast<OgreWidget *>(viewport())->draw_to_render_window(); > painter->endNativePainting(); > } > > If this doesn't work, another approach might be to get Ogre to draw into a > framebuffer object in a shared context, and then blit the texture in > drawBackground() (on a graphics view with a QGLWidget viewport). > > -- > Samuel >
Thank you for such a detailed answer! However, one of the selling points of using a rendering engine instead of raw OpenGL is that your game is written entirely in high-level terms, and as such never depends on the underlying libraries such as OpenGL and D3D. So on windows, Ogre would be using the D3D layer to draw, and one Linux it'd be OGL. One reason for this, besides "nice" encapsulation, is that D3D driver implementations tend to be quite a bit better for D3D than OGL. One other issue is that the internals of Ogre3D never expose the internal OGL context, because it is not meant to be shared, and may react badly if Qt ever changes the context. Currently the way Ogre3D integrates with Qt is to steal the OS-level window handle (win32/X11 respectively) and draw itself directly there. Since Qt isn't doing any 3D rendering, this shouldn't be a problem correct? Is there any method which doesn't rely on OGL? Cheers, _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
