Here's what a hard-coded version of the compiled material asset file would look like:float* b0data = { 0.8f, 0.5f, 0.5f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f };
CBuffer buffers[] = { { 0, 32, b0data } };
Material myMaterial = { "myMaterial", "myShader", 1, buffers };Except instead of hard-coding them, you'd load that data from a file (and a tool would compile the earlier text files into these binary files).

For special passes such as shadows or "fancy shader pass " I have a callback interface passed in a structure I call "RenderContext" ..if the callback is null the mesh is using its material to draw itself, if the callback isnt null it calls "renderMesh(this);" on the callback Interface to request a thrid party logic render strategy to handle the state setup.

Here's what a hard-coded version of the compiled material asset file would look like:float* b0data = { 0.8f, 0.5f, 0.5f, 1.0f, 1.0f, 1.0f, 1.0f, 1.0f };
CBuffer buffers[] = { { 0, 32, b0data } };
Material myMaterial = { "myMaterial", "myShader", 1, buffers };
[/quote]
So creating the float* b0data like in the above requires knowledge of how the cbuffer is laid out. So this means if someone swapped two parameters in a cbuffer it would break the material loading code. Like if you are reading
diffuse = { 0.8, 0.5, 0.5 }from a [Material] file, then you need to know where that element is in the cbuffer. Or do you always match names--so the [Material] element name is the same name as the constant buffer element name so that you can match them up?

We also make a map of parameter names -> offsets in the constant buffer, so that we can set the values of dynamic properties.
[/quote]

So this is similar to the effects framework's "get variable by name"? Like if you wanted to update the world-view-projection matrix you would do something like:

UINT offset = myMap["worldViewProj"];
// Update cbuffer value?

So with this, how do you handle special rendering passes?

For example, lets say in the main rendering pass you use some fancy shader Shader="Fancy" and ... in the water reflection pass, you want to use a basic shader Shader="Basic" because the fancy effects will go unnoticed in the distorted reflection.

The data chunk allocated for the Fancy material properties is different from the cbuffer format the Basic shader wants. So how does the engine handle this? Does it map as many properties as possible to a Basic material at runtime, or does each drawable item store multiple materials (one for each possible pass the engine supports?)

Also, for textures, do you just keep an array of texture/slot pairs in your material?[/quote]Pretty much, yep.
[font="arial, verdana, tahoma, sans-serif"]

So creating the float* b0data like in the above requires knowledge of how the cbuffer is laid out. So this means if someone swapped two parameters in a cbuffer it would break the material loading code. Like if you are reading
diffuse = { 0.8, 0.5, 0.5 }from a [Material] file, then you need to know where that element is in the cbuffer. Or do you always match names--so the [Material] element name is the same name as the constant buffer element name so that you can match them up?

The "[Material]" file is a text file that uses names. This file is then compiled into a binary file that uses register numbers (e.g. above, FancyParameters becomes "b0", while BasicParameters becomes "b1"[/font][font="arial, verdana, tahoma, sans-serif"]) and offsets. When compiling the material files, the shader is inspected to resolve names and determine buffer sizes (e.g. diffuse is offset 0, ambient is offset 1, etc...)[/font]
[font="arial, verdana, tahoma, sans-serif"]The material file is dependent on the shader file, so if someone modifies the shader file, the build system will automatically re-build the binary material files using that shader.[/font]

Sorry for more questions. I am trying to work out an example to convert my system to this generic material approach but am finding a problem. The material text file doesn't specify every map. For example, it doesn't mention the shadow map. But the corresponding shader will have:

Texture2D ShadowMapNameWhatever;

But when I reflect on the shader, all I will know is the name, type, and slot #. But this is not enough to tell me that it expects a shadow map, so I have no idea what to bind for this slot. Do you use a semantic system for these kind of parameters?

Texture2D ShadowMapNameWhatever : SHADOWMAP;

There are other parameters like this too. For example, shadow cascade interval positions, and shadow cascade light space transforms. The material doesn't care about these, but the shader does.

Granted, these are scene level parameters (not per object), so I guess I could make a special perFrame cbuffer, and handle that specially.