Hmm, another week gone by already. But, I haven’t been idle - the Cg plugin is now working nicely, it’s now startlingly easy to use both assembler and Cg vertex and fragment programs. The Cg plugin compiles .cg programs on demand and spits out the appropriate assembler programs to be used by the rendersystems. The plugin negotiates with the rendersystem to determine the appropriate type of assembler to output based on the syntaxes it supports, and when defining a program you give it a list of profiles you know it will compile under. If none of the profiles you list is available in the renderer and / or the current card, the technique is marked as unsupported and the next fallback technique will be used. As well as outputting assembler, the Cg plugin reads the program definition and determines the mapping between named parameters in Cg and the constant registers in the assembler, automatically providing a mapping so you can use names instead of indexes to set your parameters. It’s all rather neat I think 😀We use none of the rendersystem-specific aspects of Cg, we literally just use the compiler / parser; that way Cg support can be a plugin and we don’t have to overcomplicate our render state management with the DX or GL Cg runtime messing with it.
I’ve updated the the documentation for the .material script format to reflect the (significant) changes in order to give myself a solid specification to work from when writing the parser. I’ve also added a new script type - .program. This will contain the definitions of the vertex and fragment programs that can be shared between many passes of many materials. I separated it out from .material because it became too awkward to deal with ordering issues between declaration and referencing programs, and also made the demarkations of what MaterialSerializer did and did not write when exporting; .program scripts will be parsed earlier than .material scripts and their contents will not be exported by MaterialSerializer.
I’m just starting to add LOD support to materials, each technique can be assigned to a LOD (default 0), with the best technique in each LOD being used at the appropriate distance.