How to write a "material module" for 3D rendering?

Question

At some point I would like to write some type of dynamic material-handling module for my 3D rendering engine. It should be portable (GL, D3D, etc). And when I say "dynamic" I mean a module that is able to load material definitions and data runtime (through my resource management module).

The material module should cope with basic primitives: textures, normal maps, fragment shaders, and so on and so forth.

How do I start? Trial and error is sure to result in two or three totally worthless prototypes, which I would prefer to skip. Could you point me at some good, or even great, design/implementation/tutorial/article that might help me in my quest?

Answer 1

I'd start by looking at the freely available Blender code.

Also, have a look at this book: 3d Computer Graphics

I found it enormously helpful at explaining the fundamentals

Answer 2

Thats a really big topic; architecting an efficient material system is hard to begin with, but add in that you want it to be portable AND dynamic, and it doesn't really get much more complex than that.

Places to look (Google will find all these):

• Game Programming Gems books
• Graphics Programming Gems books
• ShaderX books
• The GameDev-Algorithms mailing list is an excellent resource, also the SWEng-GameDev list
• Look at what other APIs do; for example Ogre3D or Unity.

Advice:

• Look at the D3D10 way of handling state as immutable state blocks; this is good because it suits 3D hardware
• Think of material state and material data as separate things; state is stuff like alpha blending type, while data is things like diffuse color or texture. State is immutable, and the basis for sorting your rendering pass, while data is dynamic and can be set/changed per-rendered object
• I couldn't find any good solutions for shaders. GLSL is great unless you want to support Intel hardware on Windows, where there aren't any GL drivers. HLSL is DirectX only. Cg couldn't be run multithreaded enough for me. If your situation is the same, the only options are to offer specific shader profiles (eg 'HLSL Vertex Shader 3.0') and let the developer cope with the differences, or abstract it all away somehow, which is more work and may be less flexible
• Making it dynamic is just a matter of keeping track of references correctly etc. The hard part is the less obvious cases, like if you change a material that a mesh is being rendered with, it might require a different vertex format, so you will have to update the mesh's vertex buffers