Original Post
Im looking at my code, and Im thinking that a lot of things know about stuff they dont need to know about, and Im wondering how I can improve upon it, or if its not really a problem. Id like your opinions. At the moment I hava a Renderer Object, whos job it is to carry out all debug drawing tasks, such as DrawLine, DrawBox, DrawSphere etc etc. My game is a bit bare bones at the moment, and I only have:- -Terrain rendering -Ocean rendering -Skybox rendering -Static Mesh rendering (static meshes loaded as models from file) -Dynamic Mesh rendering (dynmaic meshes loaded as skinned models from file) And all of the above have their own HLSL file, so each has its own effect object for rendering, and knows how to create themselves from scratch. So all objects know how to render themselves, which means they know about, and how to use:- - How to load a HLSL file, (effect object) - How to load textures - How to read files - Shader Parameters - etc etc The exception to the above is Static and dynamic meshes, they dont know how to load themselves from file, and dont know how to render themselves. They purely contain only the information they NEED to know about. Such as their materials, textures and vertex/index buffers. But they dont know how to load any of it. This is achieved by having a meshmanager that loads static and dynamic files, and returns them as objects. delegating all the file laoding, such as textures, materials and the mesh file format to the meshmanager. The same applies for the renderer, static and dynamic meshes dont know how to render themselves or anything about shaders what so ever, but they can queue themselves by calling an AddToQueue from the renderer object. Where the renderer doesnt know how to render them either, but has 2 objects, a StaticMeshRenderer and a DynamicMeshRenderer. When addToQueue is called, the renderer delegates the call to one of these, where the object is added to their queue. Once the general Render() is called on renderer, it then in turn calls StaticMeshRenderer.Render() and DynamicMeshRenderer().Render(), where they each render their lists in one go. So to sum it up - Static and Dynamic meshes are loaded using the meshmanager, which delegates the call to staticLoader and dynamicLoader classes - Static and Dynamic meshes are rendered using the renderer, which delegates the call to staticRenderer and dynamicRenderer classes Now, getting back to the question. The other objects (Terrain, Ocean, skybox) dont do any of this, and do everything in one class. Which as I said before, means that an object of each type knows about a lot of stuff it doesnt need to. How do I go about resolving this? Should I follow the same approach and have :- Terrain - Object, contains only terrain paramters and general functions TerrainLoader - Knows how to load a terrain from file, and its dependancies, such as textures and materials TerrainRenderer - Encapsulates the Effect, so shader paramters and techniques. Held by the Renderer, and gets called if a Terrain is in the Render Queue. and the same for the other 2? Im thinking about having the Renderer, work something like this
void Renderer::AddToQueue(Const Actor* pActor)
{
// ...perform any culling
//...then
switch( pActor->GetType() )
{
case STATIC_MESH:
m_pStaticMeshRenderer->AddToQueue( pActor );
break;
case DYNAMIC_MESH:
m_pDynamicMeshRenderer->AddToQueue( pActor );
break;
case SKYBOX:
m_pSkyboxRenderer->AddToQueue( pActor );
break;
case TERRAIN:
m_pTerrainRenderer->AddToQueue( pActor );
break;
case OCEAN:
m_pOceanRenderer->AddToQueue( pActor );
break;
}
}
void Renderer::Render()
{
//render all objects
// ... order dependant? (transparency?)
}
