RE: [Algorithms] Re: Is there such a thing as spherical harmonic lighting for characters?
Brought to you by:
vexxed72
From: Tom F. <tom...@ee...> - 2004-04-12 06:44:16
|
> I could see that he may be doing that. But horizon maps are=20 > way more compact > than a SH, and they works well. So I am assuming that he must=20 > be encoding > something else in there.=20 Not in my experience. I think the two are roughly equivalent. Compare a horizon map storing eight directions (which is pretty much the minimum = for good-looking shadows up-close) with a 9-component luminance SH (i.e. = just greyscale, not RGB). You can store most of the SH data as signed (or = biased) bytes, so it's 9/8ths more data than the horizon map. Except that it = also encodes the luminance of the diffuse texture and the normal map, so you don't have to send those textures down as well (you can simply send = diffuse chrominance deltas and downsample & compress the texture a lot). And = best of all, it handles the entire lighting environment in one calculation, no matter how many lights - whereas a horizon map only deals with one light = at a time. Horizon maps deal better with a single specular light, and skinning the = SHs quickly is still an annoying problem, but they're pretty close in useability. TomF. > -----Original Message----- > From: gda...@li...=20 > [mailto:gda...@li...] On=20 > Behalf Of Tomas Arce > Sent: 11 April 2004 23:22 > To: gda...@li... > Subject: [Algorithms] Re: Is there such a thing as spherical=20 > harmonic lighting for characters? >=20 >=20 > >>>> David <<<< > >>>> The "new bump-map" technique, however, is probably=20 > refering to the=20 > paralax-mapping technique (they use it on their walls and such, so=20 > probably their characters too). Which looks frigin' great. =20 > I've got it=20 > in my engine and the artists are revamping areas to use=20 > it.... whew, a=20 > real win of a technique. >=20 > Yes I was aware of that particular feature. It looks pretty=20 > good. But I was > not talking about that; I was wondering which things was he=20 > encoding using > by using spherical harmonic.=20 >=20 > >>>> TomF. <<<< > >>>> So the SH lighting he's probably talking about is encoding the > self-shadowing term of the bumpmap in an SH per-vertex or per-pixel. = =3D > People have been doing this with horizon maps for a while (e.g. > http://eelpi.gotdns.org/papers.html - "A paper on self-shadowing =3D > bumpmaps"=20 >=20 > I could see that he may be doing that. But horizon maps are=20 > way more compact > than a SH, and they works well. So I am assuming that he must=20 > be encoding > something else in there.=20 >=20 > >>>> Although in fact people have been encoding them with=20 > "grubbiness maps" > or "ambient occlusion terms" (which are basically the 0th=20 > term of the SH) > and cones =3D of light and ellipses (which are very close to=20 > the first four SH > terms) for some time.=20 >=20 > The only demo that I have seem doing ambient occlusion has=20 > been the ogre > demo from nvidia. The way they did it was to store the info=20 > per frame. Which > that to me is cheating in a big way; In other words they have=20 > not done it. >=20 > >>>> So if you look at some of Peter-Pike Sloan's talks on=20 > PRT, he has this > self-shadowing term in there, but then he extends it to specular and > interreflecting and translucent and all those nice effects, and also = =3D > extends the range to include non-local effects. But if you=20 > just limit it to=20 > local effects (i.e. the neighbouring tens of texels), then=20 > you get all the =3D > effect of the local self-shadowing of the bumpmaps.=20 >=20 > But those effects that you talked about such the interreflecting, and > translucent they will be "worng"/half right/not fully=20 > approximated. Like I > said in my original post. Because they are not fully=20 > describing what is > actually happening. But I guess it may be better than nothing=20 > which is what > we have.=20 >=20 > I guess for the pre-computation you will want to keep the=20 > rays very short. > So that they don't affect non-related parts/joins. Example;=20 > Head with chess. > I also wonder how it will look if you skin the light SH=20 > vector. Sorry I just > rumbling now... >=20 > >>>> Kelly Brock <<<< > >>>> If you treated the system much like you did the 8 lights > available to most 3D API's, would it be possible to recomputed the SH > coefficients on the fly with appropriate data stored in the map as > "location" data? >=20 > I don't think so. I guess this is somewhat equivalent to ask=20 > whether is > possible to recomputed a light map on the fly. The answer is=20 > yes and no. > Well encoded SH are more expensive than light maps at least=20 > for the radiance > transfer part. But like Tom replied you can have a bunch of=20 > SH coefficients > spread around which represent the lighting at those locations=20 > and then you > can interpolate them. That will give you a more accurate L(s) of the > lighting equation, but not a better radian transfer T(s) part of the > function.=20 >=20 > Tomas >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > = administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli= ck > _______________________________________________ > 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 |