Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Algorithms] Illumination Half vector in lighting

 Re: [Algorithms] Illumination Half vector in lighting From: Matt J - 2006-07-28 06:42:45 ```Thanks for the tips..although I follow, I can't say I understand completely... I'm guessing the dimming your describing was the result of a lack of normalization inherent on lerp'd vectors, or because the reflection vector method produces better results. Either way if I notice this I'll know what to do. Quite right, one of my first shaders I wrote is a phong ARB shader. It's rather trivial. Im starting to realize quickly soon the difficulty won't be the implementation, it will be to how to scale different shading models with hardware that has varying texture units, and how do stack techniques (like say bump mapping with ward vs. phong, etc), and what calculations do you decide to either do in the fragment shaders or do you decide to precalculate in the vertex shaders. In a dynamic engine, it would seem you would need to dynamically modify the assembly or high level code to accomodate the lighting, texture units available, etc, before applying it to a material.. Matthew > If you got local view & light source then you'll get incorrect half-vector interpolation over the triangle (because of the two varying vectors over the triangle). We tried the half-vector approach in Splinter Cell: Chaos Theory, but because of the error specular highlights kind of followed triangle edges of models. Sorry for the vague explanation, but just try to imagine :) so we just ended up computing the reflection vector per-pixel from the two vectors to get proper results (infact IIRC we still used half-vector for characters because view-vector was fairly constant for small triangles on characters). It's only couple of pixel shader instructions to compute reflection vector and you don't need to do it for anything but the view-vector (e.g. if you compute multiple lights in single pass) so it's no big deal to do the real thing. Of course if your target platform got no pixel shaders or your shader is packed, it's a different story (: > > Cheers, Jarkko > ```

 Re: [Algorithms] Illumination Half vector in lighting From: Jarkko Lempiainen - 2006-07-27 13:10:58 ```If you got local view & light source then you'll get incorrect half-vector = interpolation over the triangle (because of the two varying vectors over th= e triangle). We tried the half-vector approach in Splinter Cell: Chaos Theo= ry, but because of the error specular highlights kind of followed triangle = edges of models. Sorry for the vague explanation, but just try to imagine := ) so we just ended up computing the reflection vector per-pixel from the tw= o vectors to get proper results (infact IIRC we still used half-vector for = characters because view-vector was fairly constant for small triangles on c= haracters). It's only couple of pixel shader instructions to compute reflec= tion vector and you don't need to do it for anything but the view-vector (e= .g. if you compute multiple lights in single pass) so it's no big deal to d= o the real thing. Of course if your target platform got no pixel shaders or= your shader is packed, it's a different story (: Cheers, Jarkko -----Original Message----- From: gdalgorithms-list-bounces@... [mailto:gdalgorithms-list-bounces@...]On Behalf Of Matt J Sent: 26 July 2006 21:24 To: Game Development Algorithms Subject: [Algorithms] Illumination Half vector in lighting Can someone explain the difference, visual and conceptually, from a local light half vector and one that is from an infinite distance away? I'm not having a problem with the mathematics, more like the conceptual understanding. Local meaning: h =3D L + V / || L + V || And infinite meaning: h_inf =3D L + (0, 0, 1) / || L + (0, 0, 1) || i.e. the latter which is given from: fragment.light[n].half and used in LIT ARB opcode Would you assume the viewer is infinite because its a directional light? What meaning would this half vector mean then, if the source is a spot or area light? Or is that value no longer useful then? To me, the meaning of an infintely far viewer and a local light is the same as the meaning of an infinitely far light and a local viewer. Is this correct? Thanks for the tips :) ----- Matt Johnson http://otowngraphics.blogspot.com ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE= VDEV _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ***************************************************************************= ******* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ***************************************************************************= ******* ```
 Re: [Algorithms] Illumination Half vector in lighting From: - 2006-07-28 02:21:54 ```An infinite viewer can be seen as in the limit of an orthogonal camera, = ie. all pixels have the same view vector. You get this, if the camera moves far away while at the same time = zooming (tele) in for compensation. The smaller the field of view, the more far away the viewer in this = sense. -----Original Message----- From: gdalgorithms-list-bounces@... = [mailto:gdalgorithms-list-bounces@...] On Behalf Of = Matt J Sent: Wednesday, July 26, 2006 10:24 PM To: Game Development Algorithms Subject: [Algorithms] Illumination Half vector in lighting Can someone explain the difference, visual and conceptually, from a local light half vector and one that is from an infinite distance away? I'm not having a problem with the mathematics, more like the conceptual understanding. Local meaning: h =3D L + V / || L + V || And infinite meaning: h_inf =3D L + (0, 0, 1) / || L + (0, 0, 1) || i.e. the latter which is given from: fragment.light[n].half and used in LIT ARB opcode Would you assume the viewer is infinite because its a directional light? What meaning would this half vector mean then, if the source is a spot or area light? Or is that value no longer useful then? To me, the meaning of an infintely far viewer and a local light is the same as the meaning of an infinitely far light and a local viewer. Is this correct? Thanks for the tips :) ----- Matt Johnson http://otowngraphics.blogspot.com -------------------------------------------------------------------------= Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share = your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ GDAlgorithms-list mailing list GDAlgorithms-list@... https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 ```
 Re: [Algorithms] Illumination Half vector in lighting From: Matt J - 2006-07-28 06:42:45 ```Thanks for the tips..although I follow, I can't say I understand completely... I'm guessing the dimming your describing was the result of a lack of normalization inherent on lerp'd vectors, or because the reflection vector method produces better results. Either way if I notice this I'll know what to do. Quite right, one of my first shaders I wrote is a phong ARB shader. It's rather trivial. Im starting to realize quickly soon the difficulty won't be the implementation, it will be to how to scale different shading models with hardware that has varying texture units, and how do stack techniques (like say bump mapping with ward vs. phong, etc), and what calculations do you decide to either do in the fragment shaders or do you decide to precalculate in the vertex shaders. In a dynamic engine, it would seem you would need to dynamically modify the assembly or high level code to accomodate the lighting, texture units available, etc, before applying it to a material.. Matthew > If you got local view & light source then you'll get incorrect half-vector interpolation over the triangle (because of the two varying vectors over the triangle). We tried the half-vector approach in Splinter Cell: Chaos Theory, but because of the error specular highlights kind of followed triangle edges of models. Sorry for the vague explanation, but just try to imagine :) so we just ended up computing the reflection vector per-pixel from the two vectors to get proper results (infact IIRC we still used half-vector for characters because view-vector was fairly constant for small triangles on characters). It's only couple of pixel shader instructions to compute reflection vector and you don't need to do it for anything but the view-vector (e.g. if you compute multiple lights in single pass) so it's no big deal to do the real thing. Of course if your target platform got no pixel shaders or your shader is packed, it's a different story (: > > Cheers, Jarkko > ```