Sods law says “If you have plans for something, forget about it.”, or something like that. I’ve been fixing up a few things in the last couple of days, mostly issues with using multiple render targets; there were some problems with overlay sizes and frame rate stats when using more than one. I wanted to do this because the demo I have planned will use 3 targets; 2 render textures and the main view.
Happy new year to everyone! I’ve pretty much finished all the texture flipping business, _mental_ is working on DDS /volume texture / compressed texture support for GL now and in the meantime I’ve been fixing a few miscellaneous bugs, like a problem with a boundary condition on the mesh LOD generation and some issues with overlay sizing when using multiple render targets (like in the render to texture demo). I’m also propagating all the bugfixes in the pending 0.
Well, xmas is over and I actually had a little bit of a break from OGRE for a change. Nevertheless, I did sneak back to the keyboard at least a few times over the last few days, and the result of that has been that I got the nvparse code working, which is good news for GL users owning GF3’s and GF4’s, and I also added an implementation of DirectX9 HLSL, really just for the hell of it.
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.