The new material framework for 0.13 is approaching completion; this version does not simply introduce the binding of vertex and fragment programs to the pipeline, it adds a whole new level of flexibility to the use of materials in OGRE. People have been asking for ‘shader’ support for some time, but we’ve waited until we had enough time to do it properly, to give people a fully rounded framework in which to use them rather than just tacking them on. We hope you approve..
Materials can contain multiple ‘techniques’ which are methods of achieving the effect you are looking for (this has a direct correlation with techniques in D3D .fx and CgFx, but is platform and API-independent). The engine automatically works out the best technique available for the hardware you are running on, taking into account the number of texture units available, the versions of vertex and fragment programs used, and (soon) a LOD bias which allows materials to degrade gracefully in the distance to save processing power.
Each technique is made up of potentially multiple passes; passes without fragment programs assigned can be automatically split into multiple passes by the engine if the card does not have enough texture units, much like the multipass fallback present in the 0.12 materials. Passes with fragment programs cannot be split because the program relies on the texture unit assignments, so lack of texture units here will cause this technique to be tagged as ‘unsupported’ by the material compilation, and the next technique will be considered instead.
Both low-level and high-level vertex and fragment program languages will be supported in each pass, and you can have either a vertex program or a frgament program, or both, per pass. In 0.13 all of the native assembler languages will be supported (vs_1_1, ps_2_x, ARB_fragment_program etc) along with Cg (and hence D3D9 HLSL, which is the same syntax) as an optional plugin. This gives you the flexibility to use a single high-level program if you want, or you can precompile your programs, or write assembler directly if you want more control (you’d be advised to provide alternate techniques for each 3D API if you want cross-compatibility though). If you use low level languages only, your application is not dependent on the Cg runtime, because the OGRE core does not rely on it.
The engine utilises deferred loading techniques to ensure that only programs which are used and supported are compiled and loaded. Parameters to the programs can be defined manually (using constant indexes for low-level programs or named parameters for high-level programs), or they can be linked to important engine state like the current world matrix, or more complex derived values like the object space light position of the closest ‘n’ lights. All of these settings will of course be definable using our simple but powerful .material scripts.
There is more work to do yet, and of course much testing, but the main parts of the new architecture are already working; those wishing to get a sneak preview can play with the cvs version for more details.