I don’t really have time for this, but I need to get to know Redhat Enterprise Linux a little since the machine that will eventually be our new server is running on it. In recent years I’ve gotten pretty comfortable with Debian which is great for servers IMO - its racy teen offspring Ubuntu might be getting all the attention lately on the desktop, but Debian is a solid workhorse with a sensible stability / security policy and lots of really sensible and useful tools.
It’s coming. Eihort, that is. I’ve been working on pretty much nothing else since just before Christmas and the items on the TODO are, one by one, getting ticked off. Annoying gotchas with the texture shadow enhancements delayed me for a bit but the going is smoother now. I have a hard deadline of the end of the week to finish the majority of the new code. That’s because for the 3-4 weeks after that I have commitments to third parties and thus any OGRE work will have to be done around that.
Sorry for the downtime of the site, and any bounced mails you might have had from my personal domain over the weekend. This domain’s contact email, unlike all the other domains I administer, was set to the old webmail account I used when I set it up, which I don’t check very often, and so I missed the renewal reminders. Dumb mistake, especially since this happened a few years back too and I thought I’d altered it, but obviously not.
As you probably already know, I live on a tiny island just off the French coast. Many of you might not realise just how small it is - about 78 square kilometers in total and about 62,000 people. The upside is the quality of life is a lot better than many places, one of the downsides is that a small population and a significant economic skew towards financial services means there aren’t that many software development people about.
I spent yesterday sorting out all the dependencies for Eihort - that meant updating to the latest versions of almost everything. For the core that meant rebuilding FreeType (v2.3.0), FreeImage (CVS - I submitted a patch because they had a small scoping bug in VC8), and Zziplib (0.13.47). I’m building all these with VC8 SP1 now, since I intend to supply binaries for Eihort with the SP installed. For the recent Dagon stable release I used my laptop which doesn’t have SP1 on it, to make it easier to update for those who are sans-SP1, but with Eihort it’ll be full-bore only.
I finally got around to giving the Athene model a combined normal mapping and depth-shadowmapping shader - you might have noticed I’d avoided doing any close-ups of it in previous shots, it’s because it I hadn’t gotten around to it yet and Athene was still using the old normal mapping shader. As you can see she self-shadows nicely now and the shadow detail nicely follows the normal mapped detail like the folds in her cloak.
Wow, I had a really interesting mail today. Here’s how it starts: Subject: PLEASE READ this is not an advertisement or a joke! Ok, that alone earned you a few points on my spam filter’s scoring system. But, then it gets more interesting: Dear Steve, AKA sinbad, My name is [omitted in case name was stolen from elsewhere]. That name is actually an alias (mine I mean). I must use thise alias because of what I am about to tell you.
Preprocessor macros are very useful for re-using the same shader source code in small variant ways. For example (snippet from my depth shadowmap code): #if PCF // use depths from prev, calculate diff depths += depthAdjust.xxxx; float final = (finalCenterDepth shadowUV.z) ? 1.0f : 0.0f; final += (depths.x shadowUV.z) ? 1.0f : 0.0f; final += (depths.y shadowUV.z) ? 1.0f : 0.0f; final += (depths.z shadowUV.z) ? 1.
Just a quick follow-up, I mused in my earlier post today that the fact that D3D9 inexplicably gives you an integer format texture (D3DFMT_G16R16) when you ask for a 16-bit floating point texture (D3DFMT_R16F), was the root of my precision problems in depth shadowmapping, and indeed that was the case. I also found another contributing error (a slipup in the clipspace-to-texturespace matrix) but D3D’s odd behaviour had a significant influence.
Ok, so I’ve finally managed to get back to doing more testing on the ‘integrated’ texture shadow techniques this week (formerly known as ‘custom sequence’ texture shadows but I thought that was an ambiguous term). For those who haven’t been following this, ‘integrated’ shadows in Ogre are those where the shadowing calculation is done directly in the primary material of the receiver, and not done as additional passes. The easiest way to use Ogre’s texture shadows (and the only way previously) is to use the non-integrated methods, which basically do one of two things - re-render the receivers in the scene with a modulative pass per light, or break apart your receiver materials into ambient, per-light and decal (albedo) render passes in order to build shadow-masked lighting up additively.