I spent this evening getting the nvparse code _mental_ has been working on compiling under VC6 and VC7; basically this is to provide support for ps_1_x equivalents under GL for nVidia cards, since GL’s first standard was equivalent to ps_2_0 which cards like the GeForce3 and GeForce4 do not support. nvparse produces the effect of using NV_register_combiners and NV_texture_shader, and the best thing is that you can generate it from Cg.
I’ve been working on the dot3bump demo among other things (like wrapping pressies ;), and it’s looking nice. I’ve decided to implement a number of versions of the effect, since the variety of cards it can run on means that there are a few different ways of achieving it. The one prerequisite is vertex program support - this is required to calculate the object-space light parameters. However, here are the variants, in ascending order of complexity:
We’ve been on a bit of a bug fixing spree, between myself and _mental_ we’ve sorted out the problems with arbfp1 and 1D textures, and the cel shader is now working great on both render systems. I was lucky enough to be the happy recipient of a GeForce FX 5900 Ultra today, a beast of a card that weighs a ton and sounds like a nuclear power station starting up, but it can sure pump out some juice.
bad_camel, the lucky owner of a GeForceFX and a linux user, raised an issue late last night about the cel shader not looking right on his machine. Unfortunately, because my dev boxes don’t have ARB_fragment_program capable cards (because arbfp1 is equivalent to ps_2_0, and my cards only support ps_1_x) I haven’t been able to test the cel shader in GL yet. Luckily my wife’s machine has an ATI 9500 Pro in it, kindly donated by ATI a while back so I used that for a bit of testing, and it turns out that GL does not like you sampling a 2D texture with a 1D texture coordinate.
As I worked through the dot3bump demo, it occurred to me that it currently wasn’t that easy to write a programmable material pass which dealt with an arbitrary number of lights. We do automatically ‘black out’ light information which is beyond the range of the number of lights currently close to the object being rendered (so that if your programs assumed 2 lights and there was only one in range, the second one would be black), but this isn’t ideal as a general case.
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.