QtOgre Application Framework - Now using Qt 4.5

[banal]

Hi
I'm sorry, this code must have slipped in while i tested some things. It works without that code, so please feel free to remove it.
Cheers

[PolyVox]

Ok, no problem. The patch is commited now.

In other exciting news Qt 4.5 has now been released I notice this version comes with an SDK which will hopefully make installation easier and help boost it's adoption. At some point I will make sure QtOgre works smoothly with it, but this won't be for a few weeks I'm afraid!

[alex_qt]

Hi !

Has anyone managed to use Ogre with Qt 4.5 ?

Working code linked with 4.4, is flickering a lot with 4.5...
It seems as someone said before that the backbuffer is switched twice ...

[PolyVox]

I haven't tried it I'm afraid. Of course I will at some point, but knowing there are likely to be problems I will have to wait until I have time to fix them as well

[rtlpixy]

To make QtOgre works with qt 4.5 just override QWidget::paintEngine() method returning 0 in the OgreWidget class.
Doing this you will tell Qt to don't use its internal backing store mechanism to display the ogre window.

OgreWidget.h (add the paintEngine() declaration)

Code: Select all

protected:
    ...
    ...
    QPaintEngine *paintEngine() const;

OgreWidget.cpp (implementation of paintEngine() method)

Code: Select all

...
...

  QPaintEngine *OgreWidget:: paintEngine() const
  {
    return 0;
  }

...
...

Best,

Angelo

[PolyVox]

Thanks again for this! I've comited the fix for Subversion.

[dermont]

I have a problem with with the Qt OgreWidget, when I resize the main frame the render window is not resized to fit the main frame:

GeForce 9800 GTX/9800 GTX+
GL_VERSION = 3.0.0 NVIDIA 180.44
QtFrameWork revision 2681M, Ogre1.6.1, Qt4.5.0


If I replace "parentWindowHandle" with "externalWindowHandle" and uncomment
the handle info.visual() string the render window is resized correctly, i.e. the handle in the form:
poslong:posint:poslong:poslong (display*:screen:windowHandle:XVisualInfo*)

Has anyone else encountered this?

[PolyVox]

Very interesting.You probably noticed that the code contains #ifdef blocks such that it uses 'externalWindowHandle' on Windows and 'parentWindowHandle' on Linux. To be honest I don't know what the difference between these two parameters is as the docs don't really make it clear. I just found the current configuration by trial and error, but it seems it doesn't work for you...

Try setting both of them, maybe that's how it's meant to be used? Otherwise it might be worth having a look in sinbad's WxWidgets MVC framework to see what he does in there, because there's a good chance he's doing it right

I'll look into it mysef, but not until next week as I'm away for a few days.

[chmod]

Polyvox this is great work. I grabbed your source to play around with tonight and noticed a few things that might make your life easier.

In your Log class you're using a QTableWidget which sacrifices a lot of the power of Qt4's model/view framework. For instance there's really no need for a bunch of seperate Log instances, each log message could be put into subclass of QAbstractTableModel and then you could do all of your filtering and sorting on a single data structure. This also makes it very easy to give different DisplayRoles to the items. This way you could also easily filter across several logs at once with much more speed than doing it on each log.

I know it might be too much of an investment when you already have something working, but it's a huge advantage to having Qt4 around, and I heartily recommend using it in the future.

Also, had you thought about letting Ogre continue to run the main loop and just calling processEvents on your Qt/Ogre application periodically?

EDIT: The prebuilt version runs fine for me, but when I build from source in both debug and release the video mode combobox (mWindowModeComboBox) has no values in it, and then crashes after I select DX9 and run. I guess there's a diff between your binary release and the source release?

[PolyVox]

Polyvox this is great work. I grabbed your source to play around with tonight and noticed a few things that might make your life easier.

Thanks for your interest

In your Log class you're using a QTableWidget which sacrifices a lot of the power of Qt4's model/view framework. For instance there's really no need for a bunch of seperate Log instances, each log message could be put into subclass of QAbstractTableModel and then you could do all of your filtering and sorting on a single data structure. This also makes it very easy to give different DisplayRoles to the items. This way you could also easily filter across several logs at once with much more speed than doing it on each log.

I know it might be too much of an investment when you already have something working, but it's a huge advantage to having Qt4 around, and I heartily recommend using it in the future.

Sounds interesting. I have to admit I'm not a Qt expert so I basically used the easiest way that I could find. But I'll consider it as an improvement if I get time in the future.

Also, had you thought about letting Ogre continue to run the main loop and just calling processEvents on your Qt/Ogre application periodically?

Hmmm... I hadn't thought of it. So essentially it would decouple the rate at which frames were rendered from the rate at which events were processed. What would be the advantage of this, and which do you think should happen more frequently? I'm not against it, just not sure what the advantage would be.

EDIT: The prebuilt version runs fine for me, but when I build from source in both debug and release the video mode combobox (mWindowModeComboBox) has no values in it, and then crashes after I select DX9 and run. I guess there's a diff between your binary release and the source release?

Strange, the values for the combo box should be pulled from 'settings.ini' under 'Graphics/WindowModes'. Are they in that file? The version in SVN has some valid values.

[chmod]

Thanks for your interest

You bet

Sounds interesting. I have to admit I'm not a Qt expert so I basically used the easiest way that I could find. But I'll consider it as an improvement if I get time in the future.

I might end up doing this for you because I'd like to use your logging component If I handed off some code to you would that be ok? It appears you're using SVN (since there are branches and tags dirs in your source release), would you let me work against that with you?

Hmmm... I hadn't thought of it. So essentially it would decouple the rate at which frames were rendered from the rate at which events were processed. What would be the advantage of this, and which do you think should happen more frequently? I'm not against it, just not sure what the advantage would be.

Well the advantage comes when you're using more of Qt (if anyone wanted to do that). Say message passing, or serializing video to disk etc... Anything where you want Qt to go slower or faster than your game loop.

Strange, the values for the combo box should be pulled from 'settings.ini' under 'Graphics/WindowModes'. Are they in that file? The version in SVN has some valid values.

Heh, I deleted it thinking it would query my vid card for valid modes. Shoving the one from your prebuilt release into my build worked. It all runs great on 4.5 with the patch mentioned above.

[PolyVox]

I might end up doing this for you because I'd like to use your logging component If I handed off some code to you would that be ok? It appears you're using SVN (since there are branches and tags dirs in your source release), would you let me work against that with you?

Sure, it would be great if you improve the logging framework I can't give you SVN write access as it's actually Ogre's SVN repository and not my own, so you'll have to ask Sinbad for that. In the mean time, you can just send me patches or work locally. Oh, I'll you'll need to be happy to release your code unde the ZLib license.

Well the advantage comes when you're using more of Qt (if anyone wanted to do that). Say message passing, or serializing video to disk etc... Anything where you want Qt to go slower or faster than your game loop.

Ok, I will do something about this. I think I'll just provide an option to disable the built in timer, and then allow people to call the functions directly using thier own loop/timers/etc. But I'll leave the current behaviour on by default, as it makes it easier to get started.

Heh, I deleted it thinking it would query my vid card for valid modes. Shoving the one from your prebuilt release into my build worked. It all runs great on 4.5 with the patch mentioned above.

Yeah... I don't know a way to detect resulutions from Qt. Probably it would have to be platform specific code, or maybe there is a way to get Ogre to report them. I didn't look into this very hard.

[chmod]

If your source zip is somewhat stable I can just send you diffs based on that. I should have some time this weekend to bang it out. The option of using Qt's loop would be great, but sure, leave it as an option.

It should be possible to let Qt build the video modes dialog with info from the available plugins. But you'd have to query the driver whenever they selected OpenGL or DX which might not be that great. I built a video mode configuration GUI using Hikari before, but I've lost a lot of interest in Flash as I work for Nokia now and get to use Qt all day

Just let me know if that source is current enough and I'll send you some unified diffs.

[milliams]

Just let me know if that source is current enough and I'll send you some unified diffs.

While you don't have write access to the repo, it's publicly accessible at svn co https://ogreaddons.svn.sourceforge.net/ ... Framework/. There have been some changes since the last release so it's probably easiest to make the changes directly against the SVN repo.

[chmod]

Just let me know if that source is current enough and I'll send you some unified diffs.

While you don't have write access to the repo, it's publicly accessible at svn co https://ogreaddons.svn.sourceforge.net/ ... Framework/. There have been some changes since the last release so it's probably easiest to make the changes directly against the SVN repo.

Thanks for the info. I'll work off of that.

[PolyVox]

Agreed with milliams. Though to be honest it's not changing much at the moment as I'm focusing on other parts of my engine, but it still forms the foundation of my engine so I'll need to work on it further in the future.

[chmod]

Well I didn't get all the time I needed yesterday, but it's done enough today to show it.

I made the diffs against SVN revision 2687

All changes were constrained to the Log.h Log.cpp and Log.ui files.
Several new classes were added into those files making it a bit cluttered, but I didn't want
to presume how you'd want the file structure to look. They should be quite easy to pull out
into separate files. Also I don't know cmake very well and didn't want to screw with the
build system.

All filtering is done via the LogModelProxy. It supports text filtering as well as loglevel filtering
via the top buttons. The filtering is a bit more efficient due to how Qt stores models in memory. It's
also easy to add new filering modes. Right now the text filtering is hooked up to QRegExp-based filtering
but it could easily be made for wildcard, or simple text matching.

I've attached a zip of both the new versions of the files changed, as well as unified diffs. Let me know what you think.

[PolyVox]

Nice work! It works properly in the demo and also in my engine so I have comitted the changes. I also added a credits file as it seemed fair at this point.

I'll split the files up so there is one class per file and update the build system as necessary. I'll also make sure the naming conentions, etc match those used elsewhere (I've generally tried to follow the Qt way of doing things).

Also, are you using the static or dynamic linking to link to QtOgre in your project? I've noticed a couple of times a strange bug in the build system such that I have to build the solution twice before it is sucessful. I'll look into it, and might remove the dynamic option (as that seems to be the trouble maker). But not if your using it, of course.

[chmod]

Nice work! It works properly in the demo and also in my engine so I have comitted the changes. I also added a credits file as it seemed fair at this point.

I'm happy it works. And thanks for the credit I didn't mention before, but ZLib license is fine.

I'll split the files up so there is one class per file and update the build system as necessary. I'll also make sure the naming conentions, etc match those used elsewhere (I've generally tried to follow the Qt way of doing things).

Yeah sorry about that, I get to coding and forget how everyone else does var names. I'm from the underscored_method_name() family of coder. Probably due to the python background.

Also, are you using the static or dynamic linking to link to QtOgre in your project? I've noticed a couple of times a strange bug in the build system such that I have to build the solution twice before it is sucessful. I'll look into it, and might remove the dynamic option (as that seems to be the trouble maker). But not if your using it, of course.

I haven't actually moved my game to it yet. It's going to be a ton of work. So much so, that I'm even considering starting over with the Qt stuff, then bringing my game into it piece by piece.

Also just an FYI, but in most of my Qt projects I define some logging macros like so:

Code: Select all

#define LOGD qDebug() << __FILE__ << __LINE__ << __FUNCTION__

So then I can use the stream operators for logging, and then in the logging handler I insert the timestamp and dump it into a file. So you can do things like

Code: Select all

LOGD << "something:" << bool << float << some_instance;

[PolyVox]

I haven't actually moved my game to it yet. It's going to be a ton of work. So much so, that I'm even considering starting over with the Qt stuff, then bringing my game into it piece by piece.

Yeah, I had the same thing when I ported my engine to the framework (earlier version of my engine were just built on the Ogre example app, CEGUI, etc). I'm my usual approch to changing software is just to change one thing at a time to always keep it working - but in this case I think I had to just rip it out and start from scratch.

Also just an FYI, but in most of my Qt projects I define some logging macros like so:

Code: Select all

#define LOGD qDebug() << __FILE__ << __LINE__ << __FUNCTION__

So then I can use the stream operators for logging, and then in the logging handler I insert the timestamp and dump it into a file. So you can do things like

Code: Select all

LOGD << "something:" << bool << float << some_instance;

That should still work with the QtOgre framework, right? I don't think I'll add the macro to the library though - people can do that in their application if they want it.

[chmod]

The porting to a diff framework is going to be a whole weekend project But it's about time. There is a lot of cruft still in there from when I was first learning Ogre (and OIS, and PhysX, and FMOD etc...)

RE: Logging macros. It's actually kind of tough to use both pre-processor macros and your Log object system at the same time. Since new logs can be created at runtime. But having file, line, and function as part of the log messages can be really great when you're trying to find something tricky.

RE: further extension of the Qt stuff. Do you want any help getting Qt rendering on OGRE objects? I think that would be such a killer feature. I'd love to help out however I can.

[milliams]

RE: further extension of the Qt stuff. Do you want any help getting Qt rendering on OGRE objects? I think that would be such a killer feature. I'd love to help out however I can.

If you see the TODO.txt file in the SVN repo (under the heading '3D Widgets') you'll see the results of the half hour I spent thinking about exactly that. I've done essentially nothing on it but I agree that it would be a killer feature.

[PolyVox]

RE: Logging macros. It's actually kind of tough to use both pre-processor macros and your Log object system at the same time. Since new logs can be created at runtime. But having file, line, and function as part of the log messages can be really great when you're trying to find something tricky.

Sure, it sounds useful, but I'm still not sure it needs to be done using macros. Perhaps the log class should have a set of flags indicating what should be appended, something like that? I'll tidy the logging code and have a think about it...

RE: further extension of the Qt stuff. Do you want any help getting Qt rendering on OGRE objects? I think that would be such a killer feature. I'd love to help out however I can.

I agree this would be awesome, but it needs some thought before implementing. There's actually a bunch of different ways of integrating Qt and Ogre, questions of who is 'in charge', issues about which methods work on which platforms and with which render systems. I summarised some of my previous work here:

http://www.ogre3d.org/forums/viewtopic.php?t=42733

Since then Qt 4.5 might have changed some things (I think there is also DirectX support in Qt now?).

But my gut instinct is that a proper Qt and Ogre integration would operate at quite a low level, and should integrate nicely with the QtOgre framework without changing the higher level logic too much. But maybe it's useful to create a simple, stand alone example showing the concepts? That's what I tried to do in the thread linked above.

Personally, any time I put into QtOgre will be focused at a higher level. So if you want to have a look at rendering Ogre into Qt objects (or vice-versa) then you would be welsome

[Edit:] One thing which might be interesting is that from Qt 4.5 there are different render systems which can be used to draw Qt widgets. There is an experimental OpenGL render system. Maybe an Ogre one could be written? Then Qt Objects would be rendered with Ogre commands... maybe that's the 'cleanest' way to do it? Might be a lot of work though...

[Moohasha]

Just a quick update - the code is now available from Ogre Addons in the 'QtOgreFramework' directory.

I guess I'm missing something obvious, becaue I can't find the code. Are you talking about the Addons forum? Because I didn't see a QtOgreFramework there. The links you have on the first post for the prebuild demo and the source looks like the source for just the demo. Where can I get the source code for QtOgre?? I know I'm gonna kick myself when I finally find it...

[trnrez]

@Moohasha https://ogreaddons.svn.sourceforge.net/ ... eFramework