This sample uses the following keyboard and gamepad controls.

This rendering technique does not use instancing at all, and it is not a smart approach or something that you should copy in your own code! This is included only for comparison purposes, so you can see the performance gain achieved by the following techniques.

This technique just loops over all the active instances, calling ModelMesh.Draw (which sets all the rendering state and then calls DrawIndexedPrimitives) once for each copy of the model.

In psuedocode, this technique is implemented as follows:

        foreach (Matrix instance in instances)
        {
        SetVertexBuffer();
        SetIndexBuffer();
        SetVertexDeclaration();

        SetWorldTransform(instance);

        foreach (EffectPass pass in effect.CurrentTechnique.Passes)
        {
        pass.Apply();

        DrawIndexedPrimitives();
        }
        }
      

Note the repetitiveness of setting the same state and calling the same effect methods every time around the loop.

This is still not a proper instancing technique. It just rearranges the C# drawing code to hoist repeated operations out of the inner loop. Instead of looping over all the instances and repeating the exact same draw code for each one, the DrawModelNoInstancing method takes an array of instance transform matrices, so it can draw many copies of the same model all in one go, doing the absolute minimum of repeated work per copy.

In psuedocode, the algorithm is:

        SetVertexBuffer();
        SetIndexBuffer();
        SetVertexDeclaration();

        foreach (EffectPass pass in effect.CurrentTechnique.Passes)
        {
        foreach (Matrix instance in instances)
        {
        SetWorldTransform(instance);
        pass.Apply();

        DrawIndexedPrimitives();
        }
        }
      

This technique performs the instancing work entirely on the GPU. It has extremely low CPU load regardless of how many instances you are drawing. For optimal performance, this requires a HiDef game using shader model 3.0 vertex and pixel shaders.

In conventional non-indexed rendering, every set of three indices forms a triangle. The indices are used to look up into a vertex buffer, which provides data such as position, normal, and texture coordinates. The following diagram shows the data layout for a simple model that consists of just one rectangle (two triangles, specified by six indices, and four vertices).

Hardware instancing does not require any changes to that data layout, but it adds a new source of information. This is a second vertex buffer that holds transform matrices, one per instance. This second vertex buffer should be as large as the maximum number of instances you are planning to draw in a single call. It does not need to be the same size as your main vertex buffer. In each frame you call SetData to update this second vertex buffer with the latest transform matrices for each instance.

To pass both vertex buffers into your shader, you must specify a VertexDeclaration that includes this additional transform matrix data. Unfortunately, there is no VertexElementFormat for matrix data, so instead we must split the matrix up into four channels of type Vector4.

We must now set both vertex buffers onto the GraphicsDevice (the first holding our actual geometry data, and the second holding the instance transform matrices), and then draw by using the DrawInstancedPrimitives API method, as opposed to the usual DrawIndexedPrimitives. This is handled by the DrawModelHardwareInstancing method in this sample.

Finally, we must add the per instance transform matrix as an input parameter to our vertex shader. See the HardwareInstancingVertexShader function in InstancedModel.fx for an example of how to do this.

Once we have completed these setup operations, the GPU handles everything else for us. We can just call DrawInstancedPrimitives, and the GPU draws the specified number of copies of our model data. It reuses the same index buffer for each copy. It uses these indices to look up into the same geometry vertex buffer. It also keeps track of which instance it is currently drawing, automatically looking up the transform matrix from the appropriate part of our second vertex buffer and passing this into our vertex shader along with the position, normal, and so on.

Using the same two triangles example shown in the previous diagram, this shows the data flow when drawing two copies of the model using hardware instancing:

Data used for the first instance is shown in blue, and the second instance is green. Grey represents data that is shared between both instances. Note how triangles 0/2 and 1/3 share the same indices, which reference the same information from vertex buffer stream 0, but how each instance pulls a different transform matrix from vertex buffer stream 1.