You are mixing responsibilities because you are not properly assessing the relationships between components.
For example, it may very well be that the only system in your “engine” using matrices is your graphics module. That doesn’t mean matrices are part of the graphics library; even if no other system uses them, they are still part of the basic math module in your engine.

Likewise, a model has no place within the graphics module. While implementations and responsibilities between graphics modules may vary, a general theme is that the graphics module simply handles the commands needed to render things, and provides wrappers for textures, vertex buffers, index buffers, and shaders.

It only understands these basic components, and a few render states such as lighting on/off (which is then processed by the active shader) etc.


You consider that models are “what the graphics module draws”, so you plan to put them into the graphics module.
No, models are not what the graphics module draws. The graphics module draws whatever it is told to draw. It could be a model. It could be terrain. It could be a 2D sprite. It could be completely custom, done by the user.

Not only that, but you are forgetting that graphics are only a small part of models. What about collision boxes? Animations can be made faster using the GPU, but they are not a “graphics asset”. What about the bounding boxes that allow the model to be part of an octree?
Are you planning to incorporate all of this into your graphics module? If I link to your graphics module, am I also required to link to a collision-detection library or physics library?

As the render manager is the only thing that knows about the graphics device how can the resource manager load the mesh?

Why are these mutually exclusive?
If the render manager knows about the graphics device, it should probably provide an interface so that other modules can use that graphics device.
And that is basically its only job. Once it does anything more than this, including loading models, it has overstepped its responsibilities.

Additionally, the job of loading/managing models is not on the “resource manager”. Such a term is too broad in definition. Virtually anything can be a resource, and making a single manager to handle all of them is not a happy idea.

If you consider that the job of the rendering module is simply to provide an interface to the graphics hardware and draw whatever it is told to draw, then you can think of the model library as a way of telling the graphics module what to draw.
And your terrain library will tell it how to draw terrain.

Models and terrain both need to render. This does not make them part of the graphics module.
Models and terrain are both resources. This does not mean it is necessary to make some kind of mega resource manager.


The only “mega” in your engine should be the highest-level engine library, which knows what a renderer is, knows what models are, knows what terrain is, and knows how to connect all these parts together to make your game world.
Just in case that causes a bit of confusion, remember that some modules can connect to other modules on their own, without the need of the mega module making the connection for them. That is, the model library knows what the graphics library is regardless. The mega engine module doesn’t connect models to the renderer, but it manages models in the physical (virtual?) game world and allows them to interact with other components such as terrain.


L. Spiro

<p>[quote name=&#39;lukesmith123&#39; timestamp=&#39;1327274248&#39; post=&#39;4905246&#39;]As the render manager is the only thing that knows about the graphics device how can the resource manager load the mesh? [/quote]I would use something like this:class AssetLoader</p>
<div>{</div>
<div>public:</div>
<div>template<class T> typename T::Type* Load( const char* name, T&amp; receiver )</div>
<div>{</div>
<div>char* data; uint size;</div>
<div>LoadFile( &amp;data, &amp;size );</div>
<div>receiver.OnLoaded( data, size );</div>
<div>}</div>
<div>};</div>
<div> </div>
<div>struct Mesh {};</div>
<div> </div>
<div>class MeshManager</div>
<div>{</div>
<div>public:</div>
<div>MeshManager(ID3DDevice9* d) : device(d) {}</div>
<div>typedef Mesh Type;</div>
<div>Mesh* Load( const char* name, AssetLoader&amp; loader )</div>
<div>{</div>
<div>return loader.Load( name, *this );</div>
<div>}</div>
<div>private:</div>
<div>friend class AssetLoader;</div>
<div>Mesh* OnLoaded( char* data, uint size )</div>
<div>{</div>
<div>return new Mesh;//...</div>
<div>}</div>
<div>ID3DDevice9* device;</div>
<div>};</div>
<div> </div>
<div>class GraphicsManager</div>
<div>{</div>
<div>public:</div>
<div>GraphicsManager(ID3DDevice9* d) : device(d), meshManager(d) {}</div>
<div>MeshManager meshManager;</div>
<div>private:</div>
<div>ID3DDevice9* device;</div>
<div>};</div>

As the render manager is the only thing that knows about the graphics device how can the resource manager load the mesh?

I would use something like this:class AssetLoader
{
public:
template<class T> typename T::Type* Load( const char* name, T& receiver )
{
char* data; uint size;
LoadFile( &data, &size );
return receiver.OnDataLoaded( data, size );
}
};

struct Mesh {};

class MeshManager
{
public:
MeshManager(ID3DDevice9* d) : device(d) {}
typedef Mesh Type;
private:
friend class AssetLoader;
Mesh* OnDataLoaded( char* data, uint size )
{
return new Mesh;//...
}
ID3DDevice9* device;
};

class GraphicsManager
{
public:
GraphicsManager(ID3DDevice9* d) : device(d), meshManager(d) {}
MeshManager meshManager;
private:
ID3DDevice9* device;
};[font=courier new,courier,monospace]Mesh* mesh = assetManager.Load( "foo", graphicsManager.meshManager );[/font]

The resource manager is responsible for ensuring there is only one instance of each resource loaded. (one version of grass01.bmp, one version of terrain.obj, etc). It has the responsibility of determining the file location on the target device, and retrieving that file from the storage medium.

etc.

Here is the problem with a mega resource manager.

A single resource manager needs to know about every type of resource in your engine.
It knows about individual textures, and also high-level classes such as models.

That means if I am just a lowly sprite class and I gain access to the resource manager, suddenly I also know about terrain, models, etc. All these things I don’t need to know.


Want to prevent the duplicate loading of textures?
Make a texture manager.

Want to prevent the duplicate loading of models?
Make a model manager.

The model manager, implicitly in need of texture information, can know about the texture manager and request one-time instances of textures.
Each manager only knows about the bare minimum of classes it needs to operate correctly, and thus using these managers in later projects avoids unnecessary knowledge of unrelated classes in projects that want to use those managers.

My sprite class wants to know about textures and textures only. It doesn’t need to link to a mega resource manager that includes information about models and terrain.

Just don’t do it.


L. Spiro