Those NSA techs know a thing or two about security - you’d kind of hope that was the case I suppose, especially if you’re part of the world’s current dominant superpower (at least for now ;)). They came up with SELinux in response to a need for kernel-level mandatory access controls which were very configurable to many levels of security clearance, and indeed in its entirety it’s a pretty complex policy-driven security system which greatly enhances both the granularity and strength of security policies over and above the typical Directory Access Control (DAC) approach you get with regular Linux filesystems.
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.
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.
Anyone seen the Lost Planet short trailer they’re showing on TV? Here’s the online version if not. Come on. I mean, come on. Now, I’m sure it’s great if you’re one of those people who smokes 50 a day and needs to make money doing voice overs in between cheap slasher films, but to start a AAA game trailer off this way demonstrates an almost fatal concentration of cheese. But that’s only the start.