This morning I discovered that I hadn’t quite finished the cel shading demo; specular parameters were not quite working properly and it took me a long time to figure out what it was - turns out there was a parameter binding bug still outstanding which was the cause of the problems. Unfortunately because I thought it might be my vertex or fragment program, I spent a lot of time tinkering with those, and because I was working in Cg, doing certain things changed the way the assembler was produced which often turned on or off the case under which the parameter bug would show up, so the underlying cause was a slippery customer.
Well, I fixed the programmable-geometry-lagging-behind problem, it was a simple case that the parameters needed rebinding. Doh. Well, I’ve been playing with a cel shading material this evening, and it’s coming along well. I hit all sorts of issues, like a bug in the setting of manual parameters and the fact that unless you turn off mipmapping and clamp the texture coordinates, it_really_ screws up the effect. Anyway, it’s working now, and I’ve uploaded a screenshot to the gallery area on the OGRE site.
I’ve been meaning to revamp my own personal site for a long time, so I finally knuckled down and did it, and in the process I moved my OGRE blog here too. You will have noticed that I syndicated the OGRE news too 😀 I intend to have a crack at solving the vertex program world/view/projection matrix inconsistency with the fixed funtion pipeline tomorrow, what with the web site work and the fact that I’ve been putting really silly hours into the vertex & fragment program framework over the past few weeks encouraged me to take a day off - hopefully when I come back to it tomorrow, my mind will be clear enough that it’s more obvious than it is to me right now.
Gah, sorry for the delay again. I’m so busy coding I keep forgetting to come in here every so often. Well, lots more progress, the new .material parser is done and pretty much tested so I can finally start some serious playing with vertex and pixel programs. The multiple technique fallback approach is working really well, and coupled with Cg and assembler shader support 0.13 is going to be another milestone release; in 0.
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.