Dynamically Choosing Vertex Format

Hi All,

So this questions is more of a C++ architecture question but it's directly related to DirectX11.

In all the tutorials, they have you define a struct for your vertex format along the lines of:



struct VertexFormat {
XMFLOAT3 position;
XMFLOAT3 color;
};




And then when you create your Vertex Buffer you need to use that struct to fill out the ByteWidth of the D3D11_BUFFER_DESC and create an array of VertexFormat objects like so:


D3D11_BUFFER_DESC vertexBufferDesc;
vertexBufferDesc.ByteWidth = sizeof(VertexFormat);




VertexFormat* vertices = new VertexFormat[numVertices];





So this is all good and fine when following a tutorial, but eventually we'll want to make something a bit more modular and dynamic.

Depending on the Material used, VertexBuffers are going to use a different VertexFormat struct. Some will have normals, uv's for various textures etc.


My question is really how to make a generic function that does the work but will operate on a variety of VertexFormat objects. These VertexFormat objects wouldn't be known until runtime so I don't think templates would work.

If I were to write this in a dynamic language I would do something like this: (C++ syntax still)


//Note this function for illustration purposes only. I know it doesn't actually do anything.
void AbstractMaterial::CreateVertexBuffer() {
D3D11_BUFFER_DESC vertexBufferDesc;
vertexBufferDesc.BindFlags = D3D11_BIND_VERTEX_BUFFER];
vertexBufferDesc.ByteWidth = sizeof(myDerivedVertexFormat); //TODO: myDerivedVertexFormat is a variable that contains the TYPE of VertexFormat struct


vertices = new myDerivedVertexFormat[numVertices]; //Fill in vertices from raw data...

D3D11_SUBRESOURCE_DATA vertexBufferData;
vertexBufferData.pSysMem = vertices;
vertexBufferData.SysMemPitch = 0;
vertexBufferData.SysMemSlicePitch = 0;

//Finish creating vertex buffer }




Seems to me like the limitation of Run Time Type Checking in C++ will prevent this from happening. The only thing I can really think of is manually reimplementing the function in every derived material... but come on, that sounds terrible!

There must be a better way?
Is there?

Thanks!