No, I’m not dead. I took a bit of an OGRE break after 0.14 to avoid some serious burnout, but now I’m back. I am, however, doing a spot of contract work in my spare time now for a talented US startup (who shall remain nameless until such time as they want some free publicity ;), so that’s currently got a lot of my attention, although some of the work will benefit Ogre too.
Finally! After some nasty last-minute problems because of some dodgy Direct3D shenanigans on ‘old’ nVidia cards, and subsequently some serious hair-pulling, swearing and late nights, the latest OGRE release is out. Pop over to http://www.ogre3d.org, there are updated precompiled demos as well as the source code, and new builds of the tools. I’m going to lie down for a bit.
I decided to put in a workaround for the older nVidia cards under Direct3D since they don’t seem to be capable of doing infinite projection on that API. I also have to provide alternative vertex programs since the standard ones extrude to infinity which of course leads to dark cap clipping and ugly artefacts. I suppose I could just have made them fall back on software extrusion, but I felt there were enough people with a GF3/4 to justify doing an alternate vertex program.
I had the 0.14 release all zipped up and ready to go, with a nice new shadow demo, then I hear that the GeForce4 Ti can’t seem to handle the infinite camera projection in Direct3D! I get reports of inverted cameras and black screens. Yet it works fine in GL, and D3D9 works fine on all of my cards here (I don’t have a Ti, but I have an FX and 2 pretty diverse ATIs).
I really shouldn’t have spoken so soon. Today (well, yesterday now since it’s 3am) didn’t go anywhere near as well as Monday; I polished off the new shadows section in the manual alright, but then I decided I would try to create myself a normal mapped model for use in the shadow demo. A few hours later I was still tinkering with Melody (nVidia’s normal mapper) and swearing at the 3DS format for not supporting vertex normals.
LOD integration is done, I decided not to implement LOD biasing on the shadow because it just looks too crap at the silhouette boundary. At least if you have LOD enabled on your mesh, both your mesh and its shadow decrease in detail and so scale well. Manual LOD levels work too, my test case was turning a knot into a spaceship at a certain distance, which worked like a charm and the shadows were consistent.
Well, the scissor optimisation is done (this limits the drawing of stencil tris to a screenspace quad representing the attenuation range of the light); I haven’t reallly noticed any frame rate improvement, but perhaps I’m just not hitting my fillrate ceiling yet. Hopefully it will be a useful addition to someone. I’m just finishing up getting LOD (manual and automatically generated) playing nicely with stencil shadows, which works really well. Right now, the shadow volume reduces in detail at the same rate as the mesh itself - personally I’m not convinced that using a lower detail volume on a higher detail mesh will look good because of the mismatch between them - the shadow edge on the caster can look shoddy enough with stencil shadows anyway without it being exaggerated by mismatched geometry.
I found the bug this morning (see what I mean about a good nights sleep?). It was actually nothing to do with my recent changes, there was an existing bug that would only show up if you had a mesh with multiple submeshes, AND you had some reason to be using a separate light cap. The indexes that had been used by this separate light cap were not being added back into the running total, so if you had more than one shadow renderable (as is the case with multiple submeshes with their own geometry) the subsequent ones would screw up.
Just a quick update - infinite far plane projection is implemented in all the render systems now, and coupled with the vertex program extrusion I have found it’s made a big difference to the robustness of the volumes - degenerate cases (objects passing too close to the light, etc) are now a thing of the past I think. The engine automatically enables infinite far plane projection on cameras when you use either of the stencil shadow techniques, and vertex programs are available to extrude them.
I’m currently adding vertex program extrusion into the mix, which is giving me some frame rate improvements with stencil shadows. I also have to sort out infinite far plane projection otherwise in zfail mode the dark caps get culled, since they are being projected to infinity in the vertex program. I have a weird corruption of the volume when using vertex programs on skeletally animated meshes in release mode right now, that’s puzzling me a little since they’re fine in debug mode and non-animated meshes are fine in release mode.