Opengl ES 2.0: части модели закрыты там, где они не должны. Виноват ли z-буфер?

Question

Я использую Assimp для рендеринга 3D-моделей с OpenGL ES 2.0. У меня сейчас странная проблема, в которой некоторые части модели не видны, даже когда они должны быть. Это легко увидеть на этих картинках:

На этом втором изображении я визуализировал (линеаризованную версию) z-буфер на экран, чтобы посмотреть, не может ли это быть проблемой с z-буфером. Черные пиксели возле камеры:

Я попытался изменить значения для z-ближнего и z-дальнего без какого-либо эффекта. Прямо сейчас я делаю это при инициализации:

glEnable(GL_CULL_FACE);// Cull back facing polygons
glEnable(GL_DEPTH_TEST);

И я также делаю это для каждого кадра:

glClearColor(0.7f, 0.7f, 0.7f, 1.0f);
glClear( GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT);

Я подумал, что это может быть проблема с намоткой лица, поэтому я попытался отключить GL_CULL_FACE, но это не сработало. Я уверен, что с моделью все в порядке, поскольку Blender может правильно ее отрендерить.

Я использую эти шейдеры прямо сейчас:

// vertex shader
uniform mat4 u_ModelMatrix; // A constant representing the model matrix.
uniform mat4 u_ViewMatrix; // A constant representing the view matrix.
uniform mat4 u_ProjectionMatrix; // A constant representing the projection matrix.

attribute vec4 a_Position; // Per-vertex position information we will pass in.
attribute vec3 a_Normal; // Per-vertex normal information we will pass in.
attribute vec2 a_TexCoordinate; // Per-vertex texture coordinate information we will pass in.

varying vec3 v_Position; // This will be passed into the fragment shader.
varying vec3 v_Normal; // This will be passed into the fragment shader.
varying vec2 v_TexCoordinate; // This will be passed into the fragment shader.


void main()
{
    // Transform the vertex into eye space.
    mat4 u_ModelViewMatrix = u_ViewMatrix * u_ModelMatrix;
    v_Position = vec3(u_ModelViewMatrix * a_Position);

    // Pass through the texture coordinate.
    v_TexCoordinate = a_TexCoordinate;

    // Transform the normal's orientation into eye space.
    v_Normal = vec3(u_ModelViewMatrix * vec4(a_Normal, 0.0));

    // gl_Position is a special variable used to store the final position.
    // Multiply the vertex by the matrix to get the final point in normalized screen coordinates.
    gl_Position = u_ProjectionMatrix * u_ModelViewMatrix * a_Position;
}

И это фрагмент шейдера:

// fragment shader
uniform sampler2D u_Texture; // The input texture.
uniform int u_TexCount;

varying vec3 v_Position; // Interpolated position for this fragment.
varying vec3 v_Normal; // Interpolated normal for this fragment.
varying vec2 v_TexCoordinate; // Interpolated texture coordinate per fragment.

// The entry point for our fragment shader.
void main()
{
    vec3 u_LightPos = vec3(1.0);
    // Will be used for attenuation.
    float distance = length(u_LightPos - v_Position);

    // Get a lighting direction vector from the light to the vertex.
    vec3 lightVector = normalize(u_LightPos - v_Position);

    // Calculate the dot product of the light vector and vertex normal. If the normal and light vector are
    // pointing in the same direction then it will get max illumination.
    float diffuse = max(dot(v_Normal, lightVector), 0.0);

    // Add attenuation.
    diffuse = diffuse * (1.0 / distance);

    // Add ambient lighting
    diffuse = diffuse + 0.2;
    diffuse = 1.0;

    //gl_FragColor = (diffuse * texture2D(u_Texture, v_TexCoordinate));// Textured version

    float d = (2.0 * 0.1) / (100.0 + 0.1 - gl_FragCoord.z * (100.0 - 0.1));
    gl_FragColor = vec4(d, d, d, 1.0);// z-buffer render
}

Я использую VBO с индексами для загрузки геометрии и прочего.

Конечно, я могу вставить другой код, который, по вашему мнению, может быть релевантным, но сейчас я рад получить некоторые идеи о том, что может вызвать это странное поведение, или некоторые возможные тесты, которые я могу сделать.

Answer 1

Хорошо, я решил проблему. Я публикую решение, поскольку оно может пригодиться будущим гуглерам.

По сути, я не запрашивал буфер глубины. Я делаю все рендеринг в нативном коде, но вся инициализация контекста Open GL выполняется на стороне Java. Я использовал один из примеров Android (GL2JNIActivity) в качестве отправной точки, но они не запрашивали буфер глубины, и я этого не заметил.

Я решил это, установив размер буфера глубины на 24 при установке ConfigChooser:

setEGLConfigChooser( translucent ?
                         new ConfigChooser(8, 8, 8, 8, 24 /*depth*/, 0) :
                         new ConfigChooser(5, 6, 5, 0, 24 /*depth*/, 0 );