Thread: RE: [Algorithms] General-purpose shadowbuffer implementation.
Brought to you by:
vexxed72
From: <c.s...@ph...> - 2004-08-27 09:37:08
|
One problem I see with any projection algo, be it PSM or trapezoidal, is = that it does not help you if your view direction aligns with the light = direction. You can't have a higher resolution in the center of your = shadowmap selectively for the nearby objects :-) So, you are standing on a balcony, sun behind, and both the balcony = fence and the street below you need a decent shadow map resolution. What I did to solve this was I would call it "segmented" shadowmaps, = where different shadow maps are used for different regions between = z-planes (with texkill planes, or actually alpha test, since I did it on = FF hardware). So the balcony would get a higher resolution segment than the street. Some images can be seen at the bottom of this page,=20 http://www.thetenthplanet.de/bounce but will also try to upload some examples where the segment boundaries = are apparent.=20 I know I am guilty about not publicly writing anything about this before = :-) -chris -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of Tom = Forsyth Sent: Friday, August 27, 2004 11:13 AM To: gda...@li... Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. |
From: Gary K. <GK...@nv...> - 2004-08-27 18:03:00
|
I've nearly finished implementing a minor variation on TSMs in my PSM = demo (I still need to implement a dynamically-computed focus region; = however, I've been able to manually adapt the focus region to generate = nice shadows everywhere I've tried). Like LSPSMs, the only degeneracy is an easily-handled uninteresting case = (squeezing >N% of the frustum below the "N% line"), which makes nicer = than PSMs in that regard. A huge view frustum isn't really a problem for TSMs; no more so than = uniform shadow maps, anyway. The worst-case behavior for TSMs is when = the view frustum(/trapezoid) is fat; in this case, the best behavior is = to fall back toward uniform shadow maps (set the 80/20 split to 80/20). As far as the PSM quality in the video; it's been my experience that = PSMs (especially Stamminger & Drettakis PSMs, as opposed to LSPSMs or = Kozlov PSMs) can get into a number of situations where they look = significantly worse than uniform shadow maps; particularly in large = scenes with rough bounding box approximations. In these cases, the = post-projective view box could have significant wastage (unnecessary = bits of the scene), and when the light is close to the view-box the = large FoV causes quite a bit of compression even close to the viewer. = This was the primary reason why my demo forces a minimum distance = between the infinity plane and the view-box. -----Original Message----- From: gda...@li... [mailto:gda...@li...]On Behalf Of Tom Forsyth Sent: Friday, August 27, 2004 2:13 AM To: gda...@li... Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. 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> ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Jonathan B. <jo...@nu...> - 2004-08-27 19:00:22
|
This is exactly the problem with PSMs and TSMs: Depending on where you=20 point the camera, they are often no better than standard shadow maps. =20 So if I have to deal with making my scene look good in this case, and I=20 succeed, then I might as well throw away all the PSM and TSM stuff. In fact it often makes the scene look a lot uglier, as the resolution=20 jitters around while the camera rotates. It just doesn't feel solid. I guess PSM and TSM might have good uses in batch rendering where you=20 are splatting zillions of shadow maps per frame at real high resolution=20 and you can do this kind of case by case thing and it doesn't matter. =20 But I just don't see them as being useful for a real-time game that=20 wants high-quality shadows, not any time soon, anyway. (Though if there's a demo out there that uses these kind of systems that=20 solves the real-world problems that happen in a game, I'd be eager to=20 see it. And I'd buy the author a beer -- I sure as hell could never=20 make PSM or TSM look good, and I tried a lot.) -Jonathan. Gary King wrote: >I've nearly finished implementing a minor variation on TSMs in my PSM de= mo (I still need to implement a dynamically-computed focus region; howeve= r, I've been able to manually adapt the focus region to generate nice sha= dows everywhere I've tried). > >Like LSPSMs, the only degeneracy is an easily-handled uninteresting case= (squeezing >N% of the frustum below the "N% line"), which makes nicer th= an PSMs in that regard. > >A huge view frustum isn't really a problem for TSMs; no more so than uni= form shadow maps, anyway. The worst-case behavior for TSMs is when the v= iew frustum(/trapezoid) is fat; in this case, the best behavior is to fal= l back toward uniform shadow maps (set the 80/20 split to 80/20). > >As far as the PSM quality in the video; it's been my experience that PSM= s (especially Stamminger & Drettakis PSMs, as opposed to LSPSMs or Kozlov= PSMs) can get into a number of situations where they look significantly = worse than uniform shadow maps; particularly in large scenes with rough b= ounding box approximations. In these cases, the post-projective view box= could have significant wastage (unnecessary bits of the scene), and when= the light is close to the view-box the large FoV causes quite a bit of c= ompression even close to the viewer. This was the primary reason why my = demo forces a minimum distance between the infinity plane and the view-bo= x. > >-----Original Message----- >From: gda...@li... >[mailto:gda...@li...]On Behalf Of Tom >Forsyth >Sent: Friday, August 27, 2004 2:13 AM >To: gda...@li... >Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. > > >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 talk= ing >about ages ago. http://www.comp.nus.edu.sg/~tants/tsm.html Yeah, I'm sl= ow. >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 s= pace >(clipping as necessary). Then they approximate that with a trapezoid. An= d >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 h= ave >because all your thinking is done in the light's frustum, and by definit= ion >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, a= nd >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 pic= king >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 fanbo= y, >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 vi= ew >frustum), then your view frustum in light space is huge. So your trapezo= id >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 the= re >_is_ a way to solve that with a single buffer projected with a simple 4x= 4 >matrix). > >However, there's the stuff about the 80/20 mix that I don't fully unders= tand >- 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 a= re >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 b= e >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 a= bout >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 experien= ce >of PSMs put everyone off wacky projections for life? I know I'm a lot mo= re >wary about investing time in this stuff after that (hey - that's why I'm >posting this message :-). > > >TomF. > > > =20 > >>-----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. >> >> >>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). >> >>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) >> >>http://www.eelpi.gotdns.org/startopia/startopia.html >> >>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. >> =20 >> > ><snip> > > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > |
From: Tom F. <tom...@ee...> - 2004-08-28 05:11:02
|
> This is exactly the problem with PSMs and TSMs: Depending on=20 > where you=20 > point the camera, they are often no better than standard=20 > shadow maps. =20 > So if I have to deal with making my scene look good in this=20 > case, and I=20 > succeed, then I might as well throw away all the PSM and TSM stuff. Hurrah! Jon joins me in the place of nirvana! Well, not quite, but it's = the revelation that "none of this single-buffer crap is going to solve everything" that frees you from the stupid mathematical distractions of thinking about obscure projections and concentrates the mind on solving = the _actual_ problem, which is how to allocate multiple shadowbuffer. I do think PSM/TSM methods are useful, but they're tweaks and = optimisations to whatever higher-level method you use to solve the multi-frustum = problem. Maybe you can get a bit more performance in the average case (and if you have lots of lights, the non-average case is only going to happen to one = of them at a time, so it's certainly worthwhile). They're not, in = themselves, a solution. I still don't have a robust solution to the problem of the changing = frustums causing jitter. The "persistent" case I presented at GDC does a lot to = help it, but it's not a 100% solution. Because I've only done it in cheesy = demo apps, I'm still not sure what percentage of cases it lets jitter = through. So it's the one big problem I have left (but then again, every other = technique has it too, so I don't feel all that bad :-) Must write my algo up... TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Jonathan Blow > Sent: 27 August 2004 12:00 > To: gda...@li... > Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 > This is exactly the problem with PSMs and TSMs: Depending on=20 > where you=20 > point the camera, they are often no better than standard=20 > shadow maps. =20 > So if I have to deal with making my scene look good in this=20 > case, and I=20 > succeed, then I might as well throw away all the PSM and TSM stuff. >=20 > In fact it often makes the scene look a lot uglier, as the resolution=20 > jitters around while the camera rotates. It just doesn't feel solid. >=20 > I guess PSM and TSM might have good uses in batch rendering where you=20 > are splatting zillions of shadow maps per frame at real high=20 > resolution=20 > and you can do this kind of case by case thing and it doesn't=20 > matter. =20 > But I just don't see them as being useful for a real-time game that=20 > wants high-quality shadows, not any time soon, anyway. >=20 > (Though if there's a demo out there that uses these kind of=20 > systems that=20 > solves the real-world problems that happen in a game, I'd be eager to=20 > see it. And I'd buy the author a beer -- I sure as hell could never=20 > make PSM or TSM look good, and I tried a lot.) >=20 > -Jonathan. >=20 >=20 > Gary King wrote: >=20 > >I've nearly finished implementing a minor variation on TSMs=20 > in my PSM demo (I still need to implement a=20 > dynamically-computed focus region; however, I've been able to=20 > manually adapt the focus region to generate nice shadows=20 > everywhere I've tried). > > > >Like LSPSMs, the only degeneracy is an easily-handled=20 > uninteresting case (squeezing >N% of the frustum below the=20 > "N% line"), which makes nicer than PSMs in that regard. > > > >A huge view frustum isn't really a problem for TSMs; no more=20 > so than uniform shadow maps, anyway. The worst-case behavior=20 > for TSMs is when the view frustum(/trapezoid) is fat; in this=20 > case, the best behavior is to fall back toward uniform shadow=20 > maps (set the 80/20 split to 80/20). > > > >As far as the PSM quality in the video; it's been my=20 > experience that PSMs (especially Stamminger & Drettakis PSMs,=20 > as opposed to LSPSMs or Kozlov PSMs) can get into a number of=20 > situations where they look significantly worse than uniform=20 > shadow maps; particularly in large scenes with rough bounding=20 > box approximations. In these cases, the post-projective view=20 > box could have significant wastage (unnecessary bits of the=20 > scene), and when the light is close to the view-box the large=20 > FoV causes quite a bit of compression even close to the=20 > viewer. This was the primary reason why my demo forces a=20 > minimum distance between the infinity plane and the view-box. > > > >-----Original Message----- > >From: gda...@li... > >[mailto:gda...@li...]On=20 > Behalf Of Tom > >Forsyth > >Sent: Friday, August 27, 2004 2:13 AM > >To: gda...@li... > >Subject: RE: [Algorithms] General-purpose shadowbuffer=20 > implementation. > > > > > >Goodnes - loads of emails off-list, none on-list. Come on=20 > people - don't be > >shy! > > > >Anyway, due to popular demand I will do a wbe page or a post=20 > about the > >implementation details. > > > > > > > >So I was reading the Trapezoidal Shadow Map paper that=20 > everyone was talking > >about ages ago. http://www.comp.nus.edu.sg/~tants/tsm.html =20 > Yeah, I'm slow. > >It's interesting reading - it's basically a smarter version=20 > of PSM from what > >I can see - selecting a better warping for the shadowmap=20 > that minimises > >texel wastage. They take the camera frustum and draw it in=20 > the light's space > >(clipping as necessary). Then they approximate that with a=20 > trapezoid. And > >then they find a 4x4 projection matrix that maps that to the=20 > unit square. > >And that's your shadowbuffer projection. > > > >So by definition it doesn't have the divide-by-zero problems=20 > that PSMs have > >because all your thinking is done in the light's frustum,=20 > and by definition > >if something is outside the light's frustum, it's not lit=20 > 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=20 > light, camera or > >objects doesn't cause a large change in the trapezoidal=20 > approximation, and > >therefore the mapping always changes smoothly, which solves=20 > some of the > >abrupt popping of most shadowbuffer methods. (actually, objects are > >irrelevant, unlike PSM, because TSM doesn't consider them at=20 > all - just > >camera frustum and light). > > > >(The paper also has some interesting (but orthogonal)=20 > comments about picking > >a depth epsilon to try to reduce surface acne and=20 > peterpanning, and how a > >trapezoidal projection makes this a lot worse and how to=20 > make it not so bad > >by de-projecting the epsilon in the shader. But I'm an=20 > ID/priority fanboy, > >so I just skimmed that bit) > > > >So it's all great for distant lights and shortish view=20 > distances. But it > >seems like there's a pretty glaring hole in the algorithm.=20 > If your view is > >any decent distance compared to the light, and the light is=20 > not a nice > >narrow-cone spotlight (so you can just clip off the large=20 > bits of the view > >frustum), then your view frustum in light space is huge. So=20 > your trapezoid > >approximation doesn't help you much. Also, it doesn't seem=20 > to help the > >duelling frustum case at all that I can see (because I don't=20 > believe there > >_is_ a way to solve that with a single buffer projected with=20 > a simple 4x4 > >matrix). > > > >However, there's the stuff about the 80/20 mix that I don't=20 > fully understand > >- maybe that somehow compensates for large far-clip-plane=20 > distances. But who > >uses a far clip plane that isn't basically infinite these=20 > days? The only > >case I can think of is corridor shooters, and 90% of your=20 > lights there are > >very close to the view frustum, so again - minimal gain from=20 > TSM (in a > >corridor shooter, apart from the omnidirection-light=20 > problem, which is a > >different kettle of fish altogether, you can pretty easily=20 > 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=20 > 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=20 > it lots of > >trouble. > > > >I also don't understand the videos - their PSM=20 > implementation seems to be > >performing terribly - far worse than I'd expect. There's no=20 > reason I can see > >that it should ever be _worse_ than the relatively dumb BB=20 > case. Another > >(rather more minor) quibble I have is that if one of the=20 > 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=20 > resoloution that is low > >enough to show me the texels not-popping. They've picked one=20 > where I can't > >actually see any texels, so they could be popping every=20 > single frame and > >you'd never know it. > > > > > >Has anyone actually tried this stuff in a real game? Or has=20 > the experience > >of PSMs put everyone off wacky projections for life? I know=20 > I'm a lot more > >wary about investing time in this stuff after that (hey -=20 > that's why I'm > >posting this message :-). > > > > > >TomF. > > > > > > =20 > > > >>-----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. > >> > >> > >>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). > >> > >>If you want to actually run it, you need a copy of the=20 > 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) > >> > >>http://www.eelpi.gotdns.org/startopia/startopia.html > >> > >>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. > >> =20 > >> > > > ><snip> > > > > > > > >------------------------------------------------------- > >SF.Net email is sponsored by Shop4tech.com-Lowest price on=20 > Blank Media > >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by BEA Weblogic Workshop > >FREE Java Enterprise J2EE developer tools! > >Get your free copy of BEA WebLogic Workshop 8.1 today. > >http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |
From: Greg H. <ghj...@lv...> - 2004-08-28 15:32:09
|
SG93IGRvIHlvdSBndXlzIGhhbmRsZSB0aGUgY2FzZSB3aGVyZSBvYmplY3RzIG92ZXJsYXAg dGhlIGJvdW5kYXJ5DQpiZXR3ZWVuIG11bHRpcGxlIHNoYWRvdyBidWZmZXJzPyAgRm9yIGV4 YW1wbGUgaW4gVG9tJ3MgR0RDIGRlbW8gaGUNCmhhZCBjaHVua3Mgb2YgdGhlICJ0ZXJyYWlu IiBtZXNoIGFmZmVjdGVkIGJ5IHNlcGFyYXRlIHNoYWRvdw0KbWFwcyBtZWFuaW5nIHRoYXQg YXJiaXRyYXJpbHkgY2hhbmdpbmcgY2h1bmtzIG9mIHRlcnJhaW4gaGF2ZSB0byBiZQ0KZHJh d24gc2VwYXJhdGVseS4gIFRoaXMgc2VlbXMgbGlrZSBhIGZhaXJseSBiaWcgcHJvYmxlbSB0 byBtZSBidXQNCm1heWJlIEknbSBtaXNzaW5nIGEgc2ltcGxlIHNvbHV0aW9uPw0KDQpHcmVn IEhqZWxzdHJvbQ0KDQoNCkZyaWRheSwgQXVndXN0IDI3LCAyMDA0LCAxMDoxMDo1NiBQTSwg eW91IHdyb3RlOg0KDQo+PiBUaGlzIGlzIGV4YWN0bHkgdGhlIHByb2JsZW0gd2l0aCBQU01z IGFuZCBUU01zOiBEZXBlbmRpbmcgb24gDQo+PiB3aGVyZSB5b3UgDQo+PiBwb2ludCB0aGUg Y2FtZXJhLCB0aGV5IGFyZSBvZnRlbiBubyBiZXR0ZXIgdGhhbiBzdGFuZGFyZCANCj4+IHNo YWRvdyBtYXBzLiAgDQo+PiBTbyBpZiBJIGhhdmUgdG8gZGVhbCB3aXRoIG1ha2luZyBteSBz Y2VuZSBsb29rIGdvb2QgaW4gdGhpcyANCj4+IGNhc2UsIGFuZCBJIA0KPj4gc3VjY2VlZCwg dGhlbiBJIG1pZ2h0IGFzIHdlbGwgdGhyb3cgYXdheSBhbGwgdGhlIFBTTSBhbmQgVFNNIHN0 dWZmLg0KDQpURj4gSHVycmFoISBKb24gam9pbnMgbWUgaW4gdGhlIHBsYWNlIG9mIG5pcnZh bmEhIFdlbGwsIG5vdCBxdWl0ZSwgYnV0IGl0J3MgdGhlDQpURj4gcmV2ZWxhdGlvbiB0aGF0 ICJub25lIG9mIHRoaXMgc2luZ2xlLWJ1ZmZlciBjcmFwIGlzIGdvaW5nIHRvIHNvbHZlDQpU Rj4gZXZlcnl0aGluZyIgdGhhdCBmcmVlcyB5b3UgZnJvbSB0aGUgc3R1cGlkIG1hdGhlbWF0 aWNhbCBkaXN0cmFjdGlvbnMgb2YNClRGPiB0aGlua2luZyBhYm91dCBvYnNjdXJlIHByb2pl Y3Rpb25zIGFuZCBjb25jZW50cmF0ZXMgdGhlIG1pbmQgb24gc29sdmluZyB0aGUNClRGPiBf YWN0dWFsXyBwcm9ibGVtLCB3aGljaCBpcyBob3cgdG8gYWxsb2NhdGUgbXVsdGlwbGUgc2hh ZG93YnVmZmVyLg0KDQpURj4gSSBkbyB0aGluayBQU00vVFNNIG1ldGhvZHMgYXJlIHVzZWZ1 bCwgYnV0IHRoZXkncmUgdHdlYWtzIGFuZCBvcHRpbWlzYXRpb25zDQpURj4gdG8gd2hhdGV2 ZXIgaGlnaGVyLWxldmVsIG1ldGhvZCB5b3UgdXNlIHRvIHNvbHZlIHRoZSBtdWx0aS1mcnVz dHVtIHByb2JsZW0uDQpURj4gTWF5YmUgeW91IGNhbiBnZXQgYSBiaXQgbW9yZSBwZXJmb3Jt YW5jZSBpbiB0aGUgYXZlcmFnZSBjYXNlIChhbmQgaWYgeW91DQpURj4gaGF2ZSBsb3RzIG9m IGxpZ2h0cywgdGhlIG5vbi1hdmVyYWdlIGNhc2UgaXMgb25seSBnb2luZyB0byBoYXBwZW4g dG8gb25lIG9mDQpURj4gdGhlbSBhdCBhIHRpbWUsIHNvIGl0J3MgY2VydGFpbmx5IHdvcnRo d2hpbGUpLiBUaGV5J3JlIG5vdCwgaW4gdGhlbXNlbHZlcywgYQ0KVEY+IHNvbHV0aW9uLg0K DQpURj4gSSBzdGlsbCBkb24ndCBoYXZlIGEgcm9idXN0IHNvbHV0aW9uIHRvIHRoZSBwcm9i bGVtIG9mIHRoZSBjaGFuZ2luZyBmcnVzdHVtcw0KVEY+IGNhdXNpbmcgaml0dGVyLiBUaGUg InBlcnNpc3RlbnQiIGNhc2UgSSBwcmVzZW50ZWQgYXQgR0RDIGRvZXMgYSBsb3QgdG8gaGVs cA0KVEY+IGl0LCBidXQgaXQncyBub3QgYSAxMDAlIHNvbHV0aW9uLiBCZWNhdXNlIEkndmUg b25seSBkb25lIGl0IGluIGNoZWVzeSBkZW1vDQpURj4gYXBwcywgSSdtIHN0aWxsIG5vdCBz dXJlIHdoYXQgcGVyY2VudGFnZSBvZiBjYXNlcyBpdCBsZXRzIGppdHRlciB0aHJvdWdoLiBT bw0KVEY+IGl0J3MgdGhlIG9uZSBiaWcgcHJvYmxlbSBJIGhhdmUgbGVmdCAoYnV0IHRoZW4g YWdhaW4sIGV2ZXJ5IG90aGVyIHRlY2huaXF1ZQ0KVEY+IGhhcyBpdCB0b28sIHNvIEkgZG9u J3QgZmVlbCBhbGwgdGhhdCBiYWQgOi0pDQoNClRGPiBNdXN0IHdyaXRlIG15IGFsZ28gdXAu Li4NCg0KVEY+IFRvbUYuDQoNCg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ IEZyb206IGdkYWxnb3JpdGhtcy1saXN0LWFkbWluQGxpc3RzLnNvdXJjZWZvcmdlLm5ldCAN Cj4+IFttYWlsdG86Z2RhbGdvcml0aG1zLWxpc3QtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2Uu bmV0XSBPbiANCj4+IEJlaGFsZiBPZiBKb25hdGhhbiBCbG93DQo+PiBTZW50OiAyNyBBdWd1 c3QgMjAwNCAxMjowMA0KPj4gVG86IGdkYWxnb3JpdGhtcy1saXN0QGxpc3RzLnNvdXJjZWZv cmdlLm5ldA0KPj4gU3ViamVjdDogUmU6IFtBbGdvcml0aG1zXSBHZW5lcmFsLXB1cnBvc2Ug c2hhZG93YnVmZmVyIGltcGxlbWVudGF0aW9uLg0KPj4gDQo+PiANCj4+IFRoaXMgaXMgZXhh Y3RseSB0aGUgcHJvYmxlbSB3aXRoIFBTTXMgYW5kIFRTTXM6IERlcGVuZGluZyBvbiANCj4+ IHdoZXJlIHlvdSANCj4+IHBvaW50IHRoZSBjYW1lcmEsIHRoZXkgYXJlIG9mdGVuIG5vIGJl dHRlciB0aGFuIHN0YW5kYXJkIA0KPj4gc2hhZG93IG1hcHMuICANCj4+IFNvIGlmIEkgaGF2 ZSB0byBkZWFsIHdpdGggbWFraW5nIG15IHNjZW5lIGxvb2sgZ29vZCBpbiB0aGlzIA0KPj4g Y2FzZSwgYW5kIEkgDQo+PiBzdWNjZWVkLCB0aGVuIEkgbWlnaHQgYXMgd2VsbCB0aHJvdyBh d2F5IGFsbCB0aGUgUFNNIGFuZCBUU00gc3R1ZmYuDQo+PiANCj4+IEluIGZhY3QgaXQgb2Z0 ZW4gbWFrZXMgdGhlIHNjZW5lIGxvb2sgYSBsb3QgdWdsaWVyLCBhcyB0aGUgcmVzb2x1dGlv biANCj4+IGppdHRlcnMgYXJvdW5kIHdoaWxlIHRoZSBjYW1lcmEgcm90YXRlcy4gIEl0IGp1 c3QgZG9lc24ndCBmZWVsIHNvbGlkLg0KPj4gDQo+PiBJIGd1ZXNzIFBTTSBhbmQgVFNNIG1p Z2h0IGhhdmUgZ29vZCB1c2VzIGluIGJhdGNoIHJlbmRlcmluZyB3aGVyZSB5b3UgDQo+PiBh cmUgc3BsYXR0aW5nIHppbGxpb25zIG9mIHNoYWRvdyBtYXBzIHBlciBmcmFtZSBhdCByZWFs IGhpZ2ggDQo+PiByZXNvbHV0aW9uIA0KPj4gYW5kIHlvdSBjYW4gZG8gdGhpcyBraW5kIG9m IGNhc2UgYnkgY2FzZSB0aGluZyBhbmQgaXQgZG9lc24ndCANCj4+IG1hdHRlci4gIA0KPj4g QnV0IEkganVzdCBkb24ndCBzZWUgdGhlbSBhcyBiZWluZyB1c2VmdWwgZm9yIGEgcmVhbC10 aW1lIGdhbWUgdGhhdCANCj4+IHdhbnRzIGhpZ2gtcXVhbGl0eSBzaGFkb3dzLCBub3QgYW55 IHRpbWUgc29vbiwgYW55d2F5Lg0KPj4gDQo+PiAoVGhvdWdoIGlmIHRoZXJlJ3MgYSBkZW1v IG91dCB0aGVyZSB0aGF0IHVzZXMgdGhlc2Uga2luZCBvZiANCj4+IHN5c3RlbXMgdGhhdCAN Cj4+IHNvbHZlcyB0aGUgcmVhbC13b3JsZCBwcm9ibGVtcyB0aGF0IGhhcHBlbiBpbiBhIGdh bWUsIEknZCBiZSBlYWdlciB0byANCj4+IHNlZSBpdC4gIEFuZCBJJ2QgYnV5IHRoZSBhdXRo b3IgYSBiZWVyIC0tIEkgc3VyZSBhcyBoZWxsIGNvdWxkIG5ldmVyIA0KPj4gbWFrZSBQU00g b3IgVFNNIGxvb2sgZ29vZCwgYW5kIEkgdHJpZWQgYSBsb3QuKQ0KPj4gDQo+PiAgIC1Kb25h dGhhbi4NCj4+IA0KPj4gDQo+PiBHYXJ5IEtpbmcgd3JvdGU6DQo+PiANCj4+ID5JJ3ZlIG5l YXJseSBmaW5pc2hlZCBpbXBsZW1lbnRpbmcgYSBtaW5vciB2YXJpYXRpb24gb24gVFNNcyAN Cj4+IGluIG15IFBTTSBkZW1vIChJIHN0aWxsIG5lZWQgdG8gaW1wbGVtZW50IGEgDQo+PiBk eW5hbWljYWxseS1jb21wdXRlZCBmb2N1cyByZWdpb247IGhvd2V2ZXIsIEkndmUgYmVlbiBh YmxlIHRvIA0KPj4gbWFudWFsbHkgYWRhcHQgdGhlIGZvY3VzIHJlZ2lvbiB0byBnZW5lcmF0 ZSBuaWNlIHNoYWRvd3MgDQo+PiBldmVyeXdoZXJlIEkndmUgdHJpZWQpLg0KPj4gPg0KPj4g Pkxpa2UgTFNQU01zLCB0aGUgb25seSBkZWdlbmVyYWN5IGlzIGFuIGVhc2lseS1oYW5kbGVk IA0KPj4gdW5pbnRlcmVzdGluZyBjYXNlIChzcXVlZXppbmcgPk4lIG9mIHRoZSBmcnVzdHVt IGJlbG93IHRoZSANCj4+ICJOJSBsaW5lIiksIHdoaWNoIG1ha2VzIG5pY2VyIHRoYW4gUFNN cyBpbiB0aGF0IHJlZ2FyZC4NCj4+ID4NCj4+ID5BIGh1Z2UgdmlldyBmcnVzdHVtIGlzbid0 IHJlYWxseSBhIHByb2JsZW0gZm9yIFRTTXM7IG5vIG1vcmUgDQo+PiBzbyB0aGFuIHVuaWZv cm0gc2hhZG93IG1hcHMsIGFueXdheS4gIFRoZSB3b3JzdC1jYXNlIGJlaGF2aW9yIA0KPj4g Zm9yIFRTTXMgaXMgd2hlbiB0aGUgdmlldyBmcnVzdHVtKC90cmFwZXpvaWQpIGlzIGZhdDsg aW4gdGhpcyANCj4+IGNhc2UsIHRoZSBiZXN0IGJlaGF2aW9yIGlzIHRvIGZhbGwgYmFjayB0 b3dhcmQgdW5pZm9ybSBzaGFkb3cgDQo+PiBtYXBzIChzZXQgdGhlIDgwLzIwIHNwbGl0IHRv IDgwLzIwKS4NCj4+ID4NCj4+ID5BcyBmYXIgYXMgdGhlIFBTTSBxdWFsaXR5IGluIHRoZSB2 aWRlbzsgaXQncyBiZWVuIG15IA0KPj4gZXhwZXJpZW5jZSB0aGF0IFBTTXMgKGVzcGVjaWFs bHkgU3RhbW1pbmdlciAmIERyZXR0YWtpcyBQU01zLCANCj4+IGFzIG9wcG9zZWQgdG8gTFNQ U01zIG9yIEtvemxvdiBQU01zKSBjYW4gZ2V0IGludG8gYSBudW1iZXIgb2YgDQo+PiBzaXR1 YXRpb25zIHdoZXJlIHRoZXkgbG9vayBzaWduaWZpY2FudGx5IHdvcnNlIHRoYW4gdW5pZm9y bSANCj4+IHNoYWRvdyBtYXBzOyBwYXJ0aWN1bGFybHkgaW4gbGFyZ2Ugc2NlbmVzIHdpdGgg cm91Z2ggYm91bmRpbmcgDQo+PiBib3ggYXBwcm94aW1hdGlvbnMuICBJbiB0aGVzZSBjYXNl cywgdGhlIHBvc3QtcHJvamVjdGl2ZSB2aWV3IA0KPj4gYm94IGNvdWxkIGhhdmUgc2lnbmlm aWNhbnQgd2FzdGFnZSAodW5uZWNlc3NhcnkgYml0cyBvZiB0aGUgDQo+PiBzY2VuZSksIGFu ZCB3aGVuIHRoZSBsaWdodCBpcyBjbG9zZSB0byB0aGUgdmlldy1ib3ggdGhlIGxhcmdlIA0K Pj4gRm9WIGNhdXNlcyBxdWl0ZSBhIGJpdCBvZiBjb21wcmVzc2lvbiBldmVuIGNsb3NlIHRv IHRoZSANCj4+IHZpZXdlci4gIFRoaXMgd2FzIHRoZSBwcmltYXJ5IHJlYXNvbiB3aHkgbXkg ZGVtbyBmb3JjZXMgYSANCj4+IG1pbmltdW0gZGlzdGFuY2UgYmV0d2VlbiB0aGUgaW5maW5p dHkgcGxhbmUgYW5kIHRoZSB2aWV3LWJveC4NCj4+ID4NCj4+ID4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gPkZyb206IGdkYWxnb3JpdGhtcy1saXN0LWFkbWluQGxpc3RzLnNv dXJjZWZvcmdlLm5ldA0KPj4gPlttYWlsdG86Z2RhbGdvcml0aG1zLWxpc3QtYWRtaW5AbGlz dHMuc291cmNlZm9yZ2UubmV0XU9uIA0KPj4gQmVoYWxmIE9mIFRvbQ0KPj4gPkZvcnN5dGgN Cj4+ID5TZW50OiBGcmlkYXksIEF1Z3VzdCAyNywgMjAwNCAyOjEzIEFNDQo+PiA+VG86IGdk YWxnb3JpdGhtcy1saXN0QGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPj4gPlN1YmplY3Q6IFJF OiBbQWxnb3JpdGhtc10gR2VuZXJhbC1wdXJwb3NlIHNoYWRvd2J1ZmZlciANCj4+IGltcGxl bWVudGF0aW9uLg0KPj4gPg0KPj4gPg0KPj4gPkdvb2RuZXMgLSBsb2FkcyBvZiBlbWFpbHMg b2ZmLWxpc3QsIG5vbmUgb24tbGlzdC4gQ29tZSBvbiANCj4+IHBlb3BsZSAtIGRvbid0IGJl DQo+PiA+c2h5IQ0KPj4gPg0KPj4gPkFueXdheSwgZHVlIHRvIHBvcHVsYXIgZGVtYW5kIEkg d2lsbCBkbyBhIHdiZSBwYWdlIG9yIGEgcG9zdCANCj4+IGFib3V0IHRoZQ0KPj4gPmltcGxl bWVudGF0aW9uIGRldGFpbHMuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+U28gSSB3YXMgcmVh ZGluZyB0aGUgVHJhcGV6b2lkYWwgU2hhZG93IE1hcCBwYXBlciB0aGF0IA0KPj4gZXZlcnlv bmUgd2FzIHRhbGtpbmcNCj4+ID5hYm91dCBhZ2VzIGFnby4gaHR0cDovL3d3dy5jb21wLm51 cy5lZHUuc2cvfnRhbnRzL3RzbS5odG1sICANCj4+IFllYWgsIEknbSBzbG93Lg0KPj4gPkl0 J3MgaW50ZXJlc3RpbmcgcmVhZGluZyAtIGl0J3MgYmFzaWNhbGx5IGEgc21hcnRlciB2ZXJz aW9uIA0KPj4gb2YgUFNNIGZyb20gd2hhdA0KPj4gPkkgY2FuIHNlZSAtIHNlbGVjdGluZyBh IGJldHRlciB3YXJwaW5nIGZvciB0aGUgc2hhZG93bWFwIA0KPj4gdGhhdCBtaW5pbWlzZXMN Cj4+ID50ZXhlbCB3YXN0YWdlLiBUaGV5IHRha2UgdGhlIGNhbWVyYSBmcnVzdHVtIGFuZCBk cmF3IGl0IGluIA0KPj4gdGhlIGxpZ2h0J3Mgc3BhY2UNCj4+ID4oY2xpcHBpbmcgYXMgbmVj ZXNzYXJ5KS4gVGhlbiB0aGV5IGFwcHJveGltYXRlIHRoYXQgd2l0aCBhIA0KPj4gdHJhcGV6 b2lkLiBBbmQNCj4+ID50aGVuIHRoZXkgZmluZCBhIDR4NCBwcm9qZWN0aW9uIG1hdHJpeCB0 aGF0IG1hcHMgdGhhdCB0byB0aGUgDQo+PiB1bml0IHNxdWFyZS4NCj4+ID5BbmQgdGhhdCdz IHlvdXIgc2hhZG93YnVmZmVyIHByb2plY3Rpb24uDQo+PiA+DQo+PiA+U28gYnkgZGVmaW5p dGlvbiBpdCBkb2Vzbid0IGhhdmUgdGhlIGRpdmlkZS1ieS16ZXJvIHByb2JsZW1zIA0KPj4g dGhhdCBQU01zIGhhdmUNCj4+ID5iZWNhdXNlIGFsbCB5b3VyIHRoaW5raW5nIGlzIGRvbmUg aW4gdGhlIGxpZ2h0J3MgZnJ1c3R1bSwgDQo+PiBhbmQgYnkgZGVmaW5pdGlvbg0KPj4gPmlm IHNvbWV0aGluZyBpcyBvdXRzaWRlIHRoZSBsaWdodCdzIGZydXN0dW0sIGl0J3Mgbm90IGxp dCANCj4+IGFueXdheSBhbmQgc28NCj4+ID5jYW4ndCBiZSBzaGFkb3dlZCBvciBjYXN0IHNo YWRvd3MuIFNvIHRoYXQgc29sdmVzIHRoYXQuDQo+PiA+DQo+PiA+SXQncyBhbHNvIG5pY2Ug dGhhdCBpdCdzIGNvbnRpbnVvdXMgLSBhIHNtYWxsIG1vdmVtZW50IG9mIA0KPj4gbGlnaHQs IGNhbWVyYSBvcg0KPj4gPm9iamVjdHMgZG9lc24ndCBjYXVzZSBhIGxhcmdlIGNoYW5nZSBp biB0aGUgdHJhcGV6b2lkYWwgDQo+PiBhcHByb3hpbWF0aW9uLCBhbmQNCj4+ID50aGVyZWZv cmUgdGhlIG1hcHBpbmcgYWx3YXlzIGNoYW5nZXMgc21vb3RobHksIHdoaWNoIHNvbHZlcyAN Cj4+IHNvbWUgb2YgdGhlDQo+PiA+YWJydXB0IHBvcHBpbmcgb2YgbW9zdCBzaGFkb3didWZm ZXIgbWV0aG9kcy4gKGFjdHVhbGx5LCBvYmplY3RzIGFyZQ0KPj4gPmlycmVsZXZhbnQsIHVu bGlrZSBQU00sIGJlY2F1c2UgVFNNIGRvZXNuJ3QgY29uc2lkZXIgdGhlbSBhdCANCj4+IGFs bCAtIGp1c3QNCj4+ID5jYW1lcmEgZnJ1c3R1bSBhbmQgbGlnaHQpLg0KPj4gPg0KPj4gPihU aGUgcGFwZXIgYWxzbyBoYXMgc29tZSBpbnRlcmVzdGluZyAoYnV0IG9ydGhvZ29uYWwpIA0K Pj4gY29tbWVudHMgYWJvdXQgcGlja2luZw0KPj4gPmEgZGVwdGggZXBzaWxvbiB0byB0cnkg dG8gcmVkdWNlIHN1cmZhY2UgYWNuZSBhbmQgDQo+PiBwZXRlcnBhbm5pbmcsIGFuZCBob3cg YQ0KPj4gPnRyYXBlem9pZGFsIHByb2plY3Rpb24gbWFrZXMgdGhpcyBhIGxvdCB3b3JzZSBh bmQgaG93IHRvIA0KPj4gbWFrZSBpdCBub3Qgc28gYmFkDQo+PiA+YnkgZGUtcHJvamVjdGlu ZyB0aGUgZXBzaWxvbiBpbiB0aGUgc2hhZGVyLiBCdXQgSSdtIGFuIA0KPj4gSUQvcHJpb3Jp dHkgZmFuYm95LA0KPj4gPnNvIEkganVzdCBza2ltbWVkIHRoYXQgYml0KQ0KPj4gPg0KPj4g PlNvIGl0J3MgYWxsIGdyZWF0IGZvciBkaXN0YW50IGxpZ2h0cyBhbmQgc2hvcnRpc2ggdmll dyANCj4+IGRpc3RhbmNlcy4gQnV0IGl0DQo+PiA+c2VlbXMgbGlrZSB0aGVyZSdzIGEgcHJl dHR5IGdsYXJpbmcgaG9sZSBpbiB0aGUgYWxnb3JpdGhtLiANCj4+IElmIHlvdXIgdmlldyBp cw0KPj4gPmFueSBkZWNlbnQgZGlzdGFuY2UgY29tcGFyZWQgdG8gdGhlIGxpZ2h0LCBhbmQg dGhlIGxpZ2h0IGlzIA0KPj4gbm90IGEgbmljZQ0KPj4gPm5hcnJvdy1jb25lIHNwb3RsaWdo dCAoc28geW91IGNhbiBqdXN0IGNsaXAgb2ZmIHRoZSBsYXJnZSANCj4+IGJpdHMgb2YgdGhl IHZpZXcNCj4+ID5mcnVzdHVtKSwgdGhlbiB5b3VyIHZpZXcgZnJ1c3R1bSBpbiBsaWdodCBz cGFjZSBpcyBodWdlLiBTbyANCj4+IHlvdXIgdHJhcGV6b2lkDQo+PiA+YXBwcm94aW1hdGlv biBkb2Vzbid0IGhlbHAgeW91IG11Y2guIEFsc28sIGl0IGRvZXNuJ3Qgc2VlbSANCj4+IHRv IGhlbHAgdGhlDQo+PiA+ZHVlbGxpbmcgZnJ1c3R1bSBjYXNlIGF0IGFsbCB0aGF0IEkgY2Fu IHNlZSAoYmVjYXVzZSBJIGRvbid0IA0KPj4gYmVsaWV2ZSB0aGVyZQ0KPj4gPl9pc18gYSB3 YXkgdG8gc29sdmUgdGhhdCB3aXRoIGEgc2luZ2xlIGJ1ZmZlciBwcm9qZWN0ZWQgd2l0aCAN Cj4+IGEgc2ltcGxlIDR4NA0KPj4gPm1hdHJpeCkuDQo+PiA+DQo+PiA+SG93ZXZlciwgdGhl cmUncyB0aGUgc3R1ZmYgYWJvdXQgdGhlIDgwLzIwIG1peCB0aGF0IEkgZG9uJ3QgDQo+PiBm dWxseSB1bmRlcnN0YW5kDQo+PiA+LSBtYXliZSB0aGF0IHNvbWVob3cgY29tcGVuc2F0ZXMg Zm9yIGxhcmdlIGZhci1jbGlwLXBsYW5lIA0KPj4gZGlzdGFuY2VzLiBCdXQgd2hvDQo+PiA+ dXNlcyBhIGZhciBjbGlwIHBsYW5lIHRoYXQgaXNuJ3QgYmFzaWNhbGx5IGluZmluaXRlIHRo ZXNlIA0KPj4gZGF5cz8gVGhlIG9ubHkNCj4+ID5jYXNlIEkgY2FuIHRoaW5rIG9mIGlzIGNv cnJpZG9yIHNob290ZXJzLCBhbmQgOTAlIG9mIHlvdXIgDQo+PiBsaWdodHMgdGhlcmUgYXJl DQo+PiA+dmVyeSBjbG9zZSB0byB0aGUgdmlldyBmcnVzdHVtLCBzbyBhZ2FpbiAtIG1pbmlt YWwgZ2FpbiBmcm9tIA0KPj4gVFNNIChpbiBhDQo+PiA+Y29ycmlkb3Igc2hvb3RlciwgYXBh cnQgZnJvbSB0aGUgb21uaWRpcmVjdGlvbi1saWdodCANCj4+IHByb2JsZW0sIHdoaWNoIGlz IGENCj4+ID5kaWZmZXJlbnQga2V0dGxlIG9mIGZpc2ggYWx0b2dldGhlciwgeW91IGNhbiBw cmV0dHkgZWFzaWx5IA0KPj4gZ2V0IGF3YXkgd2l0aA0KPj4gPmR1bWIgQkIgc2hhZG93YnVm ZmVycyBiZWNhdXNlIHRoZSBjaGFuZ2UgaW4gdGV4ZWwgZGVuc2l0eSBpcyBmYWlybHkNCj4+ ID5tb2RlcmF0ZSwgdW5saWtlIHNvbWV0aGluZyBsaWtlIHRoZSBzdW4gb3V0ZG9vcnMpLg0K Pj4gPg0KPj4gPlNvIGl0IHNlZW1zIGxpa2UgaXQncyBiZXR0ZXIgdGhhbiBQU00gZm9yIHNv bWUgY2FzZXMsIGJ1dCANCj4+IGRvZXNuJ3Qgc29sdmUgYW55DQo+PiA+b2YgdGhlIHJlYWwt d29ybGQgY2FzZXMgKGR1ZWxsaW5nIGZydXN0dW1zKSwgYW5kIGFzIGZhciBhcyBJIGNhbiBz ZWUsDQo+PiA+cHVzaGluZyB0aGUgZmFyIGNsaXAgcGxhbmUgb3V0IHRvIHNlbnNpYmxlIGRp c3RhbmNlcyBjYXVzZXMgDQo+PiBpdCBsb3RzIG9mDQo+PiA+dHJvdWJsZS4NCj4+ID4NCj4+ ID5JIGFsc28gZG9uJ3QgdW5kZXJzdGFuZCB0aGUgdmlkZW9zIC0gdGhlaXIgUFNNIA0KPj4g aW1wbGVtZW50YXRpb24gc2VlbXMgdG8gYmUNCj4+ID5wZXJmb3JtaW5nIHRlcnJpYmx5IC0g ZmFyIHdvcnNlIHRoYW4gSSdkIGV4cGVjdC4gVGhlcmUncyBubyANCj4+IHJlYXNvbiBJIGNh biBzZWUNCj4+ID50aGF0IGl0IHNob3VsZCBldmVyIGJlIF93b3JzZV8gdGhhbiB0aGUgcmVs YXRpdmVseSBkdW1iIEJCIA0KPj4gY2FzZS4gQW5vdGhlcg0KPj4gPihyYXRoZXIgbW9yZSBt aW5vcikgcXVpYmJsZSBJIGhhdmUgaXMgdGhhdCBpZiBvbmUgb2YgdGhlIA0KPj4gQ29vbCBG ZWF0dXJlcyBhYm91dA0KPj4gPlRTTSBpcyB0aGF0IHRoZSBjaGFuZ2VzIGluIG1hcHBpbmcg YXJlIGNvbnRpbnVvdXMsIHNvIHlvdSBtaWdodCBnZXQNCj4+ID5hbGlhc2luZywgYnV0IHlv dSBuZXZlciBnZXQgcG9wcywgdGhlbiBwaWNrIGEgYnVmZmVyIA0KPj4gcmVzb2xvdXRpb24g dGhhdCBpcyBsb3cNCj4+ID5lbm91Z2ggdG8gc2hvdyBtZSB0aGUgdGV4ZWxzIG5vdC1wb3Bw aW5nLiBUaGV5J3ZlIHBpY2tlZCBvbmUgDQo+PiB3aGVyZSBJIGNhbid0DQo+PiA+YWN0dWFs bHkgc2VlIGFueSB0ZXhlbHMsIHNvIHRoZXkgY291bGQgYmUgcG9wcGluZyBldmVyeSANCj4+ IHNpbmdsZSBmcmFtZSBhbmQNCj4+ID55b3UnZCBuZXZlciBrbm93IGl0Lg0KPj4gPg0KPj4g Pg0KPj4gPkhhcyBhbnlvbmUgYWN0dWFsbHkgdHJpZWQgdGhpcyBzdHVmZiBpbiBhIHJlYWwg Z2FtZT8gT3IgaGFzIA0KPj4gdGhlIGV4cGVyaWVuY2UNCj4+ID5vZiBQU01zIHB1dCBldmVy eW9uZSBvZmYgd2Fja3kgcHJvamVjdGlvbnMgZm9yIGxpZmU/IEkga25vdyANCj4+IEknbSBh IGxvdCBtb3JlDQo+PiA+d2FyeSBhYm91dCBpbnZlc3RpbmcgdGltZSBpbiB0aGlzIHN0dWZm IGFmdGVyIHRoYXQgKGhleSAtIA0KPj4gdGhhdCdzIHdoeSBJJ20NCj4+ID5wb3N0aW5nIHRo aXMgbWVzc2FnZSA6LSkuDQo+PiA+DQo+PiA+DQo+PiA+VG9tRi4NCj4+ID4NCj4+ID4NCj4+ ID4gIA0KPj4gPg0KPj4gPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj5Gcm9t OiBnZGFsZ29yaXRobXMtbGlzdC1hZG1pbkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQgDQo+PiA+ PlttYWlsdG86Z2RhbGdvcml0aG1zLWxpc3QtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0 XSBPbiANCj4+ID4+QmVoYWxmIE9mIFRvbSBGb3JzeXRoDQo+PiA+PlNlbnQ6IDI1IEF1Z3Vz dCAyMDA0IDA5OjQ3DQo+PiA+PlRvOiBnZGFsZ29yaXRobXMtbGlzdEBsaXN0cy5zb3VyY2Vm b3JnZS5uZXQNCj4+ID4+U3ViamVjdDogW0FsZ29yaXRobXNdIEdlbmVyYWwtcHVycG9zZSBz aGFkb3didWZmZXIgaW1wbGVtZW50YXRpb24uDQo+PiA+Pg0KPj4gPj4NCj4+ID4+U28gYSBm ZXcgZGF5cyBhZ28gSSBmaW5pc2hlZCBteSBTdGFyVG9waWEgInBhdGNoIiB0aGF0IA0KPj4g Pj5wcm9wZXJseSBhbmQgZmFpcmx5DQo+PiA+PnJvYnVzdGx5IGltcGxlbWVudHMgdGhlIHN0 dWZmIEkgdGFsa2VkIGFib3V0IGluIG15IEdEQyAyMDA0IA0KPj4gPj50YWxrICh3aGljaCB3 YXMNCj4+ID4+YSBmYWlybHkgYmxhdGFudCBoYWNrXkheSF5IXkggcHJvb2Ygb2YgY29uY2Vw dCB3aXRoIGEgDQo+PiA+PmhvcnJpYmxlIGJ1ZyBJIG9ubHkNCj4+ID4+ZGlzY292ZXJlZCBs YXRlcikuDQo+PiA+Pg0KPj4gPj5JZiB5b3Ugd2FudCB0byBhY3R1YWxseSBydW4gaXQsIHlv dSBuZWVkIGEgY29weSBvZiB0aGUgDQo+PiBnYW1lLCBhbmQgdGhlbg0KPj4gPj5kb3dubG9h ZCBib3RoIHBhdGNoZXMgZnJvbSBteSBzaXRlIChsaW5rIGJlbG93KS4gUHJvYmFibHkgDQo+ PiA+PmFsbW9zdCBpbXBvc3NpYmxlDQo+PiA+PnRvIGZpbmQgaW4gdGhlIHNob3BzLCBidXQg cGxlbnR5IG9uIEViYXkgYW5kIFAyUHMgYW5kIA0KPj4gPj5zdWNobGlrZSAoZm9yICphaGVt Kg0KPj4gPj5ldmFsdWF0aW9uIHB1cnBvc2VzLCBvYnZpb3VzbHkpDQo+PiA+Pg0KPj4gPj5o dHRwOi8vd3d3LmVlbHBpLmdvdGRucy5vcmcvc3RhcnRvcGlhL3N0YXJ0b3BpYS5odG1sDQo+ PiA+Pg0KPj4gPj5UaGVyZSdzIHNvbWUgcHJldHR5IHBpY3R1cmVzIGFuZCBkYWZ0IHRleHQg YXMgd2VsbC4gSWYgYW55b25lIA0KPj4gPj53YW50cyBhbiBldmVuDQo+PiA+PnNsb3dlciB2 ZXJzaW9uIHdpdGggbG90cyBvZiBkZWJ1Z2dpbmcgaW5mbyBvbiB0aGUgDQo+PiA+PnNoYWRv d2J1ZmZlcnMsIGp1c3QgeWVsbA0KPj4gPj5hbmQgSSdsbCBzZWUgd2hhdCBJIGNhbiBydXN0 bGUgdXAgZm9yIHlvdS4NCj4+ID4+ICAgIA0KPj4gPj4NCj4+ID4NCj4+ID48c25pcD4NCj4+ ID4NCj4+ID4NCj4+ID4NCj4+ID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiA+U0YuTmV0IGVtYWlsIGlzIHNwb25zb3JlZCBi eSBTaG9wNHRlY2guY29tLUxvd2VzdCBwcmljZSBvbiANCj4+IEJsYW5rIE1lZGlhDQo+PiA+ MTAwcGsgU29uaWMgRFZELVIgNHggZm9yIG9ubHkgJDI5IC0xMDBwayBTb25pYyBEVkQrUiBm b3Igb25seSAkMzMNCj4+ID5TYXZlIDUwJSBvZmYgUmV0YWlsIG9uIEluayAmIFRvbmVyIC0g RnJlZSBTaGlwcGluZyBhbmQgRnJlZSBHaWZ0Lg0KPj4gPmh0dHA6Ly93d3cuc2hvcDR0ZWNo LmNvbS96L0lua2pldF9DYXJ0cmlkZ2VzLzlfMTA4X3IyODUNCj4+ID5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPkdEQWxnb3JpdGhtcy1s aXN0IG1haWxpbmcgbGlzdA0KPj4gPkdEQWxnb3JpdGhtcy1saXN0QGxpc3RzLnNvdXJjZWZv cmdlLm5ldA0KPj4gPmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3Rp bmZvL2dkYWxnb3JpdGhtcy1saXN0DQo+PiA+QXJjaGl2ZXM6DQo+PiA+aHR0cDovL3NvdXJj ZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9mb3J1bS5waHA/Zm9ydW1faWRhODgNCj4+ID4NCj4+ ID4NCj4+ID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+PiA+VGhpcyBTRi5OZXQgZW1haWwgaXMgc3BvbnNvcmVkIGJ5IEJFQSBX ZWJsb2dpYyBXb3Jrc2hvcA0KPj4gPkZSRUUgSmF2YSBFbnRlcnByaXNlIEoyRUUgZGV2ZWxv cGVyIHRvb2xzIQ0KPj4gPkdldCB5b3VyIGZyZWUgY29weSBvZiBCRUEgV2ViTG9naWMgV29y a3Nob3AgOC4xIHRvZGF5Lg0KPj4gPmh0dHA6Ly9hZHMub3Nkbi5jb20vP2FkX2lkUDQ3JmFs bG9jX2lkEDgwOCZvcMxrDQo+PiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+ID5HREFsZ29yaXRobXMtbGlzdCBtYWlsaW5nIGxpc3QNCj4+ ID5HREFsZ29yaXRobXMtbGlzdEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4+ID5odHRwczov L2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9nZGFsZ29yaXRobXMtbGlz dA0KPj4gPkFyY2hpdmVzOg0KPj4gPmh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hp dmUvZm9ydW0ucGhwP2ZvcnVtX2lkYTg4DQo+PiA+DQo+PiA+ICANCj4+ID4NCj4+IA0KPj4g DQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+IFRoaXMgU0YuTmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieSBCRUEg V2VibG9naWMgV29ya3Nob3ANCj4+IEZSRUUgSmF2YSBFbnRlcnByaXNlIEoyRUUgZGV2ZWxv cGVyIHRvb2xzIQ0KPj4gR2V0IHlvdXIgZnJlZSBjb3B5IG9mIEJFQSBXZWJMb2dpYyBXb3Jr c2hvcCA4LjEgdG9kYXkuDQo+PiBodHRwOi8vYWRzLm9zZG4uY29tLz9hZF9pZFA0NyZhbGxv Y19pZBA4MDgmb3A9aWNrDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gR0RBbGdvcml0aG1zLWxpc3QgbWFpbGluZyBsaXN0DQo+PiBH REFsZ29yaXRobXMtbGlzdEBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4+IGh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2dkYWxnb3JpdGhtcy1saXN0DQo+ PiBBcmNoaXZlczoNCj4+IGh0dHA6Ly9zb3VyY2Vmb3JnZS5uZXQvbWFpbGFyY2hpdmUvZm9y dW0ucGhwP2ZvcnVtX2lkYTg4DQo+PiANCg0KDQoNClRGPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpURj4gVGhpcyBTRi5OZXQg ZW1haWwgaXMgc3BvbnNvcmVkIGJ5IEJFQSBXZWJsb2dpYyBXb3Jrc2hvcA0KVEY+IEZSRUUg SmF2YSBFbnRlcnByaXNlIEoyRUUgZGV2ZWxvcGVyIHRvb2xzIQ0KVEY+IEdldCB5b3VyIGZy ZWUgY29weSBvZiBCRUEgV2ViTG9naWMgV29ya3Nob3AgOC4xIHRvZGF5Lg0KVEY+IGh0dHA6 Ly9hZHMub3Nkbi5jb20vP2FkX2lkUDQ3JmFsbG9jX2lkEDgwOCZvcGxpY2sNClRGPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVEY+IEdEQWxn b3JpdGhtcy1saXN0IG1haWxpbmcgbGlzdA0KVEY+IEdEQWxnb3JpdGhtcy1saXN0QGxpc3Rz LnNvdXJjZWZvcmdlLm5ldA0KVEY+IGh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xp c3RzL2xpc3RpbmZvL2dkYWxnb3JpdGhtcy1saXN0DQpURj4gQXJjaGl2ZXM6DQpURj4gaHR0 cDovL3NvdXJjZWZvcmdlLm5ldC9tYWlsYXJjaGl2ZS9mb3J1bS5waHA/Zm9ydW1faWRhODgN Cg0KDQoNCi0tIA0KQmVzdCByZWdhcmRzLA0KIEdyZWcgICAgICAgICAgICAgICAgICAgICAg ICAgICAgbWFpbHRvOmdoamVsc3Ryb21AbHZjbS5jb20NCg== |
From: Jonathan B. <jo...@nu...> - 2004-08-28 16:26:20
|
Greg Hjelstrom wrote: >How do you guys handle the case where objects overlap the boundary >between multiple shadow buffers? For example in Tom's GDC demo he >had chunks of the "terrain" mesh affected by separate shadow >maps meaning that arbitrarily changing chunks of terrain have to be >drawn separately. This seems like a fairly big problem to me but >maybe I'm missing a simple solution? > > Using the cascading shadow maps, I always render an object with two shadow maps enabled (one is the smaller shadow map, inside the bigger one) and blend between them at the transition (though actually right now I just switch between textures with a hard line, but it's pretty much fine and I might leave it that way -- means I don't require a blend texture or alpha channel). Which two maps I use depends on how big/far-away the object is. The down-side to this is that the size of an object controls the max resolution shadow that can land on it, which means to receive highest-res close-up shadows, an object can't be gigantic. This is only a slight problem in my current system and I suspect I can just boost the resolution of the nearest shadow maps and the problem will go away. TF> I do think PSM/TSM methods are useful, but they're tweaks and optimisations TF> to whatever higher-level method you use to solve the multi-frustum problem. TF> Maybe you can get a bit more performance in the average case (and if you TF> have lots of lights, the non-average case is only going to happen to one of TF> them at a time, so it's certainly worthwhile). In my current game, I am only worried about sunlight. Given that, a single set of cascading maps completely solves the problem. 4 or 5 shadow maps is all I need for a *big* world. So there's just no incentive for me to bother even thinking about PSM any more. And frankly I am happy about that. If I were dealing with a lot of small lights, I might think about it, but I suspect that I still wouldn't like them. There are a lot of negative quality trade-offs involved in PSM (like inherent shadow crawling). TF> I still don't have a robust solution to the problem of the changing frustums TF> causing jitter. The "persistent" case I presented at GDC does a lot to help TF> it, but it's not a 100% solution. Because I've only done it in cheesy demo TF> apps, I'm still not sure what percentage of cases it lets jitter through. So TF> it's the one big problem I have left (but then again, every other technique TF> has it too, so I don't feel all that bad :-) Not the cascading maps with a parallel light source! Non-animated objects have absolutely no jitter; their shadows are nailed rock-solid to the scene. Moving stuff, well, what can you do; but the fact that the shadow itself is moving makes a little bit of edge motion acceptable. For a point source, you can do some things to minimize it, but I think leveraging shadow antialiasing is also key there. |
From: Tom F. <tom...@ee...> - 2004-08-28 17:17:38
|
It's a problem if your chunks are too big to fit in a single SB frustum. = I think this is why Jon doesn't keep using smaller and smaller shadow = buffers as he gets closer to the viewer - his smallest SB is easily big = enough to hold the largest object. There's two cases here - casters and receivers. Usually objects are = both, but it's good to think of them is two separate phases. Rendering casters is easy. You can render any casters to any SB frustum. = Worst that happens is it gets clipped off the edge and you wasted some = geometry (so hey - you need better culling). But that object casts = perfect shadows into that frustum. So there's no problems with objects = that cast really long or large shadows that cross multiple SBs - you = just render them each to every SB they intersect, and it all works. So the problem comes if you want to render a shadow receiver with more = than one SB, because you can't make a single SB to fit it. This doesn't = actually happen all that much because I deliberately choose my SBs so = that they include big objects first, then try ot fit the smaller ones in = around it. So you don't choose your frustums than worry about fitting = objects into them (like saying "I use a cubemap"), you choose your = frustums so that objects fit into them. When this does happen, the easiest solution I can think of is to chop = the object up with user clip planes and put each chunk into its own SB. = Another version would be to pre-chop (offline) the object into half, = then each part into half again, etc - and at runtime you keep doing this = until one part does fit into an SB. But I haven't actually tried either = of these because for StarTopia (a) retrofitting this would be pretty = evil and (b) it's so rare that you can usually just not shadow the = object and it looks fine. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Greg Hjelstrom > Sent: 28 August 2004 08:32 > To: Tom Forsyth > Subject: Re[2]: [Algorithms] General-purpose shadowbuffer=20 > implementation. >=20 >=20 > How do you guys handle the case where objects overlap the boundary > between multiple shadow buffers? For example in Tom's GDC demo he > had chunks of the "terrain" mesh affected by separate shadow > maps meaning that arbitrarily changing chunks of terrain have to be > drawn separately. This seems like a fairly big problem to me but > maybe I'm missing a simple solution? >=20 > Greg Hjelstrom >=20 >=20 > Friday, August 27, 2004, 10:10:56 PM, you wrote: >=20 > >> This is exactly the problem with PSMs and TSMs: Depending on=20 > >> where you=20 > >> point the camera, they are often no better than standard=20 > >> shadow maps. =20 > >> So if I have to deal with making my scene look good in this=20 > >> case, and I=20 > >> succeed, then I might as well throw away all the PSM and TSM stuff. >=20 > TF> Hurrah! Jon joins me in the place of nirvana! Well, not=20 > quite, but it's the > TF> revelation that "none of this single-buffer crap is going to solve > TF> everything" that frees you from the stupid mathematical=20 > distractions of > TF> thinking about obscure projections and concentrates the=20 > mind on solving the > TF> _actual_ problem, which is how to allocate multiple shadowbuffer. >=20 > TF> I do think PSM/TSM methods are useful, but they're tweaks=20 > and optimisations > TF> to whatever higher-level method you use to solve the=20 > multi-frustum problem. > TF> Maybe you can get a bit more performance in the average=20 > case (and if you > TF> have lots of lights, the non-average case is only going=20 > to happen to one of > TF> them at a time, so it's certainly worthwhile). They're=20 > not, in themselves, a > TF> solution. >=20 > TF> I still don't have a robust solution to the problem of=20 > the changing frustums > TF> causing jitter. The "persistent" case I presented at GDC=20 > does a lot to help > TF> it, but it's not a 100% solution. Because I've only done=20 > it in cheesy demo > TF> apps, I'm still not sure what percentage of cases it lets=20 > jitter through. So > TF> it's the one big problem I have left (but then again,=20 > every other technique > TF> has it too, so I don't feel all that bad :-) >=20 > TF> Must write my algo up... >=20 > TF> TomF. >=20 >=20 > >> -----Original Message----- > >> From: gda...@li...=20 > >> [mailto:gda...@li...] On=20 > >> Behalf Of Jonathan Blow > >> Sent: 27 August 2004 12:00 > >> To: gda...@li... > >> Subject: Re: [Algorithms] General-purpose shadowbuffer=20 > implementation. > >>=20 > >>=20 > >> This is exactly the problem with PSMs and TSMs: Depending on=20 > >> where you=20 > >> point the camera, they are often no better than standard=20 > >> shadow maps. =20 > >> So if I have to deal with making my scene look good in this=20 > >> case, and I=20 > >> succeed, then I might as well throw away all the PSM and TSM stuff. > >>=20 > >> In fact it often makes the scene look a lot uglier, as the=20 > resolution=20 > >> jitters around while the camera rotates. It just doesn't=20 > feel solid. > >>=20 > >> I guess PSM and TSM might have good uses in batch=20 > rendering where you=20 > >> are splatting zillions of shadow maps per frame at real high=20 > >> resolution=20 > >> and you can do this kind of case by case thing and it doesn't=20 > >> matter. =20 > >> But I just don't see them as being useful for a real-time=20 > game that=20 > >> wants high-quality shadows, not any time soon, anyway. > >>=20 > >> (Though if there's a demo out there that uses these kind of=20 > >> systems that=20 > >> solves the real-world problems that happen in a game, I'd=20 > be eager to=20 > >> see it. And I'd buy the author a beer -- I sure as hell=20 > could never=20 > >> make PSM or TSM look good, and I tried a lot.) > >>=20 > >> -Jonathan. > >>=20 > >>=20 > >> Gary King wrote: > >>=20 > >> >I've nearly finished implementing a minor variation on TSMs=20 > >> in my PSM demo (I still need to implement a=20 > >> dynamically-computed focus region; however, I've been able to=20 > >> manually adapt the focus region to generate nice shadows=20 > >> everywhere I've tried). > >> > > >> >Like LSPSMs, the only degeneracy is an easily-handled=20 > >> uninteresting case (squeezing >N% of the frustum below the=20 > >> "N% line"), which makes nicer than PSMs in that regard. > >> > > >> >A huge view frustum isn't really a problem for TSMs; no more=20 > >> so than uniform shadow maps, anyway. The worst-case behavior=20 > >> for TSMs is when the view frustum(/trapezoid) is fat; in this=20 > >> case, the best behavior is to fall back toward uniform shadow=20 > >> maps (set the 80/20 split to 80/20). > >> > > >> >As far as the PSM quality in the video; it's been my=20 > >> experience that PSMs (especially Stamminger & Drettakis PSMs,=20 > >> as opposed to LSPSMs or Kozlov PSMs) can get into a number of=20 > >> situations where they look significantly worse than uniform=20 > >> shadow maps; particularly in large scenes with rough bounding=20 > >> box approximations. In these cases, the post-projective view=20 > >> box could have significant wastage (unnecessary bits of the=20 > >> scene), and when the light is close to the view-box the large=20 > >> FoV causes quite a bit of compression even close to the=20 > >> viewer. This was the primary reason why my demo forces a=20 > >> minimum distance between the infinity plane and the view-box. > >> > > >> >-----Original Message----- > >> >From: gda...@li... > >> >[mailto:gda...@li...]On=20 > >> Behalf Of Tom > >> >Forsyth > >> >Sent: Friday, August 27, 2004 2:13 AM > >> >To: gda...@li... > >> >Subject: RE: [Algorithms] General-purpose shadowbuffer=20 > >> implementation. > >> > > >> > > >> >Goodnes - loads of emails off-list, none on-list. Come on=20 > >> people - don't be > >> >shy! > >> > > >> >Anyway, due to popular demand I will do a wbe page or a post=20 > >> about the > >> >implementation details. > >> > > >> > > >> > > >> >So I was reading the Trapezoidal Shadow Map paper that=20 > >> everyone was talking > >> >about ages ago. http://www.comp.nus.edu.sg/~tants/tsm.html =20 > >> Yeah, I'm slow. > >> >It's interesting reading - it's basically a smarter version=20 > >> of PSM from what > >> >I can see - selecting a better warping for the shadowmap=20 > >> that minimises > >> >texel wastage. They take the camera frustum and draw it in=20 > >> the light's space > >> >(clipping as necessary). Then they approximate that with a=20 > >> trapezoid. And > >> >then they find a 4x4 projection matrix that maps that to the=20 > >> unit square. > >> >And that's your shadowbuffer projection. > >> > > >> >So by definition it doesn't have the divide-by-zero problems=20 > >> that PSMs have > >> >because all your thinking is done in the light's frustum,=20 > >> and by definition > >> >if something is outside the light's frustum, it's not lit=20 > >> 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=20 > >> light, camera or > >> >objects doesn't cause a large change in the trapezoidal=20 > >> approximation, and > >> >therefore the mapping always changes smoothly, which solves=20 > >> some of the > >> >abrupt popping of most shadowbuffer methods. (actually,=20 > objects are > >> >irrelevant, unlike PSM, because TSM doesn't consider them at=20 > >> all - just > >> >camera frustum and light). > >> > > >> >(The paper also has some interesting (but orthogonal)=20 > >> comments about picking > >> >a depth epsilon to try to reduce surface acne and=20 > >> peterpanning, and how a > >> >trapezoidal projection makes this a lot worse and how to=20 > >> make it not so bad > >> >by de-projecting the epsilon in the shader. But I'm an=20 > >> ID/priority fanboy, > >> >so I just skimmed that bit) > >> > > >> >So it's all great for distant lights and shortish view=20 > >> distances. But it > >> >seems like there's a pretty glaring hole in the algorithm.=20 > >> If your view is > >> >any decent distance compared to the light, and the light is=20 > >> not a nice > >> >narrow-cone spotlight (so you can just clip off the large=20 > >> bits of the view > >> >frustum), then your view frustum in light space is huge. So=20 > >> your trapezoid > >> >approximation doesn't help you much. Also, it doesn't seem=20 > >> to help the > >> >duelling frustum case at all that I can see (because I don't=20 > >> believe there > >> >_is_ a way to solve that with a single buffer projected with=20 > >> a simple 4x4 > >> >matrix). > >> > > >> >However, there's the stuff about the 80/20 mix that I don't=20 > >> fully understand > >> >- maybe that somehow compensates for large far-clip-plane=20 > >> distances. But who > >> >uses a far clip plane that isn't basically infinite these=20 > >> days? The only > >> >case I can think of is corridor shooters, and 90% of your=20 > >> lights there are > >> >very close to the view frustum, so again - minimal gain from=20 > >> TSM (in a > >> >corridor shooter, apart from the omnidirection-light=20 > >> problem, which is a > >> >different kettle of fish altogether, you can pretty easily=20 > >> get away with > >> >dumb BB shadowbuffers because the change in texel density=20 > is fairly > >> >moderate, unlike something like the sun outdoors). > >> > > >> >So it seems like it's better than PSM for some cases, but=20 > >> doesn't solve any > >> >of the real-world cases (duelling frustums), and as far=20 > as I can see, > >> >pushing the far clip plane out to sensible distances causes=20 > >> it lots of > >> >trouble. > >> > > >> >I also don't understand the videos - their PSM=20 > >> implementation seems to be > >> >performing terribly - far worse than I'd expect. There's no=20 > >> reason I can see > >> >that it should ever be _worse_ than the relatively dumb BB=20 > >> case. Another > >> >(rather more minor) quibble I have is that if one of the=20 > >> Cool Features about > >> >TSM is that the changes in mapping are continuous, so you=20 > might get > >> >aliasing, but you never get pops, then pick a buffer=20 > >> resoloution that is low > >> >enough to show me the texels not-popping. They've picked one=20 > >> where I can't > >> >actually see any texels, so they could be popping every=20 > >> single frame and > >> >you'd never know it. > >> > > >> > > >> >Has anyone actually tried this stuff in a real game? Or has=20 > >> the experience > >> >of PSMs put everyone off wacky projections for life? I know=20 > >> I'm a lot more > >> >wary about investing time in this stuff after that (hey -=20 > >> that's why I'm > >> >posting this message :-). > >> > > >> > > >> >TomF. > >> > > >> > > >> > =20 > >> > > >> >>-----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=20 > implementation. > >> >> > >> >> > >> >>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). > >> >> > >> >>If you want to actually run it, you need a copy of the=20 > >> 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) > >> >> > >> >>http://www.eelpi.gotdns.org/startopia/startopia.html > >> >> > >> >>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. > >> >> =20 > >> >> > >> > > >> ><snip> > >> > > >> > > >> > > >> >------------------------------------------------------- > >> >SF.Net email is sponsored by Shop4tech.com-Lowest price on=20 > >> Blank Media > >> >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > >> >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > >> >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > >> >_______________________________________________ > >> >GDAlgorithms-list mailing list > >> >GDA...@li... > >> >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >> >Archives: > >> >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >> > > >> > > >> >------------------------------------------------------- > >> >This SF.Net email is sponsored by BEA Weblogic Workshop > >> >FREE Java Enterprise J2EE developer tools! > >> >Get your free copy of BEA WebLogic Workshop 8.1 today. > >> >http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=C3=8Ck > >> >_______________________________________________ > >> >GDAlgorithms-list mailing list > >> >GDA...@li... > >> >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >> >Archives: > >> >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >> > > >> > =20 > >> > > >>=20 > >>=20 > >>=20 > >> ------------------------------------------------------- > >> This SF.Net email is sponsored by BEA Weblogic Workshop > >> FREE Java Enterprise J2EE developer tools! > >> Get your free copy of BEA WebLogic Workshop 8.1 today. > >> http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick > >> _______________________________________________ > >> GDAlgorithms-list mailing list > >> GDA...@li... > >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >> Archives: > >> http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >>=20 >=20 >=20 >=20 > TF> ------------------------------------------------------- > TF> This SF.Net email is sponsored by BEA Weblogic Workshop > TF> FREE Java Enterprise J2EE developer tools! > TF> Get your free copy of BEA WebLogic Workshop 8.1 today. > TF> http://ads.osdn.com/?ad_idP47&alloc_id=10808&oplick > TF> _______________________________________________ > TF> GDAlgorithms-list mailing list > TF> GDA...@li... > TF> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > TF> Archives: > TF> http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 >=20 >=20 > --=20 > Best regards, > Greg mailto:ghj...@lv... > = NH=C2=B5=C5=A0=C2=B2=C2=B2u=10n=E2=80=B0=C2=AE=C2=A2=10=C2=BD=C2=B5=C2=AE= 'u=E2=80=93=C2=AE=E2=80=93=C2=B7=C2=ADy=C3=8A=10l=E2=80=B0=C2=AE=C2=A2=C2= =B6=C3=8A=C2=A7vv=E2=80=BA=E2=80=A0=C3=9Bi=C3=BF=C3=BB(=C2=BA=C2=B7=1E~=C5= =A0=C3=A0zw=C2=AD=C3=BEf=C2=A2=E2=80=A2=C2=AA=C3=9C=E2=80=A0+=C3=9E=C3=BD= =C3=BA > +=C2=BAja=C2=A5=C3=BA+=C2=BAh=C2=9D=03=C2=AD| >=20 |
From: Jonathan B. <jo...@nu...> - 2004-08-28 22:39:43
|
Tom Forsyth wrote: >It's a problem if your chunks are too big to fit in a single SB frustum.= I think this is why Jon doesn't keep using smaller and smaller shadow bu= ffers as he gets closer to the viewer - his smallest SB is easily big eno= ugh to hold the largest object. > > =20 > Yeah, in mine, an object doesn't actually have to fit into one shadow=20 map, but it has to fit into two. So my smallest SB is not actually big=20 enough to hold the largest object, but my next biggest one is (and must=20 be, for things to work right).=20 I don't have a separate light/shadow-drawing pass (as one might have in=20 an engine with many light sources simultaneously), so I am fitting the=20 shadow evaluation into the same shader program as all the other lighting=20 stuff for an object. Right now I only have hardware for 8 textures at=20 once, and no dynamic branches. So I have two shadow textures, sample=20 them both (single sample right now), and throw one of the samples away. On the eventual target platform (which will be the best card I can buy=20 around late November), I'll have dynamic branching and hopefully more=20 texture slots (newer cards go over 8 right?). So probably, I will have=20 3 textures loaded at once, and use a dynamic branch to determine which=20 one to multisample. [I had been sweeping the dynamic branch idea under the rug because I've=20 heard so many horror stories about how slow it is. But nvidia has this=20 paper recommending doing it instead of sampling a texture a bunch of=20 times, so I figure hey, why not.] Given all this, I will probably add one more resolution for stuff=20 reeeeally close to the viewer, which will help take care of surface acne=20 stuff on human-sized characters. -J. >There's two cases here - casters and receivers. Usually objects are both= , but it's good to think of them is two separate phases. > >Rendering casters is easy. You can render any casters to any SB frustum.= Worst that happens is it gets clipped off the edge and you wasted some g= eometry (so hey - you need better culling). But that object casts perfect= shadows into that frustum. So there's no problems with objects that cast= really long or large shadows that cross multiple SBs - you just render t= hem each to every SB they intersect, and it all works. > >So the problem comes if you want to render a shadow receiver with more t= han one SB, because you can't make a single SB to fit it. This doesn't ac= tually happen all that much because I deliberately choose my SBs so that = they include big objects first, then try ot fit the smaller ones in aroun= d it. So you don't choose your frustums than worry about fitting objects = into them (like saying "I use a cubemap"), you choose your frustums so th= at objects fit into them. > > >When this does happen, the easiest solution I can think of is to chop th= e object up with user clip planes and put each chunk into its own SB. Ano= ther version would be to pre-chop (offline) the object into half, then ea= ch part into half again, etc - and at runtime you keep doing this until o= ne part does fit into an SB. But I haven't actually tried either of these= because for StarTopia (a) retrofitting this would be pretty evil and (b)= it's so rare that you can usually just not shadow the object and it look= s fine. > > >TomF. > > > =20 > >>-----Original Message----- >>From: gda...@li...=20 >>[mailto:gda...@li...] On=20 >>Behalf Of Greg Hjelstrom >>Sent: 28 August 2004 08:32 >>To: Tom Forsyth >>Subject: Re[2]: [Algorithms] General-purpose shadowbuffer=20 >>implementation. >> >> >>How do you guys handle the case where objects overlap the boundary >>between multiple shadow buffers? For example in Tom's GDC demo he >>had chunks of the "terrain" mesh affected by separate shadow >>maps meaning that arbitrarily changing chunks of terrain have to be >>drawn separately. This seems like a fairly big problem to me but >>maybe I'm missing a simple solution? >> >>Greg Hjelstrom >> >> >>Friday, August 27, 2004, 10:10:56 PM, you wrote: >> >> =20 >> >>>>This is exactly the problem with PSMs and TSMs: Depending on=20 >>>>where you=20 >>>>point the camera, they are often no better than standard=20 >>>>shadow maps. =20 >>>>So if I have to deal with making my scene look good in this=20 >>>>case, and I=20 >>>>succeed, then I might as well throw away all the PSM and TSM stuff. >>>> =20 >>>> >>TF> Hurrah! Jon joins me in the place of nirvana! Well, not=20 >>quite, but it's the >>TF> revelation that "none of this single-buffer crap is going to solve >>TF> everything" that frees you from the stupid mathematical=20 >>distractions of >>TF> thinking about obscure projections and concentrates the=20 >>mind on solving the >>TF> _actual_ problem, which is how to allocate multiple shadowbuffer. >> >>TF> I do think PSM/TSM methods are useful, but they're tweaks=20 >>and optimisations >>TF> to whatever higher-level method you use to solve the=20 >>multi-frustum problem. >>TF> Maybe you can get a bit more performance in the average=20 >>case (and if you >>TF> have lots of lights, the non-average case is only going=20 >>to happen to one of >>TF> them at a time, so it's certainly worthwhile). They're=20 >>not, in themselves, a >>TF> solution. >> >>TF> I still don't have a robust solution to the problem of=20 >>the changing frustums >>TF> causing jitter. The "persistent" case I presented at GDC=20 >>does a lot to help >>TF> it, but it's not a 100% solution. Because I've only done=20 >>it in cheesy demo >>TF> apps, I'm still not sure what percentage of cases it lets=20 >>jitter through. So >>TF> it's the one big problem I have left (but then again,=20 >>every other technique >>TF> has it too, so I don't feel all that bad :-) >> >>TF> Must write my algo up... >> >>TF> TomF. >> >> >> =20 >> >>>>-----Original Message----- >>>>From: gda...@li...=20 >>>>[mailto:gda...@li...] On=20 >>>>Behalf Of Jonathan Blow >>>>Sent: 27 August 2004 12:00 >>>>To: gda...@li... >>>>Subject: Re: [Algorithms] General-purpose shadowbuffer=20 >>>> =20 >>>> >>implementation. >> =20 >> >>>>This is exactly the problem with PSMs and TSMs: Depending on=20 >>>>where you=20 >>>>point the camera, they are often no better than standard=20 >>>>shadow maps. =20 >>>>So if I have to deal with making my scene look good in this=20 >>>>case, and I=20 >>>>succeed, then I might as well throw away all the PSM and TSM stuff. >>>> >>>>In fact it often makes the scene look a lot uglier, as the=20 >>>> =20 >>>> >>resolution=20 >> =20 >> >>>>jitters around while the camera rotates. It just doesn't=20 >>>> =20 >>>> >>feel solid. >> =20 >> >>>>I guess PSM and TSM might have good uses in batch=20 >>>> =20 >>>> >>rendering where you=20 >> =20 >> >>>>are splatting zillions of shadow maps per frame at real high=20 >>>>resolution=20 >>>>and you can do this kind of case by case thing and it doesn't=20 >>>>matter. =20 >>>>But I just don't see them as being useful for a real-time=20 >>>> =20 >>>> >>game that=20 >> =20 >> >>>>wants high-quality shadows, not any time soon, anyway. >>>> >>>>(Though if there's a demo out there that uses these kind of=20 >>>>systems that=20 >>>>solves the real-world problems that happen in a game, I'd=20 >>>> =20 >>>> >>be eager to=20 >> =20 >> >>>>see it. And I'd buy the author a beer -- I sure as hell=20 >>>> =20 >>>> >>could never=20 >> =20 >> >>>>make PSM or TSM look good, and I tried a lot.) >>>> >>>> -Jonathan. >>>> >>>> >>>>Gary King wrote: >>>> >>>> =20 >>>> >>>>>I've nearly finished implementing a minor variation on TSMs=20 >>>>> =20 >>>>> >>>>in my PSM demo (I still need to implement a=20 >>>>dynamically-computed focus region; however, I've been able to=20 >>>>manually adapt the focus region to generate nice shadows=20 >>>>everywhere I've tried). >>>> =20 >>>> >>>>>Like LSPSMs, the only degeneracy is an easily-handled=20 >>>>> =20 >>>>> >>>>uninteresting case (squeezing >N% of the frustum below the=20 >>>>"N% line"), which makes nicer than PSMs in that regard. >>>> =20 >>>> >>>>>A huge view frustum isn't really a problem for TSMs; no more=20 >>>>> =20 >>>>> >>>>so than uniform shadow maps, anyway. The worst-case behavior=20 >>>>for TSMs is when the view frustum(/trapezoid) is fat; in this=20 >>>>case, the best behavior is to fall back toward uniform shadow=20 >>>>maps (set the 80/20 split to 80/20). >>>> =20 >>>> >>>>>As far as the PSM quality in the video; it's been my=20 >>>>> =20 >>>>> >>>>experience that PSMs (especially Stamminger & Drettakis PSMs,=20 >>>>as opposed to LSPSMs or Kozlov PSMs) can get into a number of=20 >>>>situations where they look significantly worse than uniform=20 >>>>shadow maps; particularly in large scenes with rough bounding=20 >>>>box approximations. In these cases, the post-projective view=20 >>>>box could have significant wastage (unnecessary bits of the=20 >>>>scene), and when the light is close to the view-box the large=20 >>>>FoV causes quite a bit of compression even close to the=20 >>>>viewer. This was the primary reason why my demo forces a=20 >>>>minimum distance between the infinity plane and the view-box. >>>> =20 >>>> >>>>>-----Original Message----- >>>>>From: gda...@li... >>>>>[mailto:gda...@li...]On=20 >>>>> =20 >>>>> >>>>Behalf Of Tom >>>> =20 >>>> >>>>>Forsyth >>>>>Sent: Friday, August 27, 2004 2:13 AM >>>>>To: gda...@li... >>>>>Subject: RE: [Algorithms] General-purpose shadowbuffer=20 >>>>> =20 >>>>> >>>>implementation. >>>> =20 >>>> >>>>>Goodnes - loads of emails off-list, none on-list. Come on=20 >>>>> =20 >>>>> >>>>people - don't be >>>> =20 >>>> >>>>>shy! >>>>> >>>>>Anyway, due to popular demand I will do a wbe page or a post=20 >>>>> =20 >>>>> >>>>about the >>>> =20 >>>> >>>>>implementation details. >>>>> >>>>> >>>>> >>>>>So I was reading the Trapezoidal Shadow Map paper that=20 >>>>> =20 >>>>> >>>>everyone was talking >>>> =20 >>>> >>>>>about ages ago. http://www.comp.nus.edu.sg/~tants/tsm.html =20 >>>>> =20 >>>>> >>>>Yeah, I'm slow. >>>> =20 >>>> >>>>>It's interesting reading - it's basically a smarter version=20 >>>>> =20 >>>>> >>>>of PSM from what >>>> =20 >>>> >>>>>I can see - selecting a better warping for the shadowmap=20 >>>>> =20 >>>>> >>>>that minimises >>>> =20 >>>> >>>>>texel wastage. They take the camera frustum and draw it in=20 >>>>> =20 >>>>> >>>>the light's space >>>> =20 >>>> >>>>>(clipping as necessary). Then they approximate that with a=20 >>>>> =20 >>>>> >>>>trapezoid. And >>>> =20 >>>> >>>>>then they find a 4x4 projection matrix that maps that to the=20 >>>>> =20 >>>>> >>>>unit square. >>>> =20 >>>> >>>>>And that's your shadowbuffer projection. >>>>> >>>>>So by definition it doesn't have the divide-by-zero problems=20 >>>>> =20 >>>>> >>>>that PSMs have >>>> =20 >>>> >>>>>because all your thinking is done in the light's frustum,=20 >>>>> =20 >>>>> >>>>and by definition >>>> =20 >>>> >>>>>if something is outside the light's frustum, it's not lit=20 >>>>> =20 >>>>> >>>>anyway and so >>>> =20 >>>> >>>>>can't be shadowed or cast shadows. So that solves that. >>>>> >>>>>It's also nice that it's continuous - a small movement of=20 >>>>> =20 >>>>> >>>>light, camera or >>>> =20 >>>> >>>>>objects doesn't cause a large change in the trapezoidal=20 >>>>> =20 >>>>> >>>>approximation, and >>>> =20 >>>> >>>>>therefore the mapping always changes smoothly, which solves=20 >>>>> =20 >>>>> >>>>some of the >>>> =20 >>>> >>>>>abrupt popping of most shadowbuffer methods. (actually,=20 >>>>> =20 >>>>> >>objects are >> =20 >> >>>>>irrelevant, unlike PSM, because TSM doesn't consider them at=20 >>>>> =20 >>>>> >>>>all - just >>>> =20 >>>> >>>>>camera frustum and light). >>>>> >>>>>(The paper also has some interesting (but orthogonal)=20 >>>>> =20 >>>>> >>>>comments about picking >>>> =20 >>>> >>>>>a depth epsilon to try to reduce surface acne and=20 >>>>> =20 >>>>> >>>>peterpanning, and how a >>>> =20 >>>> >>>>>trapezoidal projection makes this a lot worse and how to=20 >>>>> =20 >>>>> >>>>make it not so bad >>>> =20 >>>> >>>>>by de-projecting the epsilon in the shader. But I'm an=20 >>>>> =20 >>>>> >>>>ID/priority fanboy, >>>> =20 >>>> >>>>>so I just skimmed that bit) >>>>> >>>>>So it's all great for distant lights and shortish view=20 >>>>> =20 >>>>> >>>>distances. But it >>>> =20 >>>> >>>>>seems like there's a pretty glaring hole in the algorithm.=20 >>>>> =20 >>>>> >>>>If your view is >>>> =20 >>>> >>>>>any decent distance compared to the light, and the light is=20 >>>>> =20 >>>>> >>>>not a nice >>>> =20 >>>> >>>>>narrow-cone spotlight (so you can just clip off the large=20 >>>>> =20 >>>>> >>>>bits of the view >>>> =20 >>>> >>>>>frustum), then your view frustum in light space is huge. So=20 >>>>> =20 >>>>> >>>>your trapezoid >>>> =20 >>>> >>>>>approximation doesn't help you much. Also, it doesn't seem=20 >>>>> =20 >>>>> >>>>to help the >>>> =20 >>>> >>>>>duelling frustum case at all that I can see (because I don't=20 >>>>> =20 >>>>> >>>>believe there >>>> =20 >>>> >>>>>_is_ a way to solve that with a single buffer projected with=20 >>>>> =20 >>>>> >>>>a simple 4x4 >>>> =20 >>>> >>>>>matrix). >>>>> >>>>>However, there's the stuff about the 80/20 mix that I don't=20 >>>>> =20 >>>>> >>>>fully understand >>>> =20 >>>> >>>>>- maybe that somehow compensates for large far-clip-plane=20 >>>>> =20 >>>>> >>>>distances. But who >>>> =20 >>>> >>>>>uses a far clip plane that isn't basically infinite these=20 >>>>> =20 >>>>> >>>>days? The only >>>> =20 >>>> >>>>>case I can think of is corridor shooters, and 90% of your=20 >>>>> =20 >>>>> >>>>lights there are >>>> =20 >>>> >>>>>very close to the view frustum, so again - minimal gain from=20 >>>>> =20 >>>>> >>>>TSM (in a >>>> =20 >>>> >>>>>corridor shooter, apart from the omnidirection-light=20 >>>>> =20 >>>>> >>>>problem, which is a >>>> =20 >>>> >>>>>different kettle of fish altogether, you can pretty easily=20 >>>>> =20 >>>>> >>>>get away with >>>> =20 >>>> >>>>>dumb BB shadowbuffers because the change in texel density=20 >>>>> =20 >>>>> >>is fairly >> =20 >> >>>>>moderate, unlike something like the sun outdoors). >>>>> >>>>>So it seems like it's better than PSM for some cases, but=20 >>>>> =20 >>>>> >>>>doesn't solve any >>>> =20 >>>> >>>>>of the real-world cases (duelling frustums), and as far=20 >>>>> =20 >>>>> >>as I can see, >> =20 >> >>>>>pushing the far clip plane out to sensible distances causes=20 >>>>> =20 >>>>> >>>>it lots of >>>> =20 >>>> >>>>>trouble. >>>>> >>>>>I also don't understand the videos - their PSM=20 >>>>> =20 >>>>> >>>>implementation seems to be >>>> =20 >>>> >>>>>performing terribly - far worse than I'd expect. There's no=20 >>>>> =20 >>>>> >>>>reason I can see >>>> =20 >>>> >>>>>that it should ever be _worse_ than the relatively dumb BB=20 >>>>> =20 >>>>> >>>>case. Another >>>> =20 >>>> >>>>>(rather more minor) quibble I have is that if one of the=20 >>>>> =20 >>>>> >>>>Cool Features about >>>> =20 >>>> >>>>>TSM is that the changes in mapping are continuous, so you=20 >>>>> =20 >>>>> >>might get >> =20 >> >>>>>aliasing, but you never get pops, then pick a buffer=20 >>>>> =20 >>>>> >>>>resoloution that is low >>>> =20 >>>> >>>>>enough to show me the texels not-popping. They've picked one=20 >>>>> =20 >>>>> >>>>where I can't >>>> =20 >>>> >>>>>actually see any texels, so they could be popping every=20 >>>>> =20 >>>>> >>>>single frame and >>>> =20 >>>> >>>>>you'd never know it. >>>>> >>>>> >>>>>Has anyone actually tried this stuff in a real game? Or has=20 >>>>> =20 >>>>> >>>>the experience >>>> =20 >>>> >>>>>of PSMs put everyone off wacky projections for life? I know=20 >>>>> =20 >>>>> >>>>I'm a lot more >>>> =20 >>>> >>>>>wary about investing time in this stuff after that (hey -=20 >>>>> =20 >>>>> >>>>that's why I'm >>>> =20 >>>> >>>>>posting this message :-). >>>>> >>>>> >>>>>TomF. >>>>> >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>>>-----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=20 >>>>>> =20 >>>>>> >>implementation. >> =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). >>>>>> >>>>>>If you want to actually run it, you need a copy of the=20 >>>>>> =20 >>>>>> >>>>game, and then >>>> =20 >>>> >>>>>>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) >>>>>> >>>>>>http://www.eelpi.gotdns.org/startopia/startopia.html >>>>>> >>>>>>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. >>>>>> =20 >>>>>> >>>>>> =20 >>>>>> >>>>><snip> >>>>> >>>>> >>>>> >>>>>------------------------------------------------------- >>>>>SF.Net email is sponsored by Shop4tech.com-Lowest price on=20 >>>>> =20 >>>>> >>>>Blank Media >>>> =20 >>>> >>>>>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >>>>>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >>>>>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >>>>>_______________________________________________ >>>>>GDAlgorithms-list mailing list >>>>>GDA...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>>>Archives: >>>>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 >>>>> >>>>> >>>>>------------------------------------------------------- >>>>>This SF.Net email is sponsored by BEA Weblogic Workshop >>>>>FREE Java Enterprise J2EE developer tools! >>>>>Get your free copy of BEA WebLogic Workshop 8.1 today. >>>>>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=C3=8Ck >>>>>_______________________________________________ >>>>>GDAlgorithms-list mailing list >>>>>GDA...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>>>Archives: >>>>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 >>>>> >>>>>=20 >>>>> >>>>> =20 >>>>> >>>> >>>>------------------------------------------------------- >>>>This SF.Net email is sponsored by BEA Weblogic Workshop >>>>FREE Java Enterprise J2EE developer tools! >>>>Get your free copy of BEA WebLogic Workshop 8.1 today. >>>>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick >>>>_______________________________________________ >>>>GDAlgorithms-list mailing list >>>>GDA...@li... >>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>>>Archives: >>>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 >>>> >>>> =20 >>>> >> >>TF> ------------------------------------------------------- >>TF> This SF.Net email is sponsored by BEA Weblogic Workshop >>TF> FREE Java Enterprise J2EE developer tools! >>TF> Get your free copy of BEA WebLogic Workshop 8.1 today. >>TF> http://ads.osdn.com/?ad_idP47&alloc_id=10808&oplick >>TF> _______________________________________________ >>TF> GDAlgorithms-list mailing list >>TF> GDA...@li... >>TF> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>TF> Archives: >>TF> http://sourceforge.net/mailarchive/forum.php?forum_ida88 >> >> >> >>--=20 >>Best regards, >> Greg mailto:ghj...@lv... >>NH=C2=B5=C5=A0=C2=B2=C2=B2u=10n=E2=80=B0=C2=AE=C2=A2=10=C2=BD=C2=B5=C2=AE= 'u=E2=80=93=C2=AE=E2=80=93=C2=B7=C2=ADy=C3=8A=10l=E2=80=B0=C2=AE=C2=A2=C2= =B6=C3=8A=C2=A7vv=E2=80=BA=E2=80=A0=C3=9Bi=C3=BF=C3=BB(=C2=BA=C2=B7=1E~=C5= =A0=C3=A0zw=C2=AD=C3=BEf=C2=A2=E2=80=A2=C2=AA=C3=9C=E2=80=A0+=C3=9E=C3=BD= =C3=BA >>+=C2=BAja=C2=A5=C3=BA+=C2=BAh=C2=9D=03=C2=AD| >> >> =20 >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > |
From: Jonathan B. <jo...@nu...> - 2004-08-28 22:49:48
|
> > I don't have a separate light/shadow-drawing pass (as one might have > in an engine with many light sources simultaneously), so I am fitting > the shadow evaluation into the same shader program as all the other > lighting stuff for an object. Now that I think about it, if you're going to do specular (and uhh who wouldn't these days) then the old drawing-lights-first approach just doesn't work. So you'd either have to put it all in one shader like I am doing now, or else do "deferred shading"... |
From: Tom F. <tom...@ee...> - 2004-08-29 03:54:38
|
> [I had been sweeping the dynamic branch idea under the rug=20 > because I've=20 > heard so many horror stories about how slow it is. But=20 > nvidia has this=20 > paper recommending doing it instead of sampling a texture a bunch of=20 > times, so I figure hey, why not.] That's not because they do dynamic branches particularly fast, it's = because their current hardware does them slightly less slowly than the = current ATI hardware. This isn't the first time = hardware-advantage-specific advice has been doled out. And previous = examples have had the next rev of the hardware produce exactly the = opposite advice! Let's be careful out there, people. :-( TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Jonathan Blow > Sent: 28 August 2004 15:40 > To: gda...@li... > Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 > Tom Forsyth wrote: >=20 > >It's a problem if your chunks are too big to fit in a single=20 > SB frustum. I think this is why Jon doesn't keep using=20 > smaller and smaller shadow buffers as he gets closer to the=20 > viewer - his smallest SB is easily big enough to hold the=20 > largest object. > > > > =20 > > >=20 > Yeah, in mine, an object doesn't actually have to fit into one shadow=20 > map, but it has to fit into two. So my smallest SB is not=20 > actually big=20 > enough to hold the largest object, but my next biggest one is=20 > (and must=20 > be, for things to work right).=20 >=20 > I don't have a separate light/shadow-drawing pass (as one=20 > might have in=20 > an engine with many light sources simultaneously), so I am=20 > fitting the=20 > shadow evaluation into the same shader program as all the=20 > other lighting=20 > stuff for an object. Right now I only have hardware for 8=20 > textures at=20 > once, and no dynamic branches. So I have two shadow textures, sample=20 > them both (single sample right now), and throw one of the=20 > samples away. >=20 > On the eventual target platform (which will be the best card=20 > I can buy=20 > around late November), I'll have dynamic branching and hopefully more=20 > texture slots (newer cards go over 8 right?). So probably, I=20 > will have=20 > 3 textures loaded at once, and use a dynamic branch to=20 > determine which=20 > one to multisample. >=20 > [I had been sweeping the dynamic branch idea under the rug=20 > because I've=20 > heard so many horror stories about how slow it is. But=20 > nvidia has this=20 > paper recommending doing it instead of sampling a texture a bunch of=20 > times, so I figure hey, why not.] >=20 > Given all this, I will probably add one more resolution for stuff=20 > reeeeally close to the viewer, which will help take care of=20 > surface acne=20 > stuff on human-sized characters. >=20 > -J. >=20 >=20 > >There's two cases here - casters and receivers. Usually=20 > objects are both, but it's good to think of them is two=20 > separate phases. > > > >Rendering casters is easy. You can render any casters to any=20 > SB frustum. Worst that happens is it gets clipped off the=20 > edge and you wasted some geometry (so hey - you need better=20 > culling). But that object casts perfect shadows into that=20 > frustum. So there's no problems with objects that cast really=20 > long or large shadows that cross multiple SBs - you just=20 > render them each to every SB they intersect, and it all works. > > > >So the problem comes if you want to render a shadow receiver=20 > with more than one SB, because you can't make a single SB to=20 > fit it. This doesn't actually happen all that much because I=20 > deliberately choose my SBs so that they include big objects=20 > first, then try ot fit the smaller ones in around it. So you=20 > don't choose your frustums than worry about fitting objects=20 > into them (like saying "I use a cubemap"), you choose your=20 > frustums so that objects fit into them. > > > > > >When this does happen, the easiest solution I can think of=20 > is to chop the object up with user clip planes and put each=20 > chunk into its own SB. Another version would be to pre-chop=20 > (offline) the object into half, then each part into half=20 > again, etc - and at runtime you keep doing this until one=20 > part does fit into an SB. But I haven't actually tried either=20 > of these because for StarTopia (a) retrofitting this would be=20 > pretty evil and (b) it's so rare that you can usually just=20 > not shadow the object and it looks fine. > > > > > >TomF. > > > > > > =20 > > > >>-----Original Message----- > >>From: gda...@li...=20 > >>[mailto:gda...@li...] On=20 > >>Behalf Of Greg Hjelstrom > >>Sent: 28 August 2004 08:32 > >>To: Tom Forsyth > >>Subject: Re[2]: [Algorithms] General-purpose shadowbuffer=20 > >>implementation. > >> > >> > >>How do you guys handle the case where objects overlap the boundary > >>between multiple shadow buffers? For example in Tom's GDC demo he > >>had chunks of the "terrain" mesh affected by separate shadow > >>maps meaning that arbitrarily changing chunks of terrain have to be > >>drawn separately. This seems like a fairly big problem to me but > >>maybe I'm missing a simple solution? > >> > >>Greg Hjelstrom > >> > >> > >>Friday, August 27, 2004, 10:10:56 PM, you wrote: > >> > >> =20 > >> > >>>>This is exactly the problem with PSMs and TSMs: Depending on=20 > >>>>where you=20 > >>>>point the camera, they are often no better than standard=20 > >>>>shadow maps. =20 > >>>>So if I have to deal with making my scene look good in this=20 > >>>>case, and I=20 > >>>>succeed, then I might as well throw away all the PSM and=20 > TSM stuff. > >>>> =20 > >>>> > >>TF> Hurrah! Jon joins me in the place of nirvana! Well, not=20 > >>quite, but it's the > >>TF> revelation that "none of this single-buffer crap is=20 > going to solve > >>TF> everything" that frees you from the stupid mathematical=20 > >>distractions of > >>TF> thinking about obscure projections and concentrates the=20 > >>mind on solving the > >>TF> _actual_ problem, which is how to allocate multiple=20 > shadowbuffer. > >> > >>TF> I do think PSM/TSM methods are useful, but they're tweaks=20 > >>and optimisations > >>TF> to whatever higher-level method you use to solve the=20 > >>multi-frustum problem. > >>TF> Maybe you can get a bit more performance in the average=20 > >>case (and if you > >>TF> have lots of lights, the non-average case is only going=20 > >>to happen to one of > >>TF> them at a time, so it's certainly worthwhile). They're=20 > >>not, in themselves, a > >>TF> solution. > >> > >>TF> I still don't have a robust solution to the problem of=20 > >>the changing frustums > >>TF> causing jitter. The "persistent" case I presented at GDC=20 > >>does a lot to help > >>TF> it, but it's not a 100% solution. Because I've only done=20 > >>it in cheesy demo > >>TF> apps, I'm still not sure what percentage of cases it lets=20 > >>jitter through. So > >>TF> it's the one big problem I have left (but then again,=20 > >>every other technique > >>TF> has it too, so I don't feel all that bad :-) > >> > >>TF> Must write my algo up... > >> > >>TF> TomF. > >> > >> > >> =20 > >> > >>>>-----Original Message----- > >>>>From: gda...@li...=20 > >>>>[mailto:gda...@li...] On=20 > >>>>Behalf Of Jonathan Blow > >>>>Sent: 27 August 2004 12:00 > >>>>To: gda...@li... > >>>>Subject: Re: [Algorithms] General-purpose shadowbuffer=20 > >>>> =20 > >>>> > >>implementation. > >> =20 > >> > >>>>This is exactly the problem with PSMs and TSMs: Depending on=20 > >>>>where you=20 > >>>>point the camera, they are often no better than standard=20 > >>>>shadow maps. =20 > >>>>So if I have to deal with making my scene look good in this=20 > >>>>case, and I=20 > >>>>succeed, then I might as well throw away all the PSM and=20 > TSM stuff. > >>>> > >>>>In fact it often makes the scene look a lot uglier, as the=20 > >>>> =20 > >>>> > >>resolution=20 > >> =20 > >> > >>>>jitters around while the camera rotates. It just doesn't=20 > >>>> =20 > >>>> > >>feel solid. > >> =20 > >> > >>>>I guess PSM and TSM might have good uses in batch=20 > >>>> =20 > >>>> > >>rendering where you=20 > >> =20 > >> > >>>>are splatting zillions of shadow maps per frame at real high=20 > >>>>resolution=20 > >>>>and you can do this kind of case by case thing and it doesn't=20 > >>>>matter. =20 > >>>>But I just don't see them as being useful for a real-time=20 > >>>> =20 > >>>> > >>game that=20 > >> =20 > >> > >>>>wants high-quality shadows, not any time soon, anyway. > >>>> > >>>>(Though if there's a demo out there that uses these kind of=20 > >>>>systems that=20 > >>>>solves the real-world problems that happen in a game, I'd=20 > >>>> =20 > >>>> > >>be eager to=20 > >> =20 > >> > >>>>see it. And I'd buy the author a beer -- I sure as hell=20 > >>>> =20 > >>>> > >>could never=20 > >> =20 > >> > >>>>make PSM or TSM look good, and I tried a lot.) > >>>> > >>>> -Jonathan. > >>>> > >>>> > >>>>Gary King wrote: > >>>> > >>>> =20 > >>>> > >>>>>I've nearly finished implementing a minor variation on TSMs=20 > >>>>> =20 > >>>>> > >>>>in my PSM demo (I still need to implement a=20 > >>>>dynamically-computed focus region; however, I've been able to=20 > >>>>manually adapt the focus region to generate nice shadows=20 > >>>>everywhere I've tried). > >>>> =20 > >>>> > >>>>>Like LSPSMs, the only degeneracy is an easily-handled=20 > >>>>> =20 > >>>>> > >>>>uninteresting case (squeezing >N% of the frustum below the=20 > >>>>"N% line"), which makes nicer than PSMs in that regard. > >>>> =20 > >>>> > >>>>>A huge view frustum isn't really a problem for TSMs; no more=20 > >>>>> =20 > >>>>> > >>>>so than uniform shadow maps, anyway. The worst-case behavior=20 > >>>>for TSMs is when the view frustum(/trapezoid) is fat; in this=20 > >>>>case, the best behavior is to fall back toward uniform shadow=20 > >>>>maps (set the 80/20 split to 80/20). > >>>> =20 > >>>> > >>>>>As far as the PSM quality in the video; it's been my=20 > >>>>> =20 > >>>>> > >>>>experience that PSMs (especially Stamminger & Drettakis PSMs,=20 > >>>>as opposed to LSPSMs or Kozlov PSMs) can get into a number of=20 > >>>>situations where they look significantly worse than uniform=20 > >>>>shadow maps; particularly in large scenes with rough bounding=20 > >>>>box approximations. In these cases, the post-projective view=20 > >>>>box could have significant wastage (unnecessary bits of the=20 > >>>>scene), and when the light is close to the view-box the large=20 > >>>>FoV causes quite a bit of compression even close to the=20 > >>>>viewer. This was the primary reason why my demo forces a=20 > >>>>minimum distance between the infinity plane and the view-box. > >>>> =20 > >>>> > >>>>>-----Original Message----- > >>>>>From: gda...@li... > >>>>>[mailto:gda...@li...]On=20 > >>>>> =20 > >>>>> > >>>>Behalf Of Tom > >>>> =20 > >>>> > >>>>>Forsyth > >>>>>Sent: Friday, August 27, 2004 2:13 AM > >>>>>To: gda...@li... > >>>>>Subject: RE: [Algorithms] General-purpose shadowbuffer=20 > >>>>> =20 > >>>>> > >>>>implementation. > >>>> =20 > >>>> > >>>>>Goodnes - loads of emails off-list, none on-list. Come on=20 > >>>>> =20 > >>>>> > >>>>people - don't be > >>>> =20 > >>>> > >>>>>shy! > >>>>> > >>>>>Anyway, due to popular demand I will do a wbe page or a post=20 > >>>>> =20 > >>>>> > >>>>about the > >>>> =20 > >>>> > >>>>>implementation details. > >>>>> > >>>>> > >>>>> > >>>>>So I was reading the Trapezoidal Shadow Map paper that=20 > >>>>> =20 > >>>>> > >>>>everyone was talking > >>>> =20 > >>>> > >>>>>about ages ago. http://www.comp.nus.edu.sg/~tants/tsm.html =20 > >>>>> =20 > >>>>> > >>>>Yeah, I'm slow. > >>>> =20 > >>>> > >>>>>It's interesting reading - it's basically a smarter version=20 > >>>>> =20 > >>>>> > >>>>of PSM from what > >>>> =20 > >>>> > >>>>>I can see - selecting a better warping for the shadowmap=20 > >>>>> =20 > >>>>> > >>>>that minimises > >>>> =20 > >>>> > >>>>>texel wastage. They take the camera frustum and draw it in=20 > >>>>> =20 > >>>>> > >>>>the light's space > >>>> =20 > >>>> > >>>>>(clipping as necessary). Then they approximate that with a=20 > >>>>> =20 > >>>>> > >>>>trapezoid. And > >>>> =20 > >>>> > >>>>>then they find a 4x4 projection matrix that maps that to the=20 > >>>>> =20 > >>>>> > >>>>unit square. > >>>> =20 > >>>> > >>>>>And that's your shadowbuffer projection. > >>>>> > >>>>>So by definition it doesn't have the divide-by-zero problems=20 > >>>>> =20 > >>>>> > >>>>that PSMs have > >>>> =20 > >>>> > >>>>>because all your thinking is done in the light's frustum,=20 > >>>>> =20 > >>>>> > >>>>and by definition > >>>> =20 > >>>> > >>>>>if something is outside the light's frustum, it's not lit=20 > >>>>> =20 > >>>>> > >>>>anyway and so > >>>> =20 > >>>> > >>>>>can't be shadowed or cast shadows. So that solves that. > >>>>> > >>>>>It's also nice that it's continuous - a small movement of=20 > >>>>> =20 > >>>>> > >>>>light, camera or > >>>> =20 > >>>> > >>>>>objects doesn't cause a large change in the trapezoidal=20 > >>>>> =20 > >>>>> > >>>>approximation, and > >>>> =20 > >>>> > >>>>>therefore the mapping always changes smoothly, which solves=20 > >>>>> =20 > >>>>> > >>>>some of the > >>>> =20 > >>>> > >>>>>abrupt popping of most shadowbuffer methods. (actually,=20 > >>>>> =20 > >>>>> > >>objects are > >> =20 > >> > >>>>>irrelevant, unlike PSM, because TSM doesn't consider them at=20 > >>>>> =20 > >>>>> > >>>>all - just > >>>> =20 > >>>> > >>>>>camera frustum and light). > >>>>> > >>>>>(The paper also has some interesting (but orthogonal)=20 > >>>>> =20 > >>>>> > >>>>comments about picking > >>>> =20 > >>>> > >>>>>a depth epsilon to try to reduce surface acne and=20 > >>>>> =20 > >>>>> > >>>>peterpanning, and how a > >>>> =20 > >>>> > >>>>>trapezoidal projection makes this a lot worse and how to=20 > >>>>> =20 > >>>>> > >>>>make it not so bad > >>>> =20 > >>>> > >>>>>by de-projecting the epsilon in the shader. But I'm an=20 > >>>>> =20 > >>>>> > >>>>ID/priority fanboy, > >>>> =20 > >>>> > >>>>>so I just skimmed that bit) > >>>>> > >>>>>So it's all great for distant lights and shortish view=20 > >>>>> =20 > >>>>> > >>>>distances. But it > >>>> =20 > >>>> > >>>>>seems like there's a pretty glaring hole in the algorithm.=20 > >>>>> =20 > >>>>> > >>>>If your view is > >>>> =20 > >>>> > >>>>>any decent distance compared to the light, and the light is=20 > >>>>> =20 > >>>>> > >>>>not a nice > >>>> =20 > >>>> > >>>>>narrow-cone spotlight (so you can just clip off the large=20 > >>>>> =20 > >>>>> > >>>>bits of the view > >>>> =20 > >>>> > >>>>>frustum), then your view frustum in light space is huge. So=20 > >>>>> =20 > >>>>> > >>>>your trapezoid > >>>> =20 > >>>> > >>>>>approximation doesn't help you much. Also, it doesn't seem=20 > >>>>> =20 > >>>>> > >>>>to help the > >>>> =20 > >>>> > >>>>>duelling frustum case at all that I can see (because I don't=20 > >>>>> =20 > >>>>> > >>>>believe there > >>>> =20 > >>>> > >>>>>_is_ a way to solve that with a single buffer projected with=20 > >>>>> =20 > >>>>> > >>>>a simple 4x4 > >>>> =20 > >>>> > >>>>>matrix). > >>>>> > >>>>>However, there's the stuff about the 80/20 mix that I don't=20 > >>>>> =20 > >>>>> > >>>>fully understand > >>>> =20 > >>>> > >>>>>- maybe that somehow compensates for large far-clip-plane=20 > >>>>> =20 > >>>>> > >>>>distances. But who > >>>> =20 > >>>> > >>>>>uses a far clip plane that isn't basically infinite these=20 > >>>>> =20 > >>>>> > >>>>days? The only > >>>> =20 > >>>> > >>>>>case I can think of is corridor shooters, and 90% of your=20 > >>>>> =20 > >>>>> > >>>>lights there are > >>>> =20 > >>>> > >>>>>very close to the view frustum, so again - minimal gain from=20 > >>>>> =20 > >>>>> > >>>>TSM (in a > >>>> =20 > >>>> > >>>>>corridor shooter, apart from the omnidirection-light=20 > >>>>> =20 > >>>>> > >>>>problem, which is a > >>>> =20 > >>>> > >>>>>different kettle of fish altogether, you can pretty easily=20 > >>>>> =20 > >>>>> > >>>>get away with > >>>> =20 > >>>> > >>>>>dumb BB shadowbuffers because the change in texel density=20 > >>>>> =20 > >>>>> > >>is fairly > >> =20 > >> > >>>>>moderate, unlike something like the sun outdoors). > >>>>> > >>>>>So it seems like it's better than PSM for some cases, but=20 > >>>>> =20 > >>>>> > >>>>doesn't solve any > >>>> =20 > >>>> > >>>>>of the real-world cases (duelling frustums), and as far=20 > >>>>> =20 > >>>>> > >>as I can see, > >> =20 > >> > >>>>>pushing the far clip plane out to sensible distances causes=20 > >>>>> =20 > >>>>> > >>>>it lots of > >>>> =20 > >>>> > >>>>>trouble. > >>>>> > >>>>>I also don't understand the videos - their PSM=20 > >>>>> =20 > >>>>> > >>>>implementation seems to be > >>>> =20 > >>>> > >>>>>performing terribly - far worse than I'd expect. There's no=20 > >>>>> =20 > >>>>> > >>>>reason I can see > >>>> =20 > >>>> > >>>>>that it should ever be _worse_ than the relatively dumb BB=20 > >>>>> =20 > >>>>> > >>>>case. Another > >>>> =20 > >>>> > >>>>>(rather more minor) quibble I have is that if one of the=20 > >>>>> =20 > >>>>> > >>>>Cool Features about > >>>> =20 > >>>> > >>>>>TSM is that the changes in mapping are continuous, so you=20 > >>>>> =20 > >>>>> > >>might get > >> =20 > >> > >>>>>aliasing, but you never get pops, then pick a buffer=20 > >>>>> =20 > >>>>> > >>>>resoloution that is low > >>>> =20 > >>>> > >>>>>enough to show me the texels not-popping. They've picked one=20 > >>>>> =20 > >>>>> > >>>>where I can't > >>>> =20 > >>>> > >>>>>actually see any texels, so they could be popping every=20 > >>>>> =20 > >>>>> > >>>>single frame and > >>>> =20 > >>>> > >>>>>you'd never know it. > >>>>> > >>>>> > >>>>>Has anyone actually tried this stuff in a real game? Or has=20 > >>>>> =20 > >>>>> > >>>>the experience > >>>> =20 > >>>> > >>>>>of PSMs put everyone off wacky projections for life? I know=20 > >>>>> =20 > >>>>> > >>>>I'm a lot more > >>>> =20 > >>>> > >>>>>wary about investing time in this stuff after that (hey -=20 > >>>>> =20 > >>>>> > >>>>that's why I'm > >>>> =20 > >>>> > >>>>>posting this message :-). > >>>>> > >>>>> > >>>>>TomF. > >>>>> > >>>>> > >>>>>=20 > >>>>> > >>>>> =20 > >>>>> > >>>>>>-----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=20 > >>>>>> =20 > >>>>>> > >>implementation. > >> =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). > >>>>>> > >>>>>>If you want to actually run it, you need a copy of the=20 > >>>>>> =20 > >>>>>> > >>>>game, and then > >>>> =20 > >>>> > >>>>>>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) > >>>>>> > >>>>>>http://www.eelpi.gotdns.org/startopia/startopia.html > >>>>>> > >>>>>>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. > >>>>>> =20 > >>>>>> > >>>>>> =20 > >>>>>> > >>>>><snip> > >>>>> > >>>>> > >>>>> > >>>>>------------------------------------------------------- > >>>>>SF.Net email is sponsored by Shop4tech.com-Lowest price on=20 > >>>>> =20 > >>>>> > >>>>Blank Media > >>>> =20 > >>>> > >>>>>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > >>>>>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > >>>>>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > >>>>>_______________________________________________ > >>>>>GDAlgorithms-list mailing list > >>>>>GDA...@li... > >>>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >>>>>Archives: > >>>>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >>>>> > >>>>> > >>>>>------------------------------------------------------- > >>>>>This SF.Net email is sponsored by BEA Weblogic Workshop > >>>>>FREE Java Enterprise J2EE developer tools! > >>>>>Get your free copy of BEA WebLogic Workshop 8.1 today. > >>>>>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=C3=8Ck > >>>>>_______________________________________________ > >>>>>GDAlgorithms-list mailing list > >>>>>GDA...@li... > >>>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >>>>>Archives: > >>>>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >>>>> > >>>>>=20 > >>>>> > >>>>> =20 > >>>>> > >>>> > >>>>------------------------------------------------------- > >>>>This SF.Net email is sponsored by BEA Weblogic Workshop > >>>>FREE Java Enterprise J2EE developer tools! > >>>>Get your free copy of BEA WebLogic Workshop 8.1 today. > >>>>http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick > >>>>_______________________________________________ > >>>>GDAlgorithms-list mailing list > >>>>GDA...@li... > >>>>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >>>>Archives: > >>>>http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >>>> > >>>> =20 > >>>> > >> > >>TF> ------------------------------------------------------- > >>TF> This SF.Net email is sponsored by BEA Weblogic Workshop > >>TF> FREE Java Enterprise J2EE developer tools! > >>TF> Get your free copy of BEA WebLogic Workshop 8.1 today. > >>TF> http://ads.osdn.com/?ad_idP47&alloc_id=10808&oplick > >>TF> _______________________________________________ > >>TF> GDAlgorithms-list mailing list > >>TF> GDA...@li... > >>TF> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >>TF> Archives: > >>TF> http://sourceforge.net/mailarchive/forum.php?forum_ida88 > >> > >> > >> > >>--=20 > >>Best regards, > >> Greg mailto:ghj...@lv... > = >>NH=C2=B5=C5=A0=C2=B2=C2=B2u=10n=E2=80=B0=C2=AE=C2=A2=10=C2=BD=C2=B5=C2=AE= 'u=E2=80=93=C2=AE=E2=80=93=C2=B7=C2=ADy=C3=8A=10l=E2=80=B0=C2=AE=C2=A2=C2= =B6=C3=8A=C2=A7vv=E2=80=BA=E2=80=A0=C3=9Bi=C3=BF=C3=BB(=C2=BA=C2=B7=1E~=C5= =A0=C3=A0zw=C2=AD=C3=BEf=C2=A2=E2=80=A2=C2=AA=C3=9C=E2=80=A0+=C3=9E=C3=BD= =C3=BA > >>+=C2=BAja=C2=A5=C3=BA+=C2=BAh=C2=9D=03=C2=AD| > >> > >> =20 > >> > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by BEA Weblogic Workshop > >FREE Java Enterprise J2EE developer tools! > >Get your free copy of BEA WebLogic Workshop 8.1 today. > >_______________________________________________ > >GDAlgorithms-list mailing list > >GDA...@li... > >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > >Archives: > >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > > > =20 > > >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |
From: <c.s...@ph...> - 2004-08-28 10:46:09
|
I believe the cascade approach is the only useful solution available = today that works well in a general case. It comes with the prize of = rendering multiple maps, but you only need it for the large outdoor = sunlight. What gives me more headaches is many small local lights, like torches on = walls for instance. Since they are attached to something, most of them could be bounded with = a light cone of 180=B0, so they are hemispherical. This would make them = suitable for a single pass paraboloid map. Even slightly larger cones = like 200=B0 could be fitted onto a single paraboloid map. But the = geometry of the buildings would need to be tesselated really high for = the nonlinear projection to work. I want to avoid rendering multiple shadow map faces per light source. If = I go shadow volume, I could have omnidirectional shadows for local = lights in a single pass always. But shadow volumes would need a = completely different pipeline on top of the existing one. So if anyone knows the Miracle Worker (tm), I'd like to know ... -----Original Message----- From: gda...@li... on behalf of = Jonathan Blow Sent: Fri 8/27/2004 5:20 PM To: gda...@li... Cc:=09 Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. Before the TSM paper came out (I think; before I heard of it, anyway) I=20 was doing all kinds of things in that area, after being very frustrated=20 at PSM. My general M.O. was to think about the shadow map as being a=20 surface in world space, and then build an arbitrary transform by mapping = 4 points in world space to 4 points in projective space. (Or 3 points=20 and a vector, for parallel light sources). There are a whole bunch of=20 strategies you can explore about how to choose the 4 points, which=20 becomes a generalization of PSM, TSM, etc. They all suck. -snip |
From: Tom F. <tom...@ee...> - 2004-08-28 15:40:55
|
> but you only need=20 > it for the large outdoor sunlight. Untrue. You need it any time there is a significant change in the light<->object distance or the camera<->object distance. If your light = is the sun, the first one is constant, and yes - you only _need_ it for = large scenes (though it can optimise smaller scenes). But if your lights are local, you need it a lot. > I want to avoid rendering multiple shadow map faces per light=20 > source. But why? It's really not very expensive, it just "feels" like it is. = There's three main costs to it: -Changing render targets -Rendering shadow casters to multiple targets (only happens to a small fraction of objects, but it's a cost) -Rendering with multiple render targets, i.e. a texture switch. The first one used to be a killer - but it's become a lot cheaper these days. And if you use a decent wrapper library that allocates a few = larger rendertargets and then partitions them into smaller ones (I use a = quadtree allocator - very easy to write), you actually don't change rendertarget = or texture all that much. So the real cost is the extra rendering. Two parts to this - fillrate = and geometry processing. The idea of choosing your SBs well is to only pick = them as big as you have to. So if you do that, you minimise the fillrate. If = you could reduce the fillrate even more, you would have picked smaller SBs, right? If you had used paraboloid maps or something like that, they = still need the same texel density. So still the same number of texels, and = thus the same fillrate. So the geometry cost - as you point out, the = alternative is massive tessellation to cope with the curvature of a parapoloid map. = Far cheaper just to render the thing two or three times. Paraboloids might avoid the seam problems slightly better. But only if = you can always use a single one, and I claim that you can't. The problem is = that you still haven't solved the duelling frustums problem! So again, you = either need the whole thing to have huge resoloution, or you suffer Big Texel Syndrome on things that are close to the camera. TomF. > -----Original Message----- > From: Christian Sch=FCler=20 > [mailto:gda...@li...] On=20 > Behalf Of Christian Sch=FCler > Sent: 28 August 2004 03:38 > To: gda...@li... > Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 >=20 > I believe the cascade approach is the only useful solution=20 > available today that works well in a general case. It comes=20 > with the prize of rendering multiple maps, but you only need=20 > it for the large outdoor sunlight. >=20 > What gives me more headaches is many small local lights, like=20 > torches on walls for instance. >=20 > Since they are attached to something, most of them could be=20 > bounded with a light cone of 180=B0, so they are hemispherical.=20 > This would make them suitable for a single pass paraboloid=20 > map. Even slightly larger cones like 200=B0 could be fitted=20 > onto a single paraboloid map. But the geometry of the=20 > buildings would need to be tesselated really high for the=20 > nonlinear projection to work. >=20 > I want to avoid rendering multiple shadow map faces per light=20 > source. If I go shadow volume, I could have omnidirectional=20 > shadows for local lights in a single pass always. But shadow=20 > volumes would need a completely different pipeline on top of=20 > the existing one. >=20 > So if anyone knows the Miracle Worker (tm), I'd like to know ... >=20 >=20 > -----Original Message----- > From: gda...@li... on behalf=20 > of Jonathan Blow > Sent: Fri 8/27/2004 5:20 PM > To: gda...@li... > Cc:=09 > Subject: Re: [Algorithms] General-purpose shadowbuffer=20 > implementation. > Before the TSM paper came out (I think; before I heard of it,=20 > anyway) I=20 > was doing all kinds of things in that area, after being very=20 > frustrated=20 > at PSM. My general M.O. was to think about the shadow map as being a=20 > surface in world space, and then build an arbitrary transform=20 > by mapping=20 > 4 points in world space to 4 points in projective space. (Or=20 > 3 points=20 > and a vector, for parallel light sources). There are a whole=20 > bunch of=20 > strategies you can explore about how to choose the 4 points, which=20 > becomes a generalization of PSM, TSM, etc. They all suck. >=20 > -snip >=20 >=20 |
From: Jonathan B. <jo...@nu...> - 2004-08-28 16:11:50
|
>Paraboloids might avoid the seam problems slightly better. But only if you >can always use a single one, and I claim that you can't. The problem is that >you still haven't solved the duelling frustums problem! So again, you either >need the whole thing to have huge resoloution, or you suffer Big Texel >Syndrome on things that are close to the camera. > > > The hyperbolic map solves duelling frustums, since there is no light frustum. I would assume the paraboloid thing can work the same way. There would still be a seam though, since you need a back-plane to handle all the shadows going away from the viewer. |
From: Tom F. <tom...@ee...> - 2004-08-28 17:22:08
|
I meant they don't solve that case, not that the frustums actually duel. = If you're looking at a light, rendering with a paraboloid map (I assume = it's used in the same sense as a cube-map, but without the multiple chunks) = means that you have too many texels near to the light and too few near the = camera. That's what I mean by the duelling frustum case. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Jonathan Blow > Sent: 28 August 2004 09:11 > To: gda...@li... > Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 >=20 > >Paraboloids might avoid the seam problems slightly better.=20 > But only if you > >can always use a single one, and I claim that you can't. The=20 > problem is that > >you still haven't solved the duelling frustums problem! So=20 > again, you either > >need the whole thing to have huge resoloution, or you suffer=20 > Big Texel > >Syndrome on things that are close to the camera. > > > > =20 > > >=20 > The hyperbolic map solves duelling frustums, since there is no light=20 > frustum. I would assume the paraboloid thing can work the same way. =20 > There would still be a seam though, since you need a back-plane to=20 > handle all the shadows going away from the viewer. |
From: Jonathan B. <jo...@nu...> - 2004-08-28 22:32:50
|
Tom Forsyth wrote: >I meant they don't solve that case, not that the frustums actually duel. If >you're looking at a light, rendering with a paraboloid map (I assume it's >used in the same sense as a cube-map, but without the multiple chunks) means >that you have too many texels near to the light and too few near the camera. >That's what I mean by the duelling frustum case. > > Okay, I get what you're saying. The thing is though, once you've decided to use a paraboloid, there's no point in worrying about things like linearity any more. At which point, you can throw some kind of warping function onto the surface of the paraboloid to try and account for perspective. Since the paraboloid is easily parameterized, you ought to be able to map the distortion to something pretty close to the right answer, and thus beat duelling frustums. That's what I was thinking anyway, but I didn't think about it too hard. The view-dependant hyperbola on the other hand basically gives you the exact warping function that you want no matter what, which is why I would do that instead of a hyperbola, except hey, I can't render curved surfaces. (And honestly, trying to tessellate geometry to the degree that would be necessary is basically a losing proposition -- you'd need a crazy triangle density.) |
From: Tom F. <tom...@ee...> - 2004-08-29 03:49:31
|
So my fundamental point about all these cunning warps is you're trying = to find the 3D-2D mapping that does the best thing. The problem is, the = domain you're trying to cover is fundamentally 3D. Imagine a volume filled with spheres that are quite small and don't = touch, so that they can cast shadows on each other, and you can see a majority = of the spheres. This case is the one that says to me that the problem is a = 3D one - you are trying to find a mapping for the shadowbuffer that fills = this volume. But that's asking a 2D surface to fill a volume - can't be done unless you can throw away a dimension. The problem is, the only one you = can throw away and maintain even texel density is along the camera's Z axis. = But the only one you are _allowed_ to throw away is the one radiating out = from the light (that's why it's a shadowmap :-) This says to me that trying to find a single mapping is doomed, no = matter how clever your tech. But maybe my intuition is leading me astray. I think if you want to find one that maps onto something like a ground = plane with good texel density, then maybe you can do it with some odd = warpings. But that doesn't cover the general case. Admittedly, it covers a lot of outdoor game cases, so it might still be useful. But it's not general-purpose. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Jonathan Blow > Sent: 28 August 2004 15:33 > To: gda...@li... > Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 > Tom Forsyth wrote: >=20 > >I meant they don't solve that case, not that the frustums=20 > actually duel. If > >you're looking at a light, rendering with a paraboloid map=20 > (I assume it's > >used in the same sense as a cube-map, but without the=20 > multiple chunks) means > >that you have too many texels near to the light and too few=20 > near the camera. > >That's what I mean by the duelling frustum case. > > =20 > > >=20 > Okay, I get what you're saying. The thing is though, once you've=20 > decided to use a paraboloid, there's no point in worrying=20 > about things=20 > like linearity any more. At which point, you can throw some kind of=20 > warping function onto the surface of the paraboloid to try=20 > and account=20 > for perspective. Since the paraboloid is easily parameterized, you=20 > ought to be able to map the distortion to something pretty=20 > close to the=20 > right answer, and thus beat duelling frustums. That's what I was=20 > thinking anyway, but I didn't think about it too hard. >=20 > The view-dependant hyperbola on the other hand basically=20 > gives you the=20 > exact warping function that you want no matter what, which is why I=20 > would do that instead of a hyperbola, except hey, I can't=20 > render curved=20 > surfaces. (And honestly, trying to tessellate geometry to the degree=20 > that would be necessary is basically a losing proposition --=20 > you'd need=20 > a crazy triangle density.) >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 |
From: Jonathan B. <jo...@nu...> - 2004-08-29 05:04:13
|
I think you're making the problem too hard. It's okay if some things deep in the scene accidentally get=20 high-resolution shadows, as long as the reason that high resolution=20 patch exists, is because someone near in the scene needed it. In this=20 case, resolution is not being wasted, it's just that someone deep in the=20 scene fortuitously landed in a spot where they lucked out and got a bonus. i.e. your goal is to give a *minimum* resolution to each of those points=20 in the scene, without wasting shadow buffer resolution. But that's not=20 the same as constraining the resolution of each point in the scene,=20 because the resolution is free to be above minimum. So, the problem is=20 easier. In the hyperbolic mapping, there is enough shadow buffer resolution to=20 cover every projector from the light source, at the point of nearest=20 resolution. As you cast a line through the frustum, of course the=20 needed resolution is going to vary (in the general case). The=20 hyperbolic mapping solves for the maximum resolution, then provides that=20 resolution for the entire projector. So, the problem is made into a 2D one and is solvable. -J. Tom Forsyth wrote: >So my fundamental point about all these cunning warps is you're trying t= o >find the 3D-2D mapping that does the best thing. The problem is, the dom= ain >you're trying to cover is fundamentally 3D. > >Imagine a volume filled with spheres that are quite small and don't touc= h, >so that they can cast shadows on each other, and you can see a majority = of >the spheres. This case is the one that says to me that the problem is a = 3D >one - you are trying to find a mapping for the shadowbuffer that fills t= his >volume. But that's asking a 2D surface to fill a volume - can't be done >unless you can throw away a dimension. The problem is, the only one you = can >throw away and maintain even texel density is along the camera's Z axis.= But >the only one you are _allowed_ to throw away is the one radiating out fr= om >the light (that's why it's a shadowmap :-) > >This says to me that trying to find a single mapping is doomed, no matte= r >how clever your tech. But maybe my intuition is leading me astray. > >I think if you want to find one that maps onto something like a ground p= lane >with good texel density, then maybe you can do it with some odd warpings. >But that doesn't cover the general case. Admittedly, it covers a lot of >outdoor game cases, so it might still be useful. But it's not >general-purpose. > >TomF. > > > =20 > >>-----Original Message----- >>From: gda...@li...=20 >>[mailto:gda...@li...] On=20 >>Behalf Of Jonathan Blow >>Sent: 28 August 2004 15:33 >>To: gda...@li... >>Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >> >> >>Tom Forsyth wrote: >> >> =20 >> >>>I meant they don't solve that case, not that the frustums=20 >>> =20 >>> >>actually duel. If >> =20 >> >>>you're looking at a light, rendering with a paraboloid map=20 >>> =20 >>> >>(I assume it's >> =20 >> >>>used in the same sense as a cube-map, but without the=20 >>> =20 >>> >>multiple chunks) means >> =20 >> >>>that you have too many texels near to the light and too few=20 >>> =20 >>> >>near the camera. >> =20 >> >>>That's what I mean by the duelling frustum case. >>>=20 >>> >>> =20 >>> >>Okay, I get what you're saying. The thing is though, once you've=20 >>decided to use a paraboloid, there's no point in worrying=20 >>about things=20 >>like linearity any more. At which point, you can throw some kind of=20 >>warping function onto the surface of the paraboloid to try=20 >>and account=20 >>for perspective. Since the paraboloid is easily parameterized, you=20 >>ought to be able to map the distortion to something pretty=20 >>close to the=20 >>right answer, and thus beat duelling frustums. That's what I was=20 >>thinking anyway, but I didn't think about it too hard. >> >>The view-dependant hyperbola on the other hand basically=20 >>gives you the=20 >>exact warping function that you want no matter what, which is why I=20 >>would do that instead of a hyperbola, except hey, I can't=20 >>render curved=20 >>surfaces. (And honestly, trying to tessellate geometry to the degree=20 >>that would be necessary is basically a losing proposition --=20 >>you'd need=20 >>a crazy triangle density.) >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by BEA Weblogic Workshop >>FREE Java Enterprise J2EE developer tools! >>Get your free copy of BEA WebLogic Workshop 8.1 today. >>http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick >>_______________________________________________ >>GDAlgorithms-list mailing list >>GDA...@li... >>https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>Archives: >>http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >> >> =20 >> > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > |
From: Jonathan B. <jo...@nu...> - 2004-08-29 05:22:05
|
One other thing I want to clarify is that the hyperbolic mapping doesn't=20 fall into the class of "odd warpings". It is actually an analytical=20 solution that provides the Right Answer. (I was discussing Odd Warpings=20 in the realm of the parabolic thing we were talking about earlier, in=20 order to make it more like the hyperbolic case, but it's sort of the=20 difference between a hack and the Right Thing). The job of the hyperbola is just to provide an approximation of the view=20 frustum that can be stated in closed form, that is easy to intersect=20 lines with, and that doesn't blow up to crazy resolution at the near=20 plane. You intersect the projectors from the light source with that=20 hyperbola. This gives you 2 intersection points in the general case. =20 You pick the one with the lowest positive z-distance to the camera, then=20 you divide by that z to warp the uv map. So it's a lot more sensible, and less arbitrary, than may have seemed=20 from the offhand way I was talking about it... -J. Jonathan Blow wrote: > I think you're making the problem too hard. > > It's okay if some things deep in the scene accidentally get=20 > high-resolution shadows, as long as the reason that high resolution=20 > patch exists, is because someone near in the scene needed it. In this=20 > case, resolution is not being wasted, it's just that someone deep in=20 > the scene fortuitously landed in a spot where they lucked out and got=20 > a bonus. > > i.e. your goal is to give a *minimum* resolution to each of those=20 > points in the scene, without wasting shadow buffer resolution. But=20 > that's not the same as constraining the resolution of each point in=20 > the scene, because the resolution is free to be above minimum. So,=20 > the problem is easier. > > In the hyperbolic mapping, there is enough shadow buffer resolution to=20 > cover every projector from the light source, at the point of nearest=20 > resolution. As you cast a line through the frustum, of course the=20 > needed resolution is going to vary (in the general case). The=20 > hyperbolic mapping solves for the maximum resolution, then provides=20 > that resolution for the entire projector. > > So, the problem is made into a 2D one and is solvable. > > -J. > > > Tom Forsyth wrote: > >> So my fundamental point about all these cunning warps is you're=20 >> trying to >> find the 3D-2D mapping that does the best thing. The problem is, the=20 >> domain >> you're trying to cover is fundamentally 3D. >> >> Imagine a volume filled with spheres that are quite small and don't=20 >> touch, >> so that they can cast shadows on each other, and you can see a=20 >> majority of >> the spheres. This case is the one that says to me that the problem is=20 >> a 3D >> one - you are trying to find a mapping for the shadowbuffer that=20 >> fills this >> volume. But that's asking a 2D surface to fill a volume - can't be don= e >> unless you can throw away a dimension. The problem is, the only one=20 >> you can >> throw away and maintain even texel density is along the camera's Z=20 >> axis. But >> the only one you are _allowed_ to throw away is the one radiating out=20 >> from >> the light (that's why it's a shadowmap :-) >> >> This says to me that trying to find a single mapping is doomed, no=20 >> matter >> how clever your tech. But maybe my intuition is leading me astray. >> >> I think if you want to find one that maps onto something like a=20 >> ground plane >> with good texel density, then maybe you can do it with some odd=20 >> warpings. >> But that doesn't cover the general case. Admittedly, it covers a lot o= f >> outdoor game cases, so it might still be useful. But it's not >> general-purpose. >> >> TomF. >> >> >> =20 >> >>> -----Original Message----- >>> From: gda...@li...=20 >>> [mailto:gda...@li...] On Behalf Of=20 >>> Jonathan Blow >>> Sent: 28 August 2004 15:33 >>> To: gda...@li... >>> Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >>> >>> >>> Tom Forsyth wrote: >>> >>> =20 >>> >>>> I meant they don't solve that case, not that the frustums =20 >>> >>> actually duel. If >>> =20 >>> >>>> you're looking at a light, rendering with a paraboloid map =20 >>> >>> (I assume it's >>> =20 >>> >>>> used in the same sense as a cube-map, but without the =20 >>> >>> multiple chunks) means >>> =20 >>> >>>> that you have too many texels near to the light and too few =20 >>> >>> near the camera. >>> =20 >>> >>>> That's what I mean by the duelling frustum case. >>>> >>>> >>>> =20 >>> >>> Okay, I get what you're saying. The thing is though, once you've=20 >>> decided to use a paraboloid, there's no point in worrying about=20 >>> things like linearity any more. At which point, you can throw some=20 >>> kind of warping function onto the surface of the paraboloid to try=20 >>> and account for perspective. Since the paraboloid is easily=20 >>> parameterized, you ought to be able to map the distortion to=20 >>> something pretty close to the right answer, and thus beat duelling=20 >>> frustums. That's what I was thinking anyway, but I didn't think=20 >>> about it too hard. >>> >>> The view-dependant hyperbola on the other hand basically gives you=20 >>> the exact warping function that you want no matter what, which is=20 >>> why I would do that instead of a hyperbola, except hey, I can't=20 >>> render curved surfaces. (And honestly, trying to tessellate=20 >>> geometry to the degree that would be necessary is basically a losing=20 >>> proposition -- you'd need a crazy triangle density.) >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by BEA Weblogic Workshop >>> FREE Java Enterprise J2EE developer tools! >>> Get your free copy of BEA WebLogic Workshop 8.1 today. >>> http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick >>> _______________________________________________ >>> GDAlgorithms-list mailing list >>> GDA...@li... >>> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >>> Archives: >>> http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >>> >>> =20 >> >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by BEA Weblogic Workshop >> FREE Java Enterprise J2EE developer tools! >> Get your free copy of BEA WebLogic Workshop 8.1 today. >> http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk >> _______________________________________________ >> GDAlgorithms-list mailing list >> GDA...@li... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_ida88 >> >> =20 >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=CCk > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 > |
From: <c.s...@ph...> - 2004-08-28 16:23:59
|
I need to save the batch count, as the game is already CPU limited. = Switching render targets and issuing draw calls is all CPU work, and DX = doesn't help with stellar batch performance. A local light attached to a = building probably is going to draw the whole building into all shadowmap = faces unless I implement some sub-object division. Geometry count is not = the problem, and fillrate is also not a problem (Besides, fillrate is = never a problem, because if you're fillrate limited, tell your user to = run a lower resolution :-) Btw, how are you going to render a cube map from a render target atlas, = without a specialized pixel shader? -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of Tom = Forsyth Sent: Saturday, August 28, 2004 5:41 PM To: gda...@li... Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. > but you only need > it for the large outdoor sunlight. Untrue. You need it any time there is a significant change in the = light<->object distance or the camera<->object distance. If your light = is the sun, the first one is constant, and yes - you only _need_ it for = large scenes (though it can optimise smaller scenes). But if your lights = are local, you need it a lot. > I want to avoid rendering multiple shadow map faces per light > source. But why? It's really not very expensive, it just "feels" like it is. = There's three main costs to it: -Changing render targets -Rendering shadow casters to multiple targets (only happens to a small = fraction of objects, but it's a cost) -Rendering with multiple render targets, i.e. a texture switch. The first one used to be a killer - but it's become a lot cheaper these = days. And if you use a decent wrapper library that allocates a few = larger rendertargets and then partitions them into smaller ones (I use a = quadtree allocator - very easy to write), you actually don't change = rendertarget or texture all that much. So the real cost is the extra rendering. Two parts to this - fillrate = and geometry processing. The idea of choosing your SBs well is to only = pick them as big as you have to. So if you do that, you minimise the = fillrate. If you could reduce the fillrate even more, you would have = picked smaller SBs, right? If you had used paraboloid maps or something = like that, they still need the same texel density. So still the same = number of texels, and thus the same fillrate. So the geometry cost - as = you point out, the alternative is massive tessellation to cope with the = curvature of a parapoloid map. Far cheaper just to render the thing two = or three times. Paraboloids might avoid the seam problems slightly better. But only if = you can always use a single one, and I claim that you can't. The problem = is that you still haven't solved the duelling frustums problem! So = again, you either need the whole thing to have huge resoloution, or you = suffer Big Texel Syndrome on things that are close to the camera. TomF. |
From: Tom F. <tom...@ee...> - 2004-08-28 17:24:43
|
> Btw, how are you going to render a cube map from a render=20 > target atlas, without a specialized pixel shader? You don't, you render it as n textures. You don't want an actual cube = map anyway, because usually you want different texel densities on different sides. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Christian Sch=FCler > Sent: 28 August 2004 09:16 > To: gda...@li... > Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 >=20 > I need to save the batch count, as the game is already CPU=20 > limited. Switching render targets and issuing draw calls is=20 > all CPU work, and DX doesn't help with stellar batch=20 > performance. A local light attached to a building probably is=20 > going to draw the whole building into all shadowmap faces=20 > unless I implement some sub-object division. Geometry count=20 > is not the problem, and fillrate is also not a problem=20 > (Besides, fillrate is never a problem, because if you're=20 > fillrate limited, tell your user to run a lower resolution :-) >=20 > Btw, how are you going to render a cube map from a render=20 > target atlas, without a specialized pixel shader? >=20 > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Tom Forsyth > Sent: Saturday, August 28, 2004 5:41 PM > To: gda...@li... > Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 > > but you only need > > it for the large outdoor sunlight. >=20 > Untrue. You need it any time there is a significant change in=20 > the light<->object distance or the camera<->object distance.=20 > If your light is the sun, the first one is constant, and yes=20 > - you only _need_ it for large scenes (though it can optimise=20 > smaller scenes). But if your lights are local, you need it a lot. >=20 > > I want to avoid rendering multiple shadow map faces per light > > source. >=20 > But why? It's really not very expensive, it just "feels" like=20 > it is. There's three main costs to it: >=20 > -Changing render targets >=20 > -Rendering shadow casters to multiple targets (only happens=20 > to a small fraction of objects, but it's a cost) >=20 > -Rendering with multiple render targets, i.e. a texture switch. >=20 >=20 > The first one used to be a killer - but it's become a lot=20 > cheaper these days. And if you use a decent wrapper library=20 > that allocates a few larger rendertargets and then partitions=20 > them into smaller ones (I use a quadtree allocator - very=20 > easy to write), you actually don't change rendertarget or=20 > texture all that much. >=20 > So the real cost is the extra rendering. Two parts to this -=20 > fillrate and geometry processing. The idea of choosing your=20 > SBs well is to only pick them as big as you have to. So if=20 > you do that, you minimise the fillrate. If you could reduce=20 > the fillrate even more, you would have picked smaller SBs,=20 > right? If you had used paraboloid maps or something like=20 > that, they still need the same texel density. So still the=20 > same number of texels, and thus the same fillrate. So the=20 > geometry cost - as you point out, the alternative is massive=20 > tessellation to cope with the curvature of a parapoloid map.=20 > Far cheaper just to render the thing two or three times. >=20 > Paraboloids might avoid the seam problems slightly better.=20 > But only if you can always use a single one, and I claim that=20 > you can't. The problem is that you still haven't solved the=20 > duelling frustums problem! So again, you either need the=20 > whole thing to have huge resoloution, or you suffer Big Texel=20 > Syndrome on things that are close to the camera. >=20 >=20 > TomF. >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 >=20 |
From: Sim D. <SDi...@nv...> - 2004-08-28 20:11:07
|
"The first one used to be a killer - but it's become a lot cheaper these = days. And if you use a decent wrapper library that allocates a few = larger rendertargets and then partitions them into smaller ones (I use a = quadtree allocator - very easy to write), you actually don't change = rendertarget or texture all that much." This was key to getting my version of this up to speed - put many shadow = maps on the same texture render target. To solve the problem of lack of sub-rect clamping, what I did was to use = a separate clamped black & white texture to prevent multiple shadows = from leaking on to the scene. Another thing I'd recommend is not solving a harder problem than you = have to. If your lights don't move ( and most don't ) - burn the = occlusion term into a unique texture ( like a lightmap ) for static = shadows. Dynamic shadows can still be done for dynamic objects via = shadow map approaches. -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of Tom = Forsyth Sent: Saturday, August 28, 2004 8:41 AM To: gda...@li... Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. > but you only need > it for the large outdoor sunlight. Untrue. You need it any time there is a significant change in the = light<->object distance or the camera<->object distance. If your light = is the sun, the first one is constant, and yes - you only _need_ it for = large scenes (though it can optimise smaller scenes). But if your lights = are local, you need it a lot. > I want to avoid rendering multiple shadow map faces per light > source. But why? It's really not very expensive, it just "feels" like it is. = There's three main costs to it: -Changing render targets -Rendering shadow casters to multiple targets (only happens to a small = fraction of objects, but it's a cost) -Rendering with multiple render targets, i.e. a texture switch. The first one used to be a killer - but it's become a lot cheaper these = days. And if you use a decent wrapper library that allocates a few = larger rendertargets and then partitions them into smaller ones (I use a = quadtree allocator - very easy to write), you actually don't change = rendertarget or texture all that much. So the real cost is the extra rendering. Two parts to this - fillrate = and geometry processing. The idea of choosing your SBs well is to only = pick them as big as you have to. So if you do that, you minimise the = fillrate. If you could reduce the fillrate even more, you would have = picked smaller SBs, right? If you had used paraboloid maps or something = like that, they still need the same texel density. So still the same = number of texels, and thus the same fillrate. So the geometry cost - as = you point out, the alternative is massive tessellation to cope with the = curvature of a parapoloid map. Far cheaper just to render the thing two = or three times. Paraboloids might avoid the seam problems slightly better. But only if = you can always use a single one, and I claim that you can't. The problem = is that you still haven't solved the duelling frustums problem! So = again, you either need the whole thing to have huge resoloution, or you = suffer Big Texel Syndrome on things that are close to the camera. TomF. > -----Original Message----- > From: Christian Sch=FCler > [mailto:gda...@li...] On=20 > Behalf Of Christian Sch=FCler > Sent: 28 August 2004 03:38 > To: gda...@li... > Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 >=20 > I believe the cascade approach is the only useful solution > available today that works well in a general case. It comes=20 > with the prize of rendering multiple maps, but you only need=20 > it for the large outdoor sunlight. >=20 > What gives me more headaches is many small local lights, like > torches on walls for instance. >=20 > Since they are attached to something, most of them could be > bounded with a light cone of 180=B0, so they are hemispherical.=20 > This would make them suitable for a single pass paraboloid=20 > map. Even slightly larger cones like 200=B0 could be fitted=20 > onto a single paraboloid map. But the geometry of the=20 > buildings would need to be tesselated really high for the=20 > nonlinear projection to work. >=20 > I want to avoid rendering multiple shadow map faces per light > source. If I go shadow volume, I could have omnidirectional=20 > shadows for local lights in a single pass always. But shadow=20 > volumes would need a completely different pipeline on top of=20 > the existing one. >=20 > So if anyone knows the Miracle Worker (tm), I'd like to know ... >=20 >=20 > -----Original Message----- > From: gda...@li... on behalf=20 > of Jonathan Blow > Sent: Fri 8/27/2004 5:20 PM > To: gda...@li... > Cc:=09 > Subject: Re: [Algorithms] General-purpose shadowbuffer=20 > implementation. > Before the TSM paper came out (I think; before I heard of it, > anyway) I=20 > was doing all kinds of things in that area, after being very=20 > frustrated=20 > at PSM. My general M.O. was to think about the shadow map as being a=20 > surface in world space, and then build an arbitrary transform=20 > by mapping=20 > 4 points in world space to 4 points in projective space. (Or=20 > 3 points=20 > and a vector, for parallel light sources). There are a whole=20 > bunch of=20 > strategies you can explore about how to choose the 4 points, which=20 > becomes a generalization of PSM, TSM, etc. They all suck. >=20 > -snip >=20 >=20 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. = http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: Peter-Pike S. <pp...@wi...> - 2004-08-29 04:50:57
|
Check out hamilton chong's paper: http://www.cs.harvard.edu/~sjg/papers.html "A Lixel for Every Pixel" It does exactly what you want in the last paragraph using vanilla projection matrices... -Peter-Pike Sloan (I think this has the cleanest way of looking at PSM type stuff, but I have some bias due to discussions/interactions with the authors...) -----Original Message----- From: gda...@li... [mailto:gda...@li...] On Behalf Of Tom Forsyth Sent: Saturday, August 28, 2004 8:49 PM To: gda...@li... Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. So my fundamental point about all these cunning warps is you're trying to find the 3D-2D mapping that does the best thing. The problem is, the domain you're trying to cover is fundamentally 3D. Imagine a volume filled with spheres that are quite small and don't touch, so that they can cast shadows on each other, and you can see a majority of the spheres. This case is the one that says to me that the problem is a 3D one - you are trying to find a mapping for the shadowbuffer that fills this volume. But that's asking a 2D surface to fill a volume - can't be done unless you can throw away a dimension. The problem is, the only one you can throw away and maintain even texel density is along the camera's Z axis. But the only one you are _allowed_ to throw away is the one radiating out from the light (that's why it's a shadowmap :-) This says to me that trying to find a single mapping is doomed, no matter how clever your tech. But maybe my intuition is leading me astray. I think if you want to find one that maps onto something like a ground plane with good texel density, then maybe you can do it with some odd warpings. But that doesn't cover the general case. Admittedly, it covers a lot of outdoor game cases, so it might still be useful. But it's not general-purpose. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On Behalf Of=20 > Jonathan Blow > Sent: 28 August 2004 15:33 > To: gda...@li... > Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. >=20 >=20 > Tom Forsyth wrote: >=20 > >I meant they don't solve that case, not that the frustums > actually duel. If > >you're looking at a light, rendering with a paraboloid map > (I assume it's > >used in the same sense as a cube-map, but without the > multiple chunks) means > >that you have too many texels near to the light and too few > near the camera. > >That's what I mean by the duelling frustum case. > > =20 > > >=20 > Okay, I get what you're saying. The thing is though, once you've=20 > decided to use a paraboloid, there's no point in worrying about things > like linearity any more. At which point, you can throw some kind of=20 > warping function onto the surface of the paraboloid to try and account > for perspective. Since the paraboloid is easily parameterized, you=20 > ought to be able to map the distortion to something pretty close to=20 > the right answer, and thus beat duelling frustums. That's what I was=20 > thinking anyway, but I didn't think about it too hard. >=20 > The view-dependant hyperbola on the other hand basically gives you the > exact warping function that you want no matter what, which is why I=20 > would do that instead of a hyperbola, except hey, I can't render=20 > curved surfaces. (And honestly, trying to tessellate geometry to the=20 > degree that would be necessary is basically a losing proposition --=20 > you'd need a crazy triangle density.) >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java=20 > Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >=20 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 |
From: <c.s...@ph...> - 2004-08-30 07:55:46
|
Seems to be as a draw. You trade render target switches during sm = rendering with render passes afterwards. I'll give it a try and see = which is best. -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of Tom = Forsyth Sent: Saturday, August 28, 2004 7:25 PM To: gda...@li... Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. > Btw, how are you going to render a cube map from a render > target atlas, without a specialized pixel shader? You don't, you render it as n textures. You don't want an actual cube = map anyway, because usually you want different texel densities on = different sides. TomF. |
From: <c.s...@ph...> - 2004-08-30 15:38:31
|
Seems to me like a special case of Lixels for the ground plane, but I = may have misunderstood. -----Original Message----- From: gda...@li... = [mailto:gda...@li...] On Behalf Of = Guido de Haan Sent: Monday, August 30, 2004 2:00 PM To: gda...@li... Subject: Re: [Algorithms] General-purpose shadowbuffer implementation. Have you seen the Light Space PSM's by Michael Wimmer et al.? http://www.cg.tuwien.ac.at/research/vr/lispsm/ Looks promising. Doesn't solve your jitter problem though, but doesn't need all the special case PSM stuff. Guido ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. = http://ads.osdn.com/?ad_id=3D5047&alloc_id=3D10808&op=3Dclick _______________________________________________ GDAlgorithms-list mailing list GDA...@li... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |
From: Jonathan B. <jo...@nu...> - 2004-08-27 15:20:06
|
Before the TSM paper came out (I think; before I heard of it, anyway) I=20 was doing all kinds of things in that area, after being very frustrated=20 at PSM. My general M.O. was to think about the shadow map as being a=20 surface in world space, and then build an arbitrary transform by mapping=20 4 points in world space to 4 points in projective space. (Or 3 points=20 and a vector, for parallel light sources). There are a whole bunch of=20 strategies you can explore about how to choose the 4 points, which=20 becomes a generalization of PSM, TSM, etc. They all suck. A linear transform is just not enough to solve this problem. Earlier this week I did some experiments with hyperbolic shadow maps,=20 where the shadow map is a hyperbola in view space that approximates the=20 view frustum. For the pathological case of a parallel light source=20 behind the viewer (which is what linear projections totally fail at), I=20 got near-perfect resolution distribution (and I am pretty sure I could=20 achieve this for any viewing angle but didn't pursue it because...). =20 Unfortunately, the mapping is highly nonlinear which creates very ugly=20 artifacts in the rendered scene due to the linear interpolation of=20 geometry. This is solvable for the project-shadows-on-geometry=20 rendering stage (just re-evaluate shadow map coordinates per pixel and=20 you do fine), but not solvable for actually creating the shadow map. =20 You would actually need to be able to precisely render the appropriate=20 curved surfaces. In a software renderer, you could do this; so I think=20 the algorithm might be good for software rendering, and for hardware=20 sometime in the further future. For now though I have dropped it. In my current game I am using the=20 cascade-of-increasing-shadow-buffer-sizes approach. And I like it a=20 lot. It runs fast even on my laptop, and the resolution is ROCK SOLID. =20 There is none of that PSM/TSM crap about your resolution wavering in and=20 out. Because the projections are exactly orthogonal, you can eliminate=20 shadow map crawling for stationary objects, by only moving the=20 projection matrix by a quantum of the shadow map texel size. It works=20 great. I am just now doing this seriously, so it's not totally done yet (no=20 antialiasing) but there are screenshots of all the stuff in progress at: http://number-none.com/happycake/notes_8/index.html (Warning: Programmer=20 Art Ahead). There is a little bit of a pragmatic issue with object size and the=20 minimum shadow map resolution I achieve close to the camera. For small=20 performance cost, I could just create another shadow map that's lower=20 resolution and put it first in the series, but this would make me unable=20 to cast good shadows on big objects until I solve this problem. (The=20 problem is not unsolvable, and certainly can be solved by brute force=20 dumb stuff, but I am trying to think of a more elegant solution). Anyway, if your target hardware is high-end enough that you don't mind=20 creating e.g. 3 or 4 shadow maps for a parallel light source (and=20 correspondingly more for a point source), then I have to say this is a=20 really good method to use. (For point sources that don't extend very=20 far, you perhaps don't need more than 2 maps anyway since distant things=20 wouldn't be illuminated). The code for this is REALLY simple, like 5=20 times simpler than my PSM implementation at least. It's very easy to=20 understand and it runs rock solid. -Jonathan. Christian Sch=FCler wrote: >One problem I see with any projection algo, be it PSM or trapezoidal, is= that it does not help you if your view direction aligns with the light d= irection. You can't have a higher resolution in the center of your shadow= map selectively for the nearby objects :-) > >So, you are standing on a balcony, sun behind, and both the balcony fenc= e and the street below you need a decent shadow map resolution. > >What I did to solve this was I would call it "segmented" shadowmaps, whe= re different shadow maps are used for different regions between z-planes = (with texkill planes, or actually alpha test, since I did it on FF hardwa= re). > >So the balcony would get a higher resolution segment than the street. > >Some images can be seen at the bottom of this page,=20 > >http://www.thetenthplanet.de/bounce > >but will also try to upload some examples where the segment boundaries a= re apparent.=20 > >I know I am guilty about not publicly writing anything about this before= :-) > >-chris > > >-----Original Message----- >From: gda...@li... [mailto:gdalgorithms= -li...@li...] On Behalf Of Tom Forsyth >Sent: Friday, August 27, 2004 11:13 AM >To: gda...@li... >Subject: RE: [Algorithms] General-purpose shadowbuffer implementation. > > > >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > |