Support and community hang-out spot for Ogre3D
https://forums.ogre3d.org/
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!Code: Select all
protected:
...
...
QPaintEngine *paintEngine() const;
Code: Select all
...
...
QPaintEngine *OgreWidget:: paintEngine() const
{
return 0;
}
...
...
Thanks for your interestchmod wrote: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.
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.chmod wrote: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.
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.chmod wrote:Also, had you thought about letting Ogre continue to run the main loop and just calling processEvents on your Qt/Ogre application periodically?
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 wrote: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?
You betPolyVox wrote:Thanks for your interest
I might end up doing this for you because I'd like to use your logging componentPolyVox wrote: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.
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?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.PolyVox wrote: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.
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 wrote: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.
Sure, it would be great if you improve the logging frameworkchmod wrote:I might end up doing this for you because I'd like to use your logging component
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. 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.chmod wrote: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.
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 wrote: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.
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 wrote:Just let me know if that source is current enough and I'll send you some unified diffs.
Thanks for the info. I'll work off of that.milliams wrote: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 wrote:Just let me know if that source is current enough and I'll send you some unified diffs.
I'm happy it works. And thanks for the creditPolyVox wrote: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 didn't mention before, but ZLib license is fine.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.PolyVox wrote: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).
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.PolyVox wrote: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.
Code: Select all
#define LOGD qDebug() << __FILE__ << __LINE__ << __FUNCTION__Code: Select all
LOGD << "something:" << bool << float << some_instance;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.chmod wrote: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.
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 wrote:Also just an FYI, but in most of my Qt projects I define some logging macros like so:
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 likeCode: Select all
#define LOGD qDebug() << __FILE__ << __LINE__ << __FUNCTION__
Code: Select all
LOGD << "something:" << bool << float << some_instance;
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...)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.chmod wrote: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.
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...chmod wrote: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.
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:chmod wrote: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 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...PolyVox wrote:Just a quick update - the code is now available from Ogre Addons in the 'QtOgreFramework' directory.