Yep you’re right jwatte, it’s the same principal as moving the light to object space. More efficient too.
As for object space needing a texture for each triangle, this is not what I said tobiaso. They just need an unique mapping in texture space. Each position on the object needs a unique position on the texture map. Kind of like character skinning but much more strict about reuse.
On other comments, you CAN keyframe an object space vector representation. Transforming the light position back through the mesh deformation matrix to object space gives you the correctly animated mesh. This is what jwatte pointed out. So for a light in world space you go back through inverse model matrix then inverse mesh deform (probably multiple matrices with weighted interp for this one) and you are in the same space the object normal is stored in.
The transformation chain looks something like this:
Tangent Space --> Object Space --(multimatrix interp)–> Deformed Mesh Space --> World Space --> Eye Space
Depending on where you have your light & other vector representations, and where you do your lighting calculation you need to apply the appropriate transformations to all vectors to get to the same space before the dot products are performed.
It doesn’t really matter what space you have them in or what space you do your dot products in except that you want to minimize the work, minimize artifacts and have an intuitive workable data representation.
You could transform everything to tangent space or eye space and it would work, however only some things are possible without complex fragment level vector transformation, so you are restricted to the spaces where a simple texture fetch gets you the correct normal vector. i.e. tangent space or object space. The others change too much. Sure you could store multiple normal maps vectors for each deformed mesh space but you’d need to interpolate the normal colors in the fragment shader before lighting dot products using multitexture based on mesh weighting and it would be an extremely inefficient data representation with a big normal map for each keyframe. It’s not how anyone would do it.
I think the confusion may arise from the way meshes have been none in the past vs the future. Object space normal representations on characters imply live skeletal deformation matrices, not explicitly hand crafted meshes with unique normals. So object space is the undeformed object mesh with identity skeletal transofrmations and that’s where the high detail object space normals are computed.
For static predeformed character animation meshes as seen in some games you could store some kind of coordinate frame at the vertices in the deformed meshes as a cue to the correct object space orientation, but you need something to tell you how to transform the vectors to object space (or tangent space) even if you’re not doing skeletal deformations on the fly. Anything else is just impractical.
[This message has been edited by dorbie (edited 09-23-2002).]