Someone can help me? Sorry for my english, i hope the problem is clear

v71
—
2010-02-21T17:50:13Z —
#2

This is something that pops up at times, basically you need to average the accumulated normals for every vertex , whose surface is associated with. Here is the code, i got more complex ones dealing with averaged surface area , and vertex normals shared by multiple vertex coordinates. This is good to make you start , don't mind the shift operation ,i use for padding my arrays, look at the code and try to see what's going on it not so difficult

I explain better how i use normals. I want to send them to a glsl shader. Until i don't use the shader, the model geometry *seems* ok. When i use the shader the geometry is bad as you can see in the previous image. I think the normal computation is ok, so what's wrong? Here the shaders:

If it is useful, i apply a transfomation to vertices, before the glVertexPointer call. Maybe the shader has not the right vertices...

Reedbeta
—
2010-02-23T00:54:14Z —
#4

The shader code looks reasonable. Try removing the bump map and looking at just the pure vertex normals for now, to eliminate the bump map as a possible source of error. Also try and reproduce the problem on a very simple model like a cube. Then you can step through it in the debugger and see exactly where things are going wrong.

Simopi
—
2010-02-26T17:18:23Z —
#5

Fixed!!!

The problems were:

a) the suggested code of v71.

b) A normal can become 0, during the cross product between the vectors v3-v1 and v2-v1, so i must fix it in some way. For now i assign that normal to a vector (1,1,1) and it works. If someone knows a better method, you are welcome.

c) Thanks to Reedbeta suggestion, i used a cube and after some trials i found the problems

Thank you guys! See you into the forum. I hope to be useful too!

v71
—
2010-02-26T17:40:57Z —
#6

Strange because i use that code everyday and it works fine, can you point me to the offending line ?

I write b\\^a instead of a\\^b to have the light in the correct direction (if not i have the shadow where i want the light and the light where i want the shadow). Maybe is the problem?

v71
—
2010-03-02T11:38:35Z —
#8

The cross product is sensitive to the orientation, also the case where the vector is zero dimensional is rather difficult to happen it means that you may have a degenerate triangle. in that case i would use a small epsilon not setting the vector to 1,1,1 its like making it pointing to a defiinite direction, basically its a diagonal pointing away. Or skip completely zero area triangle, they won't be rendered anyway.

Simopi
—
2010-03-02T17:07:27Z —
#9

I understand and you're right, i tried to skip zero-area triangles and it works!!! Thank you so much!

Can i ask a last thing? I write here because i think it is in topic. Sorry for the trouble.

I need to calculate tangents for a sphere, and for me is more difficult. I found a sphere implementation that sets normal coordinates = vertex coordinates, now i must compute tangents to apply bump mapping. I use the same shader i submitted some post ago. I tried something but it is the result (see the bright areas for example):

Note that i still have to polish and optimize a little bit, i am working on other components of my engine right now

Simopi
—
2010-03-04T00:22:31Z —
#11

Yes thanks. I use the basics of this code right now. But i have problems using that on a sphere mesh. I use a GL_TRIANGLE_STRIP method, so i have shared vertices for triangles, and it seems i have problems to retrieve the right faces...

Yes, triangle strip uses redundant vertices, and i don't like this way of render meshes, it still a legagy from old opengl version, i suggest to use vertex arrays or vbo, i wrote also a function do duplicate vertices when models have multiple texture coords for each vertex , just to avoid using strips. In my opinion triangel strip are obsolete, but if you want still to use them you should duplicate redundant vertices , also for each duplicate you have to match the corresponding tex coords and normals.