OpenGL ES 2.0: Calculated Cube Vertex Normals Verification

Question

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.

Answer 1

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.

Answer 2

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.