Does anyone use a Model View Controller Architecture for their games? If you do, are you storing the mesh data in the View or the model?

I try to use the appropriate pattern for what I am trying to do. In the case of MVC, I do use it, but I also use Doc/View which is a variant.

I've been a pattern addict since I picked up the GoF book three years ago. :)

For the people storing the mesh in the model; doesn't this violate the separation of concerns principle? It there an Object Oriented argument that can be made for storing the mesh in the model?

Thanks

I'm a little confused: wouldn't the renderer be considered part of the view ?
I voted mesh in view, but the view is the renderer, no ?

Simon.

I'm a little confused: wouldn't the renderer be considered part of the view ?
I voted mesh in view, but the view is the renderer, no ?

Simon.

Yes and No; the renderer is really only part of the view if you are using a Model / View architecture where the model can not directly see the view. Sometimes people allow their models to see the renderer; which strictly speaking is not the view; it is more or less a API to perform the act of the view.

So if your mesh is stored in the view how are you doing collision detection? Or are you just using a bounding box; etc?

Ah, i think i see what you are getting at. My present game has fairly simple character position information so I can pretty much separate the mesh from the model. I do need to keep an animation frame index in the model, however.

If I was to make, say, a starship game and wanted bombs/lasers be able to hit specific parts of my ship then, yes, the model would have some mesh information. I guess I would try to adhere to the DRY principle (do no repeat yourself), and somehow extract collision geometry and graphics mesh from the same source.

Simon.

I am not familiar with DRY principle? I am thinking that if you store the mesh in the model you can't necessarily replace the view without changing the model? Unless the new view expects the same mesh format. For example, if you ported from DirectX to OpenGL the mesh format would be very different?

That said, I feel like I have been living ground hogs day trying to figure out this issue; it would be far easier to put the mesh in the model and be done with it? Any advice?

I am not familiar with DRY principle? I am thinking that if you store the mesh in the model you can't necessarily replace the view without changing the model? Unless the new view expects the same mesh format. For example, if you ported from DirectX to OpenGL the mesh format would be very different?

Check this out:
http://www.artima.com/intv/dry.html. I'm a big fan of the Pragmatic Programmers (http://pragmaticprogrammer.com/index.html).

Why not store the mesh in a format neutral file (XML??), and then process it into whatever data you need ?

That said, I feel like I have been living ground hogs day trying to figure out this issue; it would be far easier to put the mesh in the model and be done with it? Any advice?

Just do it. You'll screw it up ;), but until you try something you won't know.

Simon.

Personally I've never bothered with MVC. My entities (2D) have direct references to bitmaps. The bitmap class is platform-independent but maintains a pointer to a platform-dependent native_bitmap. I have two implementations for native_bitmap, one using OpenGL and one using the SDL 2D API. You could do something similar with 3D meshes.

In my architecture, both the rendering system and the collision system depends on a model system in a lower layer which takes care of loading the file and presenting it to whatever needs the information. Then the renderer and the collision system can use that data in an optimal way.

The reason I did this is because the renderer and the collision system have different needs for what they need to know about the models. (The collision system usually just needs vertex positions while the renderer wants all kinds of data)

With an MVC architecture, you'd have something like this:

The "model" should contain the mesh, textures, animation sequences, current location and orientation, current vector, and game specific stuff like damage and ammo.

The "view" is the end result of the rendering pipeline. The API for manipulating the view (OpenGL, D3D, GDI, SDL, etc) is considered part of the view.

The "control" sits in the middle. It makes calls into the model to get the information needed to render, and it makes calls into the view to do the rendering. It can receive calls from the view (event handling). It rarely needs to receive calls from the model. The model and view are completely separated.

The DocView architecture is a little different, and seems to be more common for this kind of situation. The model and control are combined into the "doc"; view stays the same. The doc knows how to render itself, and makes calls directly to the view to do so.

With an MVC architecture, you'd have something like this:

The "model" should contain the mesh, textures, animation sequences, current location and orientation, current vector, and game specific stuff like damage and ammo.

The "view" is the end result of the rendering pipeline. The API for manipulating the view (OpenGL, D3D, GDI, SDL, etc) is considered part of the view.

The "control" sits in the middle. It makes calls into the model to get the information needed to render, and it makes calls into the view to do the rendering. It can receive calls from the view (event handling). It rarely needs to receive calls from the model. The model and view are completely separated.


I am not sure if you are describing the MVC design pattern; or how you would implement it. I will assume that you are describing your implementation. If you put all put everything from world matrices to vectors to texture to meshes in the model. You won't have any reuse at all out of your model; unless you all your data structures are custom and you use a custom math library.

For example, the DiectX D3DXVector3 data structure is part of DirectX; so if it goes in your model you will have to make major changes to the model if your trying to port the code.

In my architecture, both the rendering system and the collision system depends on a model system in a lower layer which takes care of loading the file and presenting it to whatever needs the information. Then the renderer and the collision system can use that data in an optimal way.

The reason I did this is because the renderer and the collision system have different needs for what they need to know about the models. (The collision system usually just needs vertex positions while the renderer wants all kinds of data)

I heard other people mention this approach; can you clarify it with a small diagram?

- Sean Doherty -
I am not sure if you are describing the MVC design pattern; or how you would implement it.

I was describing both, using 3D stuff as an example. In the "general" sense, the model should contain data, the control should contain logic for manipulating the data and the view should be responsible for presenting the data. The view and the model should be completely separate.

- Sean Doherty -
For example, the DiectX D3DXVector3 data structure is part of DirectX; so if it goes in your model you will have to make major changes to the model if your trying to port the code.

Well, you're right, putting D3DXVector3 in your model tightly couples the model to DirectX. And if you want to stay platform-neutral, that's a bad thing. That's not a problem with MVC, that's a problem with the data that you're putting into your model. If portability is an issue, then don't use D3DXVector3, use something else. Create your own vector class that wraps D3DXVector3.

I heard other people mention this approach; can you clarify it with a small diagram?


// ModelData is known by both the render and collision system
struct ModelData
{
vector<ModelVertex> vertices;
vector<unsigned short> indices;
..
more data here which the model can contain
..
};

// The render and collision system retrieve the data through this interface
class ModelCache
{
public:
const ModelData *GetModel(const std::string &name);
};

// Example of how the render and collision systems gets the model data
class RenderObject
{
public:
RenderObject(const ModelData *md);
private:
VertexBuffer *m_vb;
..
..
};

class CollisionObject
{
public:
CollisionObject(const ModelData *md);
};


Then each system can either use the data directly or copy it to an optimized format (into a vertex buffer for example). Did this clear things up?