# OpenGL ES 2.0: Calculated Cube Vertex Normals Verification

Could I kindly ask to confirm, that the calculated normals are correct, please? I have calculated them on my own, but my testcube is still strangely lighted within OpenGLES 2.0.

• The vertices were exported from 3D authoring application.
• The vertex normals were calculated using matrix cross product.
• The vertex and fragment shaders I were exact copies from the book, so there should not be a bug.

The output in OpenGL looks like the sphere is lighted from its bottom. Moreover, it looks, like the box is visible from inside, as the top part is always transparent. Any idea, where can be a problem?

## Added:

The vertex normals are calculated based on triangulated quad-polygons. The triangulation is performed internally, by the 3d application. Vertices/ indices are generated by calling API calls of that application.

#begin 8 vertices
vs 24
v -25.000000 -25.000000 -25.000000
v 25.000000 -25.000000 -25.000000
v -25.000000 25.000000 -25.000000
v 25.000000 25.000000 -25.000000
v -25.000000 -25.000000 25.000000
v 25.000000 -25.000000 25.000000
v -25.000000 25.000000 25.000000
v 25.000000 25.000000 25.000000
#end 8 vertices

#begin 12 faces
fs 36
f 0 2 3
f 0 3 1
f 0 1 5
f 0 5 4
f 0 4 6
f 0 6 2
f 1 3 7
f 1 7 5
f 2 6 7
f 2 7 3
f 4 5 7
f 4 7 6
#end 12 faces

#begin 8 calculated normals
ns 24
n -0.577350 -0.577350 -0.577350
n 0.816497 -0.408248 -0.408248
n -0.408248 0.816497 -0.408248
n 0.408248 0.408248 -0.816497
n -0.408248 -0.408248 0.816497
n 0.408248 -0.816497 0.408248
n -0.816497 0.408248 0.408248
n 0.577350 0.577350 0.577350
#end 8 calculated normals


I use OpenGL ES 2.0, but that should not be relevant at this moment.

## Update:

I can confirm now, that the calculated vertex normals are correct, and can therefore be used by others, to verify correctness of their triangulated cube vertex normals calculations.

However, I still have a problem that all the vertices, which are in positive z axis, are not rendered. Not sure if they are culled, but I have pretty large frustum. Vertices in the -z axis are kept, so the rendered mesh looks like cut in half, as it is position in 0 z-axis.

This lines below show that I should not concsicously setup small render area:

mProjection = glm::perspective (45.0f, (float)WINDOW_WIDTH / (float)WINDOW_HEIGHT, 1130.0f, -1130.0f);

mViewTransformation = glm::lookAt(glm::vec3(vIntCamera.x, vIntCamera.y, 1130.0f), glm::vec3(vIntCamera.x, vIntCamera.y, 0.0f), glm::vec3(0.0f, 1.0f, 0.0f));


Any ideas, please, what else should I check?

## Solved:

Eye position of the camera (in glm::lookAt() function) should be above the top of the perspective frustum, defined by glm::perspective().

Thanks for your support guys, especially with the upper part of my question.

• possible duplicate of Any reliable polygon normal calculation code? – bummzack May 14 '11 at 9:30
• How do you define your cubes triangles? Are you sure the triangle vertices are all defined in counter-clockwise orientation? – bummzack May 14 '11 at 9:38
• @bummzack: Hi, please, do not mark this trhead as a duplication. It is not difficult to find vertex normal generation algorithm. This question is where the probem can be (it might not be in normals), and can help others to check correctness of their algorithms against my cube normals (if proven as correct), as the cube is very standard mesh for initial testings. – Bunkai.Satori May 14 '11 at 15:26
• @bummzack: to answer your second question: I use 3D authoring application, and I have developed a plug in. The plug in uses API calls to output vertices, triangulated indices and facet normals. I generated the above normals in two ways: Firstly, by summing and averating the facet normals as returned from the software. Secondly, I calculated facet normals from scratch, by generating vertices cross product. Both results were the same. As the application uses OpenGL internaly, I that th order of triangle vertices is counter-clockwise, but I am going to verify that now. – Bunkai.Satori May 14 '11 at 15:33
• @all: the probem si partially solved: I can confirm now, that the calculated normals are correct. The problem I had, which took me more than 24 hours to solve, was in one sign. I used: mProjection = glm::perspective (45.0f, (float)WINDOW_WIDTH / (float)WINDOW_HEIGHT, -1130.0f, 1130.0f); instead of correct mProjection = glm::perspective (45.0f, (float)WINDOW_WIDTH / (float)WINDOW_HEIGHT, 1130.0f, -1130.0f); However, there is one more problem: the mesh gets rendered only if it is moved into negative -z. The vertices that are in positive z are ignored/culled. Any idea, please? – Bunkai.Satori May 14 '11 at 17:16

## 2 Answers

Without a picture I'll have a rough guess on some of your problems.

Normals: If this is a cube, I'd expect all the normal component values to be +/- 0.577350 in different combinations depending on the vertex. Where you have other values the normal is no longer being properly averaged from the three faces that share it and it'll be tending more in one direction. Because you're using shared vertices for the faces then despite it being a cube, it's trying to be lit as if it's a sphere. If you wanted it to look like an actual cube you'll need to duplicate up the vertices and have unique normals for them.

"visible from inside": This sounds like a winding order issue. Graphics hardware tends to have Backface Culling enabled as a speed optimisation, depending on the order of the vertices given to the hardware it makes a decision as to whether it thinks a polygon faces towards or away from the viewer. It's possible you can fix this problem by changing the order of the vertices in your faces, so the first face would become "0 3 2" instead of "0 2 3".

A picture of the output would help to be more specific, as would a more accurate description of what problems you actually have, for example, you say it's lit from below, is this a problem or was that just stating how it looks?

Quick update:

You can display the normals manually by drawing some simple lines, just use the vertex position as the start point, then add the normal value (scaled by some constant factor to ensure it's the length you want) and add this to the original vertex position to generate an end point.

• +1 for the first paragraph here. Bunkai needs 24 vertices to make a properly shaded cube here. 3 vertices located at each corner with normals orthogonal to the face of the triangle the vertex will be used for. – Steve H May 14 '11 at 11:12
• +1 for valuable answer. Hi Roger, thanks for your reply. I understand the issue of trippling vertices to have properly shaded cube. However, at this moment, I think the higher priority is solving the issues I described above: it looks like I always see the inside of the cube, and despite the light is positioned in front of the cube, it looks like the cube is lit from its back. I process triangulated cube, therefore, there are some irregularities in normals, assuming the normals are calculated correctly. – Bunkai.Satori May 14 '11 at 15:54
• @Steve H: thanks for your comment. I did not realize this, but because I process triangulated cubes I might need 48 vertices, is that correct? – Bunkai.Satori May 14 '11 at 15:57
• since this answer was more detailed and provided me with additional information, I am marking it as the Acceptable Answer. The problem is solved, although it was elsewhere. I described it in the update of my question above. – Bunkai.Satori May 14 '11 at 18:32

I doubt GL ES has geometry shaders but just in case it does (or if you can test your data on something with a full OpenGL 3 and above), my answer to this question on SO provides a geometry shader to visualize your normals.

• Unfortunatelly, GL ES has only vertex and fragment shaders. I do not use a full OpenGL 3. Therefore, dipping into OpenGL 3+ would probably be more consuming than finding answer to my question. Maybe, if anybody can generate vertex normals for a cube, so we could compare the results. The normals should be the same. – Bunkai.Satori May 14 '11 at 7:28
• If anyone has idea, that would really help. – Bunkai.Satori May 14 '11 at 9:18