I come from an openGL background and I'm used to ordering the rendering of my objects to limit the number of state changes.  Now that I am working with XNA and C# I've been trying to keep my code as much object oriented as possible, which seems to differ greatly from the state machine approach of openGL. 

Currently I've been deriving my game objects from the DrawnGameComponents, overriding the Draw method and then adding that to the list of components under the game class and letting it handle all the drawing from there.  Although this is really nice for keeping my code clean and very object oriented, I can't help but think how inefficient the rendering must be.

Does XNA/D3D handle a lot of this sorting for me and I am attempting to go too low level?  If not, what can I do to optimize the draw calls?  Any tips / links are appreciated. 

 
Thanks ahead of time!
 

It sounds like you might be implementing individual game objects (such as sprites or models) as GameComponents.  If that's the case, that is too low level.  The consensus seems to be that it's best to use GameComponents for managing collections of related objects.

You may want to check out this thread, as well as search to read some of the many other threads on the use of GameComponents.

Tom

I read the posts about the proper way to use the GameComonents, and I can agree with that approach.  That being said I'm still not sure how to handle rendering of many objects that may or may not share properties in their effects.  I'm finding it really hard to pull myself away from the state machine concept when I think about properties of rendered objects.  For example, if I had a few objects that used the same shader but the shader properties might change, how could I change the properties without changing the shader during rendering?  Does XNA do a lot of this for me if If notices the next effect shares the same shader as the last effect rendered?
 

I'm afraid I'm not familiar with OpenGL or how it works with shaders, so hopefully someone who is can chime in with some advice that may help you with your transition from that to XNA.

However, as far as XNA is concerned, it doesn't keep any state data for shaders as far as I know.  Each frame you have to set the properties for the shader effects you have assigned to each of your models.  So if you have a model, you'll need something like:

foreach (ModelMesh mesh in model.Meshes)
{
    foreach (Effect effect in mesh.Effects)
    {
        Matrix world = transforms[mesh.ParentBone.Index] * rotation;

        effect.Parameters["World"].SetValue(world);
        effect.Parameters["View"].SetValue(view);
        effect.Parameters["Projection"].SetValue(projection);
    }

     mesh.Draw();
}

Where World, View, and Projection are parameters for the shader effect.  Does that answer your question?

Tom

The XNA Framework (the runtime graphics part) is effectively a managed wrapper around DirectX. It simplifies the setup and running of a game but is essentially just a wrapper. DirectX and OpenGL are basically similar interfaces to the graphics hardware. So your understanding of OpenGL is still very useful. The change from the procedural OpenGL API to the vaguely OO XNA/DirectX API means very little; don't be fooled into thinking that you're suddenly working at some higher level where many hidden things are happening under the hood.

If you want to reduce render state changes then the same techniques you would have used with OpenGL apply. The XNA Framework does not sort/defer your rendering in order to optimize state changes. Generally, to optimize state changes requires some 'scene' level knowledge of what you are rendering and the XNA Framework operates at a lower level than that.

In the case of your specific example the pseudo code to render objects sorted by shader would be very similar in XNA or OpenGL:

Set shader #1
Set object #1 params
Render object #1
Set object #2 params
Render object #2
Set shader #2
Set object #3 params
Render object #3

Cheers,
Leaf.

Game Programming Gems 6 has an excellent article about designing next generation 3d engine material systems.  Basically, you have a MetaMaterial, which is an effect.  This MetaMaterial has a set of default parameters.  Objects are assigned a material, which is an instance of a MetaMaterial.  Materials have different options than the base MetaMaterial, namely different parameters.  When an object is going to render, it submits its geometry and material to the scene graph.  After everything is submitted, it sorts all material into categories based on MetaMaterial, this helps minimize state changes.

For example, you might have a Skin MetaMaterial, and Skin:light and a Skin:dark material, where each material instance changes a color parameter on the base MetaMaterial.
 

Thank you for all the replies and help.  I will setup my scenegraphs similar to how I would in openGL where I sort meshes by their base materials and then in trees of shader parameter changes. 

Is it good practice to make each scene graph (one for each feature / layer / viewport) a component of the game class ordered appropriately?