Good use of the MVC pattern with Qt and Ogre for 3d editors.

[toglia]

As many people, I want to do my first mini 3d editor for my game. The editor word here is just huge cause what I want to do is very simple.

Anyway, I have been messing with Qt for a few months now, doing a 2d editor, and I'm almost getting addicted to it, although I know I'm certainly not using it at its best. One of the main things I didn't like, for example, was syncing the Qt model (QStandardItemModel) with Ogre's Scene.

I used the QT model to store all the logic of the 2d scene itself. I would have an element/sprite per row with columns like name, position, dimension, showing/hiding, textures, etc, etc. This allowed me to use this model as a center for all the views; like, the elements view, texture view, etc. But most of the time I would catch an event, change the model then change the scene, which I always thought it was an error prone way of doing things, but it was the best I could do by that time.

I have discovered many cool things about Qt, but since a lot of Ogre users have used it before to create 3d editors too, I would like to know how did you guys end up implementing the model view controller pattern, or how, for example, do you sync the world scene in a tree view.

Thanks!

[JaJDoo]

this topic gave me quite a headache for quite some time until i came up with something;

i use a simple class to store the important information and share a pointer between 3 elements:
1. the ogre widget
2. the item view
3. a central class i call CommandRelay (you know its an awesome name, don't deny it)

the class of the object shared for a "mesh object" looks like this (i'm in an intensive reworking of the program, but the general outline might stay)

Code: Select all

    class MeshObjectData : public ObjectData
    {
    public:
        MeshObjectData( QString new_name, QString new_mesh_name );
        MeshObjectData( const MeshObjectData& ref );

        MeshObjectData* clone() {return new MeshObjectData(*this);}

        ~MeshObjectDataPackage() 

    protected:
        bool                enabled;
        QString             mesh_name;
        QHash<int, QString> submesh_materials_map;
        QString             render_group_name;
        Ogre::uint8         render_group_id;
        Ogre::Quaternion    oritentation;
        Ogre::Vector3       position;
        Ogre::Vector3       scale;
    };

the item view and the ogre widget have their own native classes to manage the information on their own. the relay simply holds the pointer. the reason i do that is because i want to be able to shut down either ones (for instance, to relaunch ogre with different preferences while keeping the scene as it was), and be able to store undo commands and the items related to them at the same class.

generally speaking, i have two main 'chains' of signals running throughout the application: one originating from the relay, and the other converging to it from all relevant locations ( i call them toRelay and fromRelay). each class that needs this connection 'plugs-in' to it (having its own toRelay and fromRelay signals; this way i always connect to\fromRelay to another to\fromRelay) and a receiving slot if needed (some classes just forward the signal without using the information themselves); this helps me keep track of who does what and avoid an overload of 'local'/specific signals running around from place to place. the command relay has a slot for receiving from each of the major objects (such as the ogre widget). the slot processes the package and sends a new one. in this way, i can make a change in one place, and tell all the other holders to perform an "internal update" (read from the shared data pointer)

the signal chains carry only a single type of class - DataPackage. it carries one QVariant and package_type. you can use Q_DECLARE_METATYPE to allow one of your classes to be stored in a QVariant. this way i can send whatever i want..

so.. i bombarded you with my unhealthy approach.
you might want to take a look at how they do it in ogitor, never did myself, but somehow i feel they did it better (me = destructive amateur)

[stealth977]

Umm, well, we do not use MVC pattern in Ogitor. %99 of the functionality is in Ogitor's core which only depends on OGRE, so it doesnt directly use anything else, especially its not tied to GUI in any way.

We did this, because we switched 3 different GUIs Fluent UI (MFC) / WxWidgets and Qt.

So, we already have a signal/slot based framework for our scene objects. The Qt views register themselves to the signals of the object they want to track and when a change is signalled, they automatically update themselves, one sideaffect/benefit of this approach is, you can record the signals and issue backwards for auto UNDOs

[toglia]

JaJDoo I must say your approach seems a little complex, not that much, just a little. The CommandRelay class reminds me of Mass Effect 2!

So, we already have a signal/slot based framework for our scene objects.

Did you guys use Qt's signals and slots?

The Qt views register themselves to the signals of the object they want to track and when a change is signalled, they automatically update themselves

So basically; for example, you have a "GameObject" class which emits a signal when it changes position. When initializing the GUI you would connect that signal with some editBox's setText slot right? Sounds pretty reasonable.

But how would you do to show Ogre's Scene Manager's hierarchy in a Qt tree view? I'd have to roll my own scene tree right? and emit signals for element added/modified/deleted and stuff like that?

Thanks stealth I was hoping you'd participate, I knew Ogitor was recently changed to Qt.

[stealth977]

We have our own signal/slot system (as i told before, our core does not depend on external libraries, except OGRE).

We have a PROPERTY class (template). Each object consists of PROPERTIES. So, lets say when you select an object, our qt properties view requests a PROPERTYLIST from that game object and auto creates the tree to display, lso auto connects to each displayed property and if any of them change, italso changes the value displayed. It uses the same technique for any VIEW that wants to display status of any framework class, it connects to the signals of the properties that class has...

[JaJDoo]

I'll summarize my babbling :
relay, ogre widget and item views keep pointer to data. when change is made, each of the holders reads in its own way.
the signal chains just move stuff around (so the pointer/command could reach the holders)

its not complex, its science fiction.

.. or something.
i feel like i could have made a better joke, but i want to sleep now.

edit: i thought about doing something like you said stealth, but i preferred an overly complex system to fit my madness.
well in truth i started something like that with a hash map but went back because what i'm working wouldn't really expand that much so i went for fixed style.

[toglia]

edit: i thought about doing something like you said stealth, but i preferred an overly complex system to fit my madness.
well in truth i started something like that with a hash map but went back because what i'm working wouldn't really expand that much so i went for fixed style.

One can never get too ambitious right!

[jacmoe]

MVC - that's a tough one.

Sinbad gave a shot at it with wxOgreMVC:
https://ogreaddons.svn.sourceforge.net/ ... /wxOgreMVC
That might be worth a look.

I really enjoy using MVC, but not in my Ogre programming.
I use it when I do web programming - CakePHP and Yii frameworks - and I think it suits that perfectly:
Model - database and data logic
Controller - actions middle man between Model and View
View - presentation layer

In graphics programming I think it's rather difficult to define what goes where..

But maybe that's me.

Qt does indeed use the MVC pattern, you can see that here:
http://doc.trolltech.com/qq/qq10-mvc.html
You can use that to present the same data in different ways using different sets of logic.
That's basically what MVC helps you do.

Unless your application is data-driven, there's no need to use the MVC pattern, IMHO.

I am using it in my web applications, and we *could* use it in Ogitor as well - but, as Ismail points out: we're not.
We are simply using the built-in widgets.
We could probably create a custom model and a controller for the treeview, but the (hacked by us) Qt property explorer works fine.
So we don't care.