## Re: [Algorithms] General-purpose shadowbuffer implementation.

 Re: [Algorithms] General-purpose shadowbuffer implementation. From: Jonathan Blow - 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: gdalgorithms-list-admin@...=20 >>[mailto:gdalgorithms-list-admin@...] On=20 >>Behalf Of Jonathan Blow >>Sent: 28 August 2004 15:33 >>To: gdalgorithms-list@... >>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 >>GDAlgorithms-list@... >>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 >GDAlgorithms-list@... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_ida88 > > =20 > ```