   What is the best way to find the normal?
  I am testing a terrain with light shining on top, but it looks blocky in each square, I am not sure is it because i used the cross product to find the normal for each square on the grid. Is there anyway of creates a smoother looks rather than blocky in each square?I hope I wrote it clear enough. : )   
  Average the normal with the normals of the surrounding vertices. Also, make sure you calculate a normal for each vertex, and not each surface, it looks a lot smoother. See: http://www.lighthouse3d.com/opengl/terrain/index.php3?normals   ;  Using the cross-product is the correct way to compute the perpendicular vector of each face adjacent to a vertex. Then normalize the vectors (i.e. make them of unit length), sum them and normalize the result again.It is also recommended to weight the particular normals before summing them. A common weighting scheme is to use the angle the face makes at the vertex. E.g. if you are using tri-strip like face scheme then 6 faces are adjacent to a (inner) vertex, 2 of them showing a ~90 degree angle and 4 of them a ~45 degree angle. So the former 2 faces are to be weighted 2 times higher than the latter ones (the absolute weigth doesn't play a big role (if at least >0 ;) due to the concluding normalization of the vector sum). Of course, if you're using quads then all angles are the same, making weighting redundant.   ;  Is working.... Thanks you so much : )[Edited by - kbundy on June 20, 2006 6:57:31 AM];  Isn't the best and cheapest weighting scheme just not normalizing the normals before summing them? Because a cross product of the sides of a triangle is directly proportional to the triangle's area, large triangles will appropriately weigh more in the sum.   ;  I don't know what's the best weighting scheme is. The following are my thoughts of this problem:The correspondence of the cross-product in question is as follows:|a x b| == |a| * |b| * sin( <a,b> )Let's assume a regular tri pattern as is given by tri-strips for a terrain where the vertices are 1 length unit apart (ignoring the differences due to different heights).Looking at a 45° angle of a tri one gets|a| * |b| * sin( <a,b> ) = 1 * sqrt(2) * 0.707 = 1and for a 90° angle|a| * |b| * sin( <a,b> ) = 1 * 1 * 1 = 1So, w/o any furthur handling, each and every of the surrounding tris would have the same influence on the vertex normal. IMHO, looking at the vertex as an infinitesimal pie chart shows that the angle and not the area plays the role of question. Furthurmore, looking at a surface with irregular faces, a couple of surrounding big faces should not suppress the influence of a small transition.On the other hand, if one has a regular pattern so that all cross-products will have more or less the same length, perhaps one may drop the normalization of the cross-products to avoid especially the sqrt. If the height changes from vertex to vertex are less, then the introduced error may be invisible. But the normal weighting is IMHO to be done independently.   ;Quote:So, w/o any furthur handling, each and every of the surrounding tris would have the same influence on the vertex normal. IMHO, looking at the vertex as an infinitesimal pie chart shows that the angle and not the area plays the role of question. Furthurmore, looking at a surface with irregular faces, a couple of surrounding big faces should not suppress the influence of a small transition.But they should. A couple of small triangles shouldn't have much effect on the shading of nearby large ones. Weighing by the area gives very nice results in all cases that I have encountered -- not limited to terrains -- *and* it's fast, if that matters.Refer to this discussion, for example: http://www.devmaster.net/forums/showthread.php?t=414;  A problem with weighting by triangle area is that a small feature surrounded by large triangles is obliterated by the weighting. Now,that feature is there for a reason, so getting smoothed away is probably wrong.Anyway, keep in mind that the normals are (supposed to be) normal to the actual surface, while the mesh is only an approximation of the actual surface. There is no way of determining the actual surface from the mesh, so there is no "correct" way of determining the normals.If you are generating normals at run-time (which is not the typical case), then speed is what matters and using the weighted face normals is probably the best way to go. Otherwise, you are generating the normals off-line and speed is not a big consideration.If convenience and simplicity is the most important factor, then do it whichever way is simplest and most convenient for you. Don't worry to much about the correctness of the results.If quality is the most important factor, then you can do a couple things:Start with a very high resolution mesh and generate the normals and the working mesh from that.Edit the normal map by hand to fix the problems.;  Just wanted to add that in cases where you know that the mesh (or a portion thereof) is generated from an equation, you can (and often should) use the equation to determine normals as well. For example, if you have a mesh covering the surface of a sphere, then however you're doing the tesselation, you can treat the normal of any face as  being proportional to (i.e. in the direction of) a line from the sphere centre to the face centre.   