Well, I’m back and catching up, just concentrating on a few bugfixes (I finally caught the animation weird-scaling problem thanks to some nice test data from nephastu) then it’s back into the material work. leedgitar pointed out in the forums that I should allow vertex programs to be used without fragment programs, because some cards only support vertex programs. This makes the design a little more complicated because we won’t be able to assume that a pass is entirely programmable or entirely non-programmable.
Good news, the material-unstable branch where I’ve been working on these changes now builds and renders successfully with the new material classes and the new rendering loop. Right now, it’s still loading the old .material script format into the new classes and just not using the new features like explicit multipass rendering, multiple techniques and vertex / fragment programs. My next job will be to write the parser for the new format so we can start exploiting the new features.
I’m still beavering away, most of Material, Technique, Pass and TextureUnitState are done now, and I’m starting work on the changes to SceneManager and Renderable. I still have a shedload of compile errors because all the rest of the code is using the old Material interfaces, but I’ll get to that soon. My main concern right now is to get everything building again so that I can start testing the routines I’m adding - I wanted to test the Material::compile method mainly (this determines which Techniques in the Material are achieveable with the current hardware, and also splits fixed-function passes into multiple passes if the card has a limited number of texture units.
Things are still progressing, I’ve added the GpuProgramUsage class to provide the link between Pass and it’s vertex and fragment programs; this also performs the cacheing of the program name and named parameters until such time as the program is loaded (important when you’re loading definitions from scripts and you don’t want to hog rendersystem resources until you absolutely need to). I’m beginning to crystallise my thoughts on the impact of these changes on the rendering pipeline; at the moment a Renderable references a Material, and sorting is done on Material.