RE: [Algorithms] General-purpose shadowbuffer implementation.
Brought to you by:
vexxed72
From: Tom F. <tom...@ee...> - 2004-08-27 09:13:36
|
Goodnes - loads of emails off-list, none on-list. Come on people - don't = be shy! Anyway, due to popular demand I will do a wbe page or a post about the implementation details. So I was reading the Trapezoidal Shadow Map paper that everyone was = talking about ages ago. http://www.comp.nus.edu.sg/~tants/tsm.html Yeah, I'm = slow. It's interesting reading - it's basically a smarter version of PSM from = what I can see - selecting a better warping for the shadowmap that minimises texel wastage. They take the camera frustum and draw it in the light's = space (clipping as necessary). Then they approximate that with a trapezoid. = And then they find a 4x4 projection matrix that maps that to the unit = square. And that's your shadowbuffer projection. So by definition it doesn't have the divide-by-zero problems that PSMs = have because all your thinking is done in the light's frustum, and by = definition if something is outside the light's frustum, it's not lit anyway and so can't be shadowed or cast shadows. So that solves that. It's also nice that it's continuous - a small movement of light, camera = or objects doesn't cause a large change in the trapezoidal approximation, = and therefore the mapping always changes smoothly, which solves some of the abrupt popping of most shadowbuffer methods. (actually, objects are irrelevant, unlike PSM, because TSM doesn't consider them at all - just camera frustum and light). (The paper also has some interesting (but orthogonal) comments about = picking a depth epsilon to try to reduce surface acne and peterpanning, and how = a trapezoidal projection makes this a lot worse and how to make it not so = bad by de-projecting the epsilon in the shader. But I'm an ID/priority = fanboy, so I just skimmed that bit) So it's all great for distant lights and shortish view distances. But it seems like there's a pretty glaring hole in the algorithm. If your view = is any decent distance compared to the light, and the light is not a nice narrow-cone spotlight (so you can just clip off the large bits of the = view frustum), then your view frustum in light space is huge. So your = trapezoid approximation doesn't help you much. Also, it doesn't seem to help the duelling frustum case at all that I can see (because I don't believe = there _is_ a way to solve that with a single buffer projected with a simple = 4x4 matrix). However, there's the stuff about the 80/20 mix that I don't fully = understand - maybe that somehow compensates for large far-clip-plane distances. But = who uses a far clip plane that isn't basically infinite these days? The only case I can think of is corridor shooters, and 90% of your lights there = are very close to the view frustum, so again - minimal gain from TSM (in a corridor shooter, apart from the omnidirection-light problem, which is a different kettle of fish altogether, you can pretty easily get away with dumb BB shadowbuffers because the change in texel density is fairly moderate, unlike something like the sun outdoors). So it seems like it's better than PSM for some cases, but doesn't solve = any of the real-world cases (duelling frustums), and as far as I can see, pushing the far clip plane out to sensible distances causes it lots of trouble. I also don't understand the videos - their PSM implementation seems to = be performing terribly - far worse than I'd expect. There's no reason I can = see that it should ever be _worse_ than the relatively dumb BB case. Another (rather more minor) quibble I have is that if one of the Cool Features = about TSM is that the changes in mapping are continuous, so you might get aliasing, but you never get pops, then pick a buffer resoloution that is = low enough to show me the texels not-popping. They've picked one where I = can't actually see any texels, so they could be popping every single frame and you'd never know it. Has anyone actually tried this stuff in a real game? Or has the = experience of PSMs put everyone off wacky projections for life? I know I'm a lot = more wary about investing time in this stuff after that (hey - that's why I'm posting this message :-). TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Tom Forsyth > Sent: 25 August 2004 09:47 > To: gda...@li... > Subject: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 > So a few days ago I finished my StarTopia "patch" that=20 > properly and fairly > robustly implements the stuff I talked about in my GDC 2004=20 > talk (which was > a fairly blatant hack^H^H^H^H proof of concept with a=20 > horrible bug I only > discovered later). >=20 > If you want to actually run it, you need a copy of the game, and then > download both patches from my site (link below). Probably=20 > almost impossible > to find in the shops, but plenty on Ebay and P2Ps and=20 > suchlike (for *ahem* > evaluation purposes, obviously) >=20 > http://www.eelpi.gotdns.org/startopia/startopia.html >=20 > There's some pretty pictures and daft text as well. If anyone=20 > wants an even > slower version with lots of debugging info on the=20 > shadowbuffers, just yell > and I'll see what I can rustle up for you. <snip> |