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.
I got a little behind with this log since this was my first week back at work, but I’ve been beavering away anyway. Both vertex and fragment programs are now working, and D3D and GL are functional thanks to temas finishing the GL stuff, although since my card does not support ARB_fragment_program I can’t test fragment programs in GL just yet (although I should be getting a newer card soon).
Things have really gone well this weekend, all the stuff I’ve been working on is falling into place, and for the most part, it’s working! I’ve implemented the automatic parameter bindings, like getting the system to automatically keep the worldView matrix or object space light position up to date in a program parameter, and the technique fallbacks seem to be working ok. I also completely overhauled the light management today; previously there could only be a fixed number of lights in the entire scene, up to the limit that the API supported, which was very limiting.
The split of vertex programs and fragment programs is done, they are now totally independent. I also fixed the remaining problems with the BSP demo (caused by some Q3A shader scripts including duplicate names, the swines), and completed the optimisation of the new Pass structure in the render queues that I mentioned before I went on holiday. I had a few problems with the cube mapping on the water demo again, there are some odd dependencies when using cube mapping in conjunction with non-identity world matrices that means you have to reissue the texgen / texmatrix calls after updating the world/view matrices to avoid some very odd artefacts, like the cubemap spinning around with the ogre head, or the reflection flipping over depending whether the ogrehead is in view or not.
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.