I have couple more questions that sprung to mind while I was thinking of how to link materials with the effect/cbuffer system.

1) If the CBuffer structures are so minimal how do you determine what buffer register to bind them to when creating the bind commands for the state groups in your materials, etc? (assuming you only store the buffer register index in the CBufferInfo class and not in your CBuffer classes)

One option I thought was that the position in the vector of cbuffers would be the register index but then realised that wouldn't work because the vector contains buffers from all shaders types and so you could have vector items 0,1 = {vs_b0, vs_b1} and items 2,3 = {ps_b0, gs_b0}.

2) When dealing with DX11, at what point do you create the actual buffer resources and how do you store/link them with the emulated cbuffer structure?

As for designing a material format, I was thinking each material would get a copy of all the default cbuffers from the effect/shader it holds and then use the material specification to determine what cbuffer constants to lookup and change. Is this essentially what you do in your system?

1) If the CBuffer structures are so minimal how do you determine what buffer register to bind them to when creating the bind commands for the state groups in your materials, etc? (assuming you only store the buffer register index in the CBufferInfo class and not in your CBuffer classes)

I'd create the buffers and their binding commands at the same time, where you've got the shader reflection information available. The command has a link to the buffer instance, but neither retains a link to the reflection info from which they were created.

2) When dealing with DX11, at what point do you create the actual buffer resources and how do you store/link them with the emulated cbuffer structure?[/quote]When loading a cbuffer from disk, or when creating one programmatically, I'd make the DX11 resource immediately. There may not even be a need to keep around an 'emulated copy' of the cbuffer's contents, especially if it's a cbuffer that will not ever be modified.

As for designing a material format, I was thinking each material would get a copy of all the default cbuffers from the effect/shader it holds and then use the material specification to determine what cbuffer constants to lookup and change. Is this essentially what you do in your system?[/quote]Yeah, but I don't instantiate all of the default cbuffers -- only the ones that have at least one value set by the material are instantiated (and have binding commands inserted into the material's state-group).
N.B. not every cbuffer is a material cbuffer -- e.g. you don't want your materials binding your camera cbuffer, especially if your material state-group has a higher priority than your camera state-group!