I'm currently writing the graphics engine for my game and I have a Graphics class that manages directX and the loading of models and textures. The model class I've created holds animations, the mesh, and the skeleton. I'm having a hard time organizing the drawing of my models. My graphics engine is meant to be used as a library in my game. The way I have it set up right now is that the game will ask for a ModelController from graphics for a given model name and this ModelController with contain per-object animation data. My question: What is a good way to organize my draw calls. I can put the draw code into my model class, but then it would need to access the effects through the graphics class for setting textures and animation data. I could put the draw code in graphics for easier access to the shaders, but then it would need to access all the data from the model like texture, mesh, animation, etc. Since I haven't used shaders or effects before, I'm not sure how to organize this to be as robust as I need. Thanks in advance

It sounds like you're at about the same level as me, so don't take this as if I really know what I'm talking about. Shouldn't you use a "renderable" class that points to both model and texture information? Then you can simply set the effect and vertex stream in your draw call.

In my graphics class I have a map of strings and the raw texture buffer.
Same goes for shaders; map of strings and the effect files.

My model class then holds the name of the texture it uses, and the mesh, animation, etc.

The ModelController hold per-object animation data.

So right now there's data in three places that I need to render. So I don't know whether to put my draw call in my graphics class, or in my model class, or in my ModelController class that then calls one of the other two options.

With all this I still need the game to only care about / be able to use: a draw call, changing animation, and updating the animation time.

From my within my game logic I'd have an entity with a ModelController in it. To draw, I could either:

Pass the model controller to the global Graphics class.
Create a draw call in the ModelController that then calls draw in graphics.
Have the graphics class get data from the model.
Have graphics pass the current shader to the model and let it draw itself.

There's all sorts of way I could think of doing this, but I feel like all them will not be very robust.

Sorry if I seem all over the place with this.

Hi,
In OOP (Object Orientated Programming) each object should be responsible for it's own functionality and the object should clearly define it's purpose.

The Graphics class is definitely not a entity/object/game object manager and this should be handled by some world /object /game object manager or scene graph.

a Resource Manager or Content Manager should be in charge of handling the resources that your game uses. It should fully manage every aspect of the resources such as passing it to the relevant Rendering Engine to queue for rendering with a Renderable Object.

The Rendering Engine should be in charge of rendering Renderable Objects which will be content / game objects you can see.

I tend to take this approach when developing game engines.

It also lends itself to further abstraction and drilling down into the low level functionality.
Take for example an IEntity (interface)
an IEntity is a contract for any object in the game.

For an object to exist in your world it needs to have certain properties. a position and width, height and depth. a RenderableEntity which derives from IEntity has other properties such as a Texture and any other metadata associated with an object that game be rendered. This RenderableEntity will keep references (strings) to resources it needs to be rendered and your world manager/scene graph has a list of these Renderable Entities.

Further you have a GameObject that might derive from RenderableEntity that has sounds attached to it and so on.

Each frame you can pass the resource manager to the rendering engine as well as a list of entities /game objects that needs to be rendered and when rendered, each object should request the resources it needs from the Resource Manager.

I hope this helps a bit.

Sounds to me like the modelController should have a draw() function for global graphics to call. The global graphics class has access to the shaders so it sets them then calls draw on a list of your modelControllers, and the modelController should have access to the model class (internal pointer).

That does help, thanks. Of course I have some questions though. It seems like if directX was to be encapsulated, the graphics class would need control over the loading of textures, models, shaders, and rendering. Don't get me wrong though, I can see how a resource manager would be incredibly useful for reference counting, easy cleanup, etc.

But as far as the game logic is concerned. As an example, lets say there are entities that can have a model component. This would contain strings for which model and texture it uses, as well as animation data ( could be factored out ). The raw mesh, animation keyframes, and textures could all be in a resource manager.
First thing is: How does the game logic draw this object? Pass the model component to a rendering class? Or a scene graph class can manage the list of these model components in order to better sort them. Then the draw call could be in the scene graph class that passes each of its items to the rendering class.

I'm starting to see how this should work though. My only problem would be coordinating the use of the resource manager from so many different sub systems. I can imagine hard coding a list of every object type I'd ever use into it along with the code to load them.

Are there any good online resources for building a graphics engine? I'd like to know a good way to set up scenes, renderer, etc. like Armadon described.

Gamedev.net should host a UML repository.
This question is a frequent one.

Would be great to look at, comment on, and use other people's ideas from UML. I'd contribute mine.

There is only so much you can get across by typing textual descriptions of how objects work together.