Rendering QT widgets in Ogre
-
- Gnome
- Posts: 351
- Joined: Thu Oct 21, 2004 1:34 pm
- Location: Diepenbeek, Belgium
- x 3
- Contact:
Rendering QT widgets in Ogre
Hi,
I am not sure if this is the correct forum to post this in, so feel free to move it.
Did anyone try to implement an Ogre renderer for QT 4.4 already? And by that, I don't mean embedding Ogre inside a QT widget, but the other way around!
If I am reading the change list for QT 4.4 correctly, a new feature should make this possible fairly easy. So we could have another nice cross-platform solution for in-game widgets.
Greetz,
JeDi
I am not sure if this is the correct forum to post this in, so feel free to move it.
Did anyone try to implement an Ogre renderer for QT 4.4 already? And by that, I don't mean embedding Ogre inside a QT widget, but the other way around!
If I am reading the change list for QT 4.4 correctly, a new feature should make this possible fairly easy. So we could have another nice cross-platform solution for in-game widgets.
Greetz,
JeDi
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
I've been thinking about this for the last week or so, since I saw this demo on TrollTech labs:
http://labs.trolltech.com/blogs/2008/06 ... th-opengl/
Combine this with Qt's ability to customise widgets using StyleSheets and you could have a really cool in game GUI. Plus you get a decent layout editor for it.
It's certainly something I intend to investigate as I bring my project out of the prototype stage, but I think it's still several moths away. If anyone plays with it I'll be very interested in the result!
http://labs.trolltech.com/blogs/2008/06 ... th-opengl/
Combine this with Qt's ability to customise widgets using StyleSheets and you could have a really cool in game GUI. Plus you get a decent layout editor for it.
It's certainly something I intend to investigate as I bring my project out of the prototype stage, but I think it's still several moths away. If anyone plays with it I'll be very interested in the result!
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Aah! Moths!!PolyVox wrote:...it's still several moths away...
In answer to the original question though, it should be quite possible to use a QGLWidget and paint over it with whatever canvas you want (a QGraphicsView with WoC (Widget on Canvas) for example would let you place almost an entire Qt application within the window).
However, this would technically still be OGRE running within a Qt widget but you wouldn't really notice that aspect of it.
I can't give you any code right now but there's a number of posts on the forum explaining how to do the first half (putting OGRE into Qt). The second half shouldn't be too much more difficult given the niceness of Qt.
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Hmm... well that disproves my hypothesis that it's possible to type accurately with your elbows.milliams wrote:Aah! Moths!!PolyVox wrote:...it's still several moths away...
Right, I'm sure that at the moment it's possible to overlay Qt widgets on an OpenGL background. But one of the nice things about the Qt 4.4 approach is that you should be able to use any OpenGL surface to draw your GUI on. For example, this would mean you can draw to a texture and then use that texture on computer screens in game (like is done for the interactive computers in Doom 3). There are probably speed benefits too.milliams wrote:In answer to the original question though, it should be quite possible to use a QGLWidget and paint over it with whatever canvas you want (a QGraphicsView with WoC (Widget on Canvas) for example would let you place almost an entire Qt application within the window).
However, this would technically still be OGRE running within a Qt widget but you wouldn't really notice that aspect of it.
I really like the idea of combining Qt and Ogre, and I think a framework which combined them properly would be great. As well as rendering into eachother, I can envisage:
- Using Qt for input handling (no dependany on OIS).
- Using Qt for the initial configuration dialog.
- Using Qt to create a log file viewer which is updated in real time.
- Using Qt to implement texture loading (no dependancy on Devil).
- pjcast
- OGRE Retired Team Member
- Posts: 2543
- Joined: Fri Oct 24, 2003 2:53 am
- Location: San Diego, Ca
- x 2
- Contact:
I noticed you specifically called out OIS , so I thought I ask why you would not want to use OIS? Or just you want one less dependency? Also, OIS does more than just Mouse/Keyboard, does Qt offer more for input?PolyVox wrote:
- Using Qt for input handling (no dependany on OIS).
Have a question about Input? Video? WGE? Come on over... http://www.wreckedgames.com/forum/
- nullsquared
- Old One
- Posts: 3245
- Joined: Tue Apr 24, 2007 8:23 pm
- Location: NY, NY, USA
- x 11
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Nope, no offense meant! And I singled out Devil too Actually, with a full game Qt can remove many dependancies including network, XML parsing, sound (limited), containers, signal slots for messaging. Of course, the implementation is not specifically designed for games so depending on your application you might want lower level networking for example. Or if you want joystick support you probably still want OIS.pjcast wrote:I noticed you specifically called out OIS , so I thought I ask why you would not want to use OIS? Or just you want one less dependency? Also, OIS does more than just Mouse/Keyboard, does Qt offer more for input?
In my particular application, I could get rid of a lot of dependencies (hence it's desirable). However, when talking about a smaller Ogre example framework it only gets rid of a couple of dependencies which is why I mentioned OIS.
And no, it's probably not as good as OIS for input. And there are a lot of great open source game libraries out there. But Qt is just a nice as an all-in-one solution.
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
Well, as of Qt 4.4, Trolltech (now Nokia technically I guess) incorporated KDE's Phonon library directly into Qt. This gives an easy to use completely cross-platform sound API. I think that point is one of the main plus-points for using Qt, the ability to develop using it on one OS and be able to compile it on any other without having to change one line of code.PolyVox wrote:...sound (limited)...
Even if you don't want to use it for the GUI aspects you can simply use just the QtCore part as a very full featured utility library. I think that's the thing many people don't realise about Qt - that it's really much more than a GUI library, it's a full-blown toolkit. It's even got a built-in scripting language (ECMAScript based) which is useful for many games. See the module list to get an idea of the scope.
Sorry if I sound like I'm doing marketing for Qt but having used it extensively within KDE it's truly made application development a breeze.
-
- Halfling
- Posts: 54
- Joined: Wed Jun 25, 2008 6:38 pm
I for one am fully in favour of this. Qt4 is a very competent package, and removing dependencies, gaining a fabulous GUI system (or more native support for wxWidgets for those that that since it uses Qt4), native KDE-integration for those that wish, and making Linux/*BSD-development more "native" are extremely good arguments.PolyVox wrote:with a full game Qt can remove many dependancies including network, XML parsing, sound (limited), containers, signal slots for messaging. Of course, the implementation is not specifically designed for games so depending on your application you might want lower level networking for example. Or if you want joystick support you probably still want OIS. ... it's probably not as good as OIS for input. And there are a lot of great open source game libraries out there. But Qt is just a nice as an all-in-one solution.
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Before I cause too much controversy, I should point out that I'm not suggesting changing anything in Ogre, or replacing the current Ogre example framework. Of course I know that not everyone wants to drag a full toolkit along with their application, and those who do may have reasons for choosing another one (wxWidgets, etc).
This would simply be an addon project which aimed to combine the best bits of Qt and Ogre to produce an alternative framework. A search on the forums shows several people are already using Qt with Ogre, so any further work to integrate them would probably be useful
And I didn't know about Phonon - do you know how advanced it is? For example, does it handle 3D sounds? So you can give a sound a location and it will attenuate it based on distance to the player, for example?
This would simply be an addon project which aimed to combine the best bits of Qt and Ogre to produce an alternative framework. A search on the forums shows several people are already using Qt with Ogre, so any further work to integrate them would probably be useful
And I didn't know about Phonon - do you know how advanced it is? For example, does it handle 3D sounds? So you can give a sound a location and it will attenuate it based on distance to the player, for example?
- milliams
- Gremlin
- Posts: 172
- Joined: Fri Feb 16, 2007 1:47 am
- Location: Portsmouth, UK
- Contact:
I'd like to draw everyone's attention to something my fellow KDEer Rivo Laks has been working on. Take a look at his latest blog entry, How to easily mix QWidgets and OpenGL. Now, this solution is a little KDE-centric as far as I'm aware but it should be very easy indeed to filter out what is and to make it pure Qt and more general.
Go ahead and try it out and if you have any questions, head over to [url]irc://irc.kde.org/kdegames[/url] where Rivo can be found.
Go ahead and try it out and if you have any questions, head over to [url]irc://irc.kde.org/kdegames[/url] where Rivo can be found.
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
-
- Gnoblar
- Posts: 16
- Joined: Sun Aug 17, 2008 8:29 pm
This is very cool stuff, and I am desperate for a solution as well.
First I thought, I could use Qt/Embedded (used for PDAs and such) and implement a custom QScreen driver to render to a texture and overlay that on top of the whole screen. Unused space would be transparent, so you could still see what's going on. Unfortunately, it seems Qt/Embedded is only available for Linux and I'd really like it all to work on my Mac. A version that works on Windows would also be nice, I guess .
So, after reading that same blog post on TT's labs, I thought this would be great. After googling a bit, I found this on qtcentre.org:
http://www.qtcentre.org/forum/f-qt-prog ... 40679.html
Apparently, this does paint an OGRE window in the background of a QGraphicsView, but only in X11. I've tried to integrate code from
http://www.ogre3d.org/phpBB2/viewtopic.php?p=258064
but that somehow doesn't work. Switching between AGL contexts seems to be more difficult than between GLX contexts. I've got the above code working on top of a normal QWidget, but not for a QGLWidget, which is kind of required for this usecase of QGraphicsView.
I can upload my changes to the qtcentre code if anyone is interested. Any help on doing the OpenGL context switching between OGRE and the QGLWidget properly such that they render on the same window, one after the other, would be much appreciated.
Also, is there any way to give OGRE a parent OpenGL context at renderwindow creation? It doesn't seem so given the current code of the GL Render System. There is no way to set the main context which is queried by the platform specific render window implementations. Maybe that would be a nice feature.
Cheers,
max
First I thought, I could use Qt/Embedded (used for PDAs and such) and implement a custom QScreen driver to render to a texture and overlay that on top of the whole screen. Unused space would be transparent, so you could still see what's going on. Unfortunately, it seems Qt/Embedded is only available for Linux and I'd really like it all to work on my Mac. A version that works on Windows would also be nice, I guess .
So, after reading that same blog post on TT's labs, I thought this would be great. After googling a bit, I found this on qtcentre.org:
http://www.qtcentre.org/forum/f-qt-prog ... 40679.html
Apparently, this does paint an OGRE window in the background of a QGraphicsView, but only in X11. I've tried to integrate code from
http://www.ogre3d.org/phpBB2/viewtopic.php?p=258064
but that somehow doesn't work. Switching between AGL contexts seems to be more difficult than between GLX contexts. I've got the above code working on top of a normal QWidget, but not for a QGLWidget, which is kind of required for this usecase of QGraphicsView.
I can upload my changes to the qtcentre code if anyone is interested. Any help on doing the OpenGL context switching between OGRE and the QGLWidget properly such that they render on the same window, one after the other, would be much appreciated.
Also, is there any way to give OGRE a parent OpenGL context at renderwindow creation? It doesn't seem so given the current code of the GL Render System. There is no way to set the main context which is queried by the platform specific render window implementations. Maybe that would be a nice feature.
Cheers,
max
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Well, I am now working on this. I only started this weekend so I haven't got very far - I'm mostly just looking at examples and trying to work out my options (and I'm no Qt expert at the moment). I do, however, have a basic OgreWidget working so I'll give you the source in case it is useful:
http://www.david-williams.info/linked_f ... -0.0.1.zip
However, it doesn't do any of the embedding qt in Ogre stuff which we really want to get to, but it does work in both Linux and Windows.
Regarding that QtCenter post, well I only skim read it but I thought it was redundant since the TT blog post? Or is there some reason you still need it?
http://www.ogre3d.org/docs/api/html/cla ... 1_1Roota34
It seems there are flags "externalGLControl" and "externalGLContext" which might do what you want, but they are flagged as Win32 only.
I hope I can be more use in a couple of weeks once I have had a chance to get my head round Qt. I've never looked at it in this level of detail...
http://www.david-williams.info/linked_f ... -0.0.1.zip
However, it doesn't do any of the embedding qt in Ogre stuff which we really want to get to, but it does work in both Linux and Windows.
Regarding that QtCenter post, well I only skim read it but I thought it was redundant since the TT blog post? Or is there some reason you still need it?
From the docs here:pmax wrote:Also, is there any way to give OGRE a parent OpenGL context at renderwindow creation? It doesn't seem so given the current code of the GL Render System. There is no way to set the main context which is queried by the platform specific render window implementations. Maybe that would be a nice feature.
http://www.ogre3d.org/docs/api/html/cla ... 1_1Roota34
It seems there are flags "externalGLControl" and "externalGLContext" which might do what you want, but they are flagged as Win32 only.
I hope I can be more use in a couple of weeks once I have had a chance to get my head round Qt. I've never looked at it in this level of detail...
-
- Gnoblar
- Posts: 16
- Joined: Sun Aug 17, 2008 8:29 pm
Hi, thanks for the quick reply.
Cheers,
max
Well, for once, they claim to have it working front to back with ogre instead of plain OpenGL. The last post of that thread has code attached which seems to work for X11. I'd say that's an important step.PolyVox wrote: Regarding that QtCenter post, well I only skim read it but I thought it was redundant since the TT blog post? Or is there some reason you still need it?
I was thinking along the same lines, but I have no idea how to encode this context into a string. Also, I checked the Mac implementation of GL Render System and it doesn't check for a user supplied context.PolyVox wrote: It seems there are flags "externalGLControl" and "externalGLContext" which might do what you want, but they are flagged as Win32 only.
Cheers,
max
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Hi Guys,
Well it's hard work but I'm finally making progress with this See below:
As you can see it is possible to embed a Qt window in an Ogre scene and get the transparency effects (the transparency and antialiasing are not possible if you simply overlay a QWidget on an Ogre/OpenGL background). So, we have a proof of concept but I am struggling a lot and could really use everyone's help.
The problem is that most of the time I do not see an image like the one above, but instead I get an image like the one below:
As you can see, the QWidget has somehow become corrupted. I suspect this is somehow related to the OpenGL format which being used (for example, Ogre is using a different format from Qt) but I lack the low level knowledge to really address this. There is also a chance it's a driver bug, which is why I'd like interested people to try it out. In an attempt to find out what was going on I downloaded and used GL Intercept which provides a replacement OpenGL32.dll with logging capabilities. This gave me a whole bunch of error messages but - most interestinly - the corruption went away and it all worked perfectly. That is how I was able to obtain the first of the two screenshots above.
Anyway, I have prepared a sample (with source code) which I would like to use to identify the problem. I know there are many people who like to use Qt with Ogre so I hope this can be useful for everyone. You can get the sample from here:
Download QtOgre Sample
You can try running both the release and debug versions. If you get corruption like I showed above then please try renaming the files 'OpenGL32.dll.temp' and 'gliConfig.ini.temp' by removing the '.temp' extension. This will enable GL Intercept to run and may produce different results as I mentioned.
If you want to build from source I provided a .sln file. Remember to replace my Ogre .dll's with your own or versioning issues could cause more problems than we are solving. You will need to build from source if you want to experiment with what I have done, or if you have trouble running the provided .exe's (for example I couldn't run them at work).
Let me know how you get on! I think Qt in Ogre could be a really cool GUI solution so let's hope we can get this working.
p.s. A couple of points - no Linux version yet. I make use of the 'externalGLControl' flag to createRenderWindow() which is not supported on Linux. However, from reading around the forums it seems this flag could be implemented - it's just no one has done it yet. I'm trying to focus on one problem at a time Also, there is no Direct3D support. I will be working on a fallback (slower) approach which will read the rendered image back from the framebuffer in order to allow Qt to perform the transparency effects.
Well it's hard work but I'm finally making progress with this See below:
As you can see it is possible to embed a Qt window in an Ogre scene and get the transparency effects (the transparency and antialiasing are not possible if you simply overlay a QWidget on an Ogre/OpenGL background). So, we have a proof of concept but I am struggling a lot and could really use everyone's help.
The problem is that most of the time I do not see an image like the one above, but instead I get an image like the one below:
As you can see, the QWidget has somehow become corrupted. I suspect this is somehow related to the OpenGL format which being used (for example, Ogre is using a different format from Qt) but I lack the low level knowledge to really address this. There is also a chance it's a driver bug, which is why I'd like interested people to try it out. In an attempt to find out what was going on I downloaded and used GL Intercept which provides a replacement OpenGL32.dll with logging capabilities. This gave me a whole bunch of error messages but - most interestinly - the corruption went away and it all worked perfectly. That is how I was able to obtain the first of the two screenshots above.
Anyway, I have prepared a sample (with source code) which I would like to use to identify the problem. I know there are many people who like to use Qt with Ogre so I hope this can be useful for everyone. You can get the sample from here:
Download QtOgre Sample
You can try running both the release and debug versions. If you get corruption like I showed above then please try renaming the files 'OpenGL32.dll.temp' and 'gliConfig.ini.temp' by removing the '.temp' extension. This will enable GL Intercept to run and may produce different results as I mentioned.
If you want to build from source I provided a .sln file. Remember to replace my Ogre .dll's with your own or versioning issues could cause more problems than we are solving. You will need to build from source if you want to experiment with what I have done, or if you have trouble running the provided .exe's (for example I couldn't run them at work).
Let me know how you get on! I think Qt in Ogre could be a really cool GUI solution so let's hope we can get this working.
p.s. A couple of points - no Linux version yet. I make use of the 'externalGLControl' flag to createRenderWindow() which is not supported on Linux. However, from reading around the forums it seems this flag could be implemented - it's just no one has done it yet. I'm trying to focus on one problem at a time Also, there is no Direct3D support. I will be working on a fallback (slower) approach which will read the rendered image back from the framebuffer in order to allow Qt to perform the transparency effects.
-
- Gnoblar
- Posts: 16
- Joined: Sun Aug 17, 2008 8:29 pm
Very cool! I've been playing around with it as well, but didn't get anywhere. I tried to reuse the context from Qt (in RenderSystems/src/OSX/OgreOSXCarbonWindow.cpp:168 by passing aglGetCurrentContext() as the second arg to aglCreateContext()), but that somehow caused an error in Qt which I can't trace because I can't figure out how to link against the debug version of Qt... Seems to be a common problem on OSX.
In the meantime, I've thought about using the idea from
http://www.ogre3d.org/phpBB2/viewtopic.php?t=2750
and implementing a separate GLSupport using Qt. The only obstacle is that I would like it to be a plugin (no reason to make Qt a dependency), but choosing a GLSupport is done in at compile time of Ogre.
The cool thing would be that the RenderWindow would be a QGLWidget to start with, so no problem using it as a widget directly instead of hacking so it shows it in the same screen coordinates. Somehow, this seems cleaner to me. The only thing is that there has to be a way to set the GLSupport instance in GLRenderSystem, which shouldn't be too hard to do. After that, implementing a Plugin to replace the GLSupport should be easy. What do you think?
In the meantime, I've thought about using the idea from
http://www.ogre3d.org/phpBB2/viewtopic.php?t=2750
and implementing a separate GLSupport using Qt. The only obstacle is that I would like it to be a plugin (no reason to make Qt a dependency), but choosing a GLSupport is done in at compile time of Ogre.
The cool thing would be that the RenderWindow would be a QGLWidget to start with, so no problem using it as a widget directly instead of hacking so it shows it in the same screen coordinates. Somehow, this seems cleaner to me. The only thing is that there has to be a way to set the GLSupport instance in GLRenderSystem, which shouldn't be too hard to do. After that, implementing a Plugin to replace the GLSupport should be easy. What do you think?
-
- Gnoblar
- Posts: 16
- Joined: Sun Aug 17, 2008 8:29 pm
Hmm, I'm almost done with a GL Support Plugin with Qt. However, I have a problem with linking it properly.
The thing is that it obviously depends on symbols defined in the RenderSystem_GL plugin. I can compile and link it fine with "-undefined dynamic_lookup" which tells the linker that undefined symbols are ok and should be looked up when the library is loaded at runtime.
The thing is, it doesn't do it properly. Once I load the RenderSystem_GL plugin, those symbols don't seem to be part of the main program. So, once I dynamically load QtGLSupport, the dynamic library loader complains about missing symbols. Proper error message:
I'm not sure what to do. Is it possible at all to have plugins depend on other plugins?
The thing is that it obviously depends on symbols defined in the RenderSystem_GL plugin. I can compile and link it fine with "-undefined dynamic_lookup" which tells the linker that undefined symbols are ok and should be looked up when the library is loaded at runtime.
The thing is, it doesn't do it properly. Once I load the RenderSystem_GL plugin, those symbols don't seem to be part of the main program. So, once I dynamically load QtGLSupport, the dynamic library loader complains about missing symbols. Proper error message:
Code: Select all
*-*-* OGRE Initialising
*-*-* Version 1.4.9 (Eihort)
Loading library RenderSystem_GL
Installing plugin: GL RenderSystem
OpenGL Rendering Subsystem created.
Plugin successfully installed
Loading library QtGLPlugin
2008-08-23 15:20:22.428 demo[3951] CFLog (21): Error loading /Library/Frameworks/Ogre.framework/Resources/QtGLPlugin.bundle/Contents/MacOS/QtGLPlugin: error code 4, error number 0 (Symbol not found: __ZN4Ogre9GLSupport20initialiseExtensionsEv
Referenced from: /Library/Frameworks/Ogre.framework/Resources/QtGLPlugin.bundle/Contents/MacOS/QtGLPlugin
Expected in: dynamic lookup
)
terminate called after throwing an instance of 'Ogre::InternalErrorException'
what(): OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library QtGLPlugin. System Error: Unknown Error in DynLib::load at /Users/max/Desktop/ogre/Mac/Ogre/../../OgreMain/src/OgreDynLib.cpp (line 80)
Abort trap
-
- Gnoblar
- Posts: 16
- Joined: Sun Aug 17, 2008 8:29 pm
Okay, I figured out what the problem was.
Of course there are some more issues I need to look into...
Cheers.
Of course there are some more issues I need to look into...
Cheers.
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Argh, sorry, not getting enough time to post...
Ok, to get my ideas straight I'm going to summarise the various approaches I have found to combining Ogre and Qt:
Moving on to your current approach of implementing a GL support plugin based on the code in the other thread - I assume it is most similar to Option 3(b) above? I haven't yet had a chance to look at the code but I hope to do so tonight. If it is similar to option 3(b) then what of the advantages of doing it as a GLSupport plugin rather than a simple widget?
From reading that thread you linked it seems that doing it as a GLSupport plugin would allow it to be used in existing Ogre application without changes to the applications source code. Is this the case? Are there any other advantages?
That's very interesting - I'd seen that thread but I didn't get all the way to the end where the source code was released! I will have a look at it to get some ideas.pmax wrote:In the meantime, I've thought about using the idea from
http://www.ogre3d.org/phpBB2/viewtopic.php?t=2750
and implementing a separate GLSupport using Qt. The only obstacle is that I would like it to be a plugin (no reason to make Qt a dependency), but choosing a GLSupport is done in at compile time of Ogre.
Ok, to get my ideas straight I'm going to summarise the various approaches I have found to combining Ogre and Qt:
- Create a window (not necessarily a QGLWidget) using Qt and pass its window handle to Ogre using the 'externalWindowHandle' flag. Ogre then creates a context and is fully responsible for it. This is basically what I did for the first demo I made. It has the advantage that it should support both OpenGL and Direct3D, and also should work accross all platforms. The big drawback is that Qt widgets can only be overlaid (not integrated) so you don't get the nice transparency.
- An approach similar to (1) but with the difference that the frame buffer is explicitly read back from Ogre and used as a widget background. This would again work accross all render systems and platforms, and now Qt can perform proper compositing from transparency. However, it is potenially slow doe to the need to read back every frame and copy it to Qt. But this could make a good 'fallback' approach. I haven't tried implementing it yet.
- This is the 'proper' approach which we are really considering in this thread. It involves both Ogre and Qt owning OpenGL contexts and both rendering into the same widget. This widget is set as the background of a QGraphicsView/QGraphicsScene and other widgets can be overliad with proper transpaency effects. It only works with OpenGL and is (theorectically) cross platform. There are two variations:
- Allow Ogre to create it's own OpenGL context (passing the flag 'externalGLControl') and then retieve the context once createRenderWindow() has finished. Under windows there are the wglGetCurrentDC() and wglGetCurrentContext() for this - other platforms should have something similar.
- Have Qt create a context on Ogre's behalf and pass that to Ogre using the 'externalGLContext' flag. In this case Ogre basically does nothing except render into the context it it provided with - all the control is with Qt. I haven't quite got this to work yet as I was having crashes in both Qt and Ogre.
Moving on to your current approach of implementing a GL support plugin based on the code in the other thread - I assume it is most similar to Option 3(b) above? I haven't yet had a chance to look at the code but I hope to do so tonight. If it is similar to option 3(b) then what of the advantages of doing it as a GLSupport plugin rather than a simple widget?
From reading that thread you linked it seems that doing it as a GLSupport plugin would allow it to be used in existing Ogre application without changes to the applications source code. Is this the case? Are there any other advantages?
Great, I'm glad you fixed it. Sorry I'm not able to help with this - MacOS is outside of my expertise. But sinbad uses it, so he might be interested in what you said in that thread.pmax wrote:Okay, I figured out what the problem was.
Of course there are some more issues I need to look into...
Cheers.
- sirbabyface
- Gnoblar
- Posts: 14
- Joined: Mon Aug 18, 2008 4:02 pm
- Location: Coimbra, Portugal
- Contact:
-
- Halfling
- Posts: 49
- Joined: Wed Jun 09, 2004 11:13 pm
Try resizing the main window, or add
before the addWidget() thing.
Code: Select all
dialog->move(10, 10);
- sirbabyface
- Gnoblar
- Posts: 14
- Joined: Mon Aug 18, 2008 4:02 pm
- Location: Coimbra, Portugal
- Contact:
- PolyVox
- OGRE Contributor
- Posts: 1316
- Joined: Tue Nov 21, 2006 11:28 am
- Location: Groningen, The Netherlands
- x 18
- Contact:
Ok, I've uploaded a new version as I made some mistakes with the original. I previously included the debug build (which couldn't be run), forgot the Qt .dll's, and included the 20Mb Intellisense files. People who failed to run it before, it would be great if you tried again (same link).
@sirbabyface - Please try the new version (with my .dll's though it shouldn't matter?). Also please try the trick I mentioned in the earlier post of renaming the files 'OpenGL32.dll.temp' and 'gliConfig.ini.temp' by removing the '.temp' extension. This causes it to run through GLIntercept which fixes the corruption on my machine.
@slan - So did you try it? Did it work?
I have a busy couple of days, but later in the week I'll look at the code pmax linked and see If I get more ideas.
Also it's incredibly slow for me (just a few FPS) which I'm attributing to the same thing which causes the corruption. Whatever that is
@sirbabyface - Please try the new version (with my .dll's though it shouldn't matter?). Also please try the trick I mentioned in the earlier post of renaming the files 'OpenGL32.dll.temp' and 'gliConfig.ini.temp' by removing the '.temp' extension. This causes it to run through GLIntercept which fixes the corruption on my machine.
@slan - So did you try it? Did it work?
I have a busy couple of days, but later in the week I'll look at the code pmax linked and see If I get more ideas.
Also it's incredibly slow for me (just a few FPS) which I'm attributing to the same thing which causes the corruption. Whatever that is