Things are a little quiet here, I know - that’s mainly because I can’t post many details of the work I’m doing right now for contractual reasons. What I can say (which you should noticed from CVS) is that the standard terrain manager is now even better than it was - faster and better looking. I’m going to add a few things to my TODO since there are some things that need looking into for Ogre 0.
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.