RE: [Algorithms] SH data falloff..

[Tom F. <tom...@ee...>]

If you're doing all this with a single light, then maybe you can correct =
in
some way. Thing is, if you're only doing one light at a time, then using =
an
SH doesn't seem to be the right answer - it's overcomplicating things. =
The
real win with using SHs is that it doesn't matter how many lights you =
use,
the cost is the same.

TomF.


> -----Original Message-----
> From: gda...@li...=20
> [mailto:gda...@li...] On=20
> Behalf Of Andreas Tadic
> Sent: 17 January 2004 15:43
> To: gda...@li...
> Subject: SV: [Algorithms] SH data falloff..
>=20
>=20
>=20
> Hmm. I see what you mean.
> I would have assumed that once one knows the lumination of the
> centerpoint of the object (that the prt sim is doing) one=20
> could use that
> formula to modify the luminance of each vector in the object.
> (And then use the greyscale luminance in ones point-light calculation)
> Obviously not at simple as that..
>=20
> -----Ursprungligt meddelande-----
> Fr=E5n: gda...@li...
> [mailto:gda...@li...] F=F6r Tom =
Forsyth
> Skickat: den 17 januari 2004 14:40
> Till: gda...@li...
> =C4mne: RE: [Algorithms] SH data falloff..
>=20
>=20
> Agreed. Abutting objects are a real pain when trying to do any sort of
> light simplification - very hard to get rid of the seams.=20
> Computing the
> SHs where they meet and interpolating is the only solution I know (not
> necessarilly along the corners, just so that along the line where they
> meet the interpolation is the same). But of course it's moderately
> expensive, and in this case you need to interpolate between=20
> four sets of
> SHs per object.
>=20
> The other option I thought of was to mark the vertices as "edge verts"
> and light them with the standard point-light illumination.=20
> This ensures
> they are consistent across seams. Only vertices for the rest of the
> object are lit using an SH. The problem is that the lighting is
> inconsistent across the surface of each object, and also that=20
> it doesn't
> actually lessen the workload (which is the whole point of=20
> using SHs for
> lighting) unless you have conditional execution in your=20
> vertex shaders,
> which is only in pretty fancy hardware right now.
>=20
> TomF.
>=20
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...] On=20
> > Behalf Of Ignacio Casta=F1o
> > Sent: 17 January 2004 13:22
> > To: gda...@li...
> > Subject: Re: [Algorithms] SH data falloff..
> >=20
> >=20
> > Andreas Tadic wrote:
> > > Each object is at a distance from the light, pivot in the
> > center of each
> > > object. What were attempting is to smooth out the vertices on each
> > > object to get be able to post-process a pointlight using=20
> > this data to
> > > control the pointlights luminace with, in effect being=20
> able to have
> > > pointlights on SH objects. Since SH objects have their=20
> > luminance based
> > > on the center of the object (it's position) they get
> > "tiled" as shown here:
> > > _http://www.customred.com/sh/rawsh.jpg_ (rawsh.cpp snippet)
> >=20
> > I think that you should compute the SHs on the corners of the tiles
> > instead of the middle, and interpolate the coefficients.
> >=20
> > You last shots look good, though. How are you doing that?
> >=20
> > --
> > Ignacio Casta=F1o
> > cas...@ya...
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> 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
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_ida88
>=20