RE: [Algorithms] [Rendering] Merging, approximating several dynamic lights
Brought to you by:
vexxed72
From: Tom F. <tom...@bl...> - 2003-07-21 11:10:00
|
Am I right in thinking the main problem you are seeing is popping as you change which lights are what sort? If so, that's certainly solvable. What I do is for each object I decide how many of what sort of light type they get. (this is determined statically, but I don't see any big problem with doing it dynamically). The three sorts of light are per-pixel (bumpmapped) ones, per-vertex "proper" lights (i.e. doing all the proper local diffuse and local specular stuff) and all the rest which get thrown into my 9-component spherical harmonic. So let's say for argument that I have 2 pixel lights, 4 vertex lights and an SH - keeps the numbers real. So for each object, find all the lights that hit it and sort them by their relative brightness at the closest point on the object to the light. So we now have lights L0, L1, L2, L3, etc... in order of brightness, brightest first. So there are 2 pixel lights. These will obviously be L0 and L1. But the problem is that as the object moves, L1 and L2 can swap places, and give you a pop in lighting. So the trick is to split L1 into part that is done per-pixel and part that is done per-vertex. The blend is such that when L1 and L2 are going to swap, i.e. they are at the same brightness, L1 is completely vertex and no pixel. Which means L1 and L2 are both vertex lights and can happily swap without a pop. Similarly, when L0 and L1 swap, make sure L1 is a completely pixel-generated light, so again they can swap with no pop. So pixel lights are: L0 and L1*blend1 And vertex lights are L1*(1-blend1), L2, L3, etc... (the multiplication just multiplies the colour of the light, it doesn't change the direction, etc). blend1 = (L1.bright - L2.bright)/(L0.bright - L2.bright); (note that when L1.bright==L2.bright, blend1==0, and when L0.bright==L1.bright, blend1==1). ...and you also do the same for the transition between vertex and SH: Pixel lights are: L0 and L1*blend1 Vertex lights are L1*(1-blend1), L2, L3, L4*blend4 SH lights are L4*(1-blend4), L5, L6, etc... blend1 = (L1.bright - L2.bright)/(L0.bright - L2.bright); blend4 = (L4.bright - L5.bright)/(L3.bright - L5.bright); The SH stuff is really cool - you can throw as many directional lights in there as you like and the per-vertex processing part doesn't change in cost. I'm doing a talk on this at GDC Europe, but there's a fair bit about them around already. Trying to merge lights sounds like a complete nightmare. I don't even attempt it. TomF. > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...] On > Behalf Of Guillaume Provost > Sent: 16 July 2003 17:05 > To: 'gda...@li...' > Subject: RE: [Algorithms] [Rendering] Merging, approximating > several dynamic lights > > > Alen, > > It's really a load balancing issue. There's two ways I > can save on > performance: > > - I can approximate and merge lights together > - I can degrade the lighting precision (pixel -> vertex > -> object) > - This can be done on an individual light basis. > > A few givens: > > - You'll want to naturally degrade the lighting precision if: > - The light is contributing very little > intensity (pixel -> > vertex -> object) > - The screen-space vertex density of an object is > sufficiently high (degrade pixel -> vertex) > - The size of the object on screen is very > small (vertex -> > object) > > Unfortunately, simply following the (above) rules is'nt > sufficient > in terms of performance, atleast not with the number of > lights and dynamic > objects that I'm currently dealing with. I can degrade lights > earlier, but > that comes at a significant visual cost - its basically > similar to switching > LODs too close from the camera. This technique also causes a > high variance > in vertex shader/pixel shader combinations, forcing me to dynamically > reconstruct, and resend code to the GPU several times a > frame. Its much more > preferable to have inacurate, consistent lighting, then acurate, > inconsistent lighting. > > I can balance the problem by merging lights. So that I > have, say, 4 > (vertex shader)/(pixel shader) combinations for various > levels of lighting > accuracy. The problem is that whatever algorithm I use to > merge lights needs > to be temporally continuous, in a way that reduces 'popping' > in the light > combinations that it produces. If a high-detail, in-your-face > object (ie: a > player's avatar) is surrounded by 6 strong lights, I need to > merge those > lights into, say, two or three clusters, then ensure that > when the player > moves in the game world, the lighting contribution does'nt 'pop'. > > ie: A simple work-around would be to simply ignore the > less-significant lights (ie - not try to merge them), and > 'cross-fade' out > old lights with new ones over time. Look at it as > 'motion-blurring' the > lighting conditions over time. > > Guillaume. > > -----Original Message----- > From: gda...@li... > [mailto:gda...@li...]On > Behalf Of Alen > Ladavac > Sent: Tuesday, July 15, 2003 2:10 PM > To: gda...@li... > Subject: Re: [Algorithms] [Rendering] Merging, approximating several > dynamic lights > > > Hm, we've used a method for aproximating any number of point(local), > directional(inifinite) and > ambient lights into one ambient and one directional. The > object could be > 0-100% in shadow wrt any > light, and transitions were always smooth. The idea was simple and > straightforward, but I am not > sure if that is what you want, as it was all for per-vertex lighting. > Is your problem in creating a smooth aproximation to for > vertex lighting, or > a smooth change between > per-pixel and vertex lighting? > > Alen > > > ----- Original Message ----- > From: "Guillaume Provost" <Gui...@ps...> > To: <gda...@li...> > Sent: Tuesday, July 15, 2003 3:13 PM > Subject: [Algorithms] [Rendering] Merging, approximating > several dynamic > lights > > > > Greetings, > > > > I am, as I'm sure you all are, constrained in the number of dynamic > > lights I can light a mesh with. I've implemented a > 'degrading scheme' > where > > I degrade a light from per-pixel to per-vertex to a simple > ambient cue in > > order to manage performance (these are also scaled with respect to > distance > > of the lightsource and camera), but these transitions are not always > > seemless. I was wondering whether some of you have tried merging > > lightsources as an alternative to this, and how much > success you've had at > > getting rid of discontinuities in the lighting conditions. > I currently > deal > > mostly with 'skewed' spotlights (point-ellipsoid lights) > which I use to > > roughly approximate rectangular area-lights, and > omnidirectional lights. > > > > Guillaume. > > www.celdamage.com > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Parasoft > > Error proof Web apps, automate testing & more. > > Download & eval WebKing and get a free book. > > www.parasoft.com/bulletproofapps1 > > _______________________________________________ > > GDAlgorithms-list mailing list > > GDA...@li... > > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > > Archives: > > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a > single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual > machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > |