fscz
Posts: 6
Joined: Sat May 02, 2015 2:12 pm

opengl es 2.0 varying interpolation

Sat May 02, 2015 2:55 pm

The attachment cube_front.png is no longer available
I am trying to store normals that are supplied as attributes to a vertex shader into a fbo by passing
those normals from the vertex shader to the fragment shader through a varying.

Vertex Shader Code:
attribute vec4 a_position;
attribute vec3 a_normal;
varying vec3 v_normal;

uniform mat4 u_world;
uniform mat4 u_view;
void main() {
gl_Position = u_view * u_world * a_position;
v_normal = u_view * u_world * a_normal;
}

Fragment Shader Code:
varying vec3 v_normal;
void main() {
gl_FragColor = vec4(abs(v_normal.xy), 0.0, 1.0);
// the absolute is to check correctness by visualizing the
// fbo texture (underlying this fragment). the idea is that a cube,
// seen from the front ( with normal: 0.0, 0.0, -1.0) should not be visible
// on the underlying texture.
}

Here is the cube mesh:

# cube.obj
#

g cube

v 0.0 0.0 0.0
v 0.0 0.0 1.0
v 0.0 1.0 0.0
v 0.0 1.0 1.0
v 1.0 0.0 0.0
v 1.0 0.0 1.0
v 1.0 1.0 0.0
v 1.0 1.0 1.0

vn 0.0 0.0 1.0
vn 0.0 0.0 -1.0
vn 0.0 1.0 0.0
vn 0.0 -1.0 0.0
vn 1.0 0.0 0.0
vn -1.0 0.0 0.0

f 1//2 7//2 5//2
f 1//2 3//2 7//2
f 1//6 4//6 3//6
f 1//6 2//6 4//6
f 3//3 8//3 7//3
f 3//3 4//3 8//3
f 5//5 7//5 8//5
f 5//5 8//5 6//5
f 1//4 5//4 6//4
f 1//4 6//4 2//4
f 2//1 6//1 8//1
f 2//1 8//1 4//1


Oddly enough, it is visible. See the attached file for a screenshot, where I visualise only the (absolute) x value of the 2 triangles. Obviously as the normal is given by (0.0, 0.0, -1.0) there should not be an x value and therefore the whole texture should be black.

The opengl es specification: https://www.khronos.org/registry/gles/s ... 1.0.17.pdf
clearly says under "4.3.5 Varying" that varyings get interpolated between the vertices of the given primitive.

In my case the primitive is GL_TRIANGLES and I am supplying the same normal to all vertices of each triangle. Therefore I would expect "v_normal" in the fragment shader to have just the same value as a_normal in the vertex shader (modulo the the view * world projection). However this does not seem to be the case.

If I edit the cube mesh and remove all faces but the first two - which are the only ones that can be visible on the screen - I get the expected result: A black texture.

This leads me to believe that the varying interpolation is not local to the current primitive but computed somehow differently. How and why I am not sure though.

Any comments or insights are welcome.
Attachments
cube_front.png
cube visible, even though it shouldn't be.
cube_front.png (1.51 KiB) Viewed 3461 times
Last edited by fscz on Sat May 02, 2015 9:27 pm, edited 1 time in total.

User avatar
PeterO
Posts: 4241
Joined: Sun Jul 22, 2012 4:14 pm

Re: opengl es 2.0 varying interpolation

Sat May 02, 2015 3:57 pm

"If I edit the cube mesh and remove all faces but the first two - which are the only ones that can be visible on the screen - I get the expected result: A black texture. "

So is the colour comming from the back face ? It isn't obvious to me why that isn't being draw.

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
Paeryn
Posts: 2140
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: opengl es 2.0 varying interpolation

Sat May 02, 2015 7:45 pm

Is that a typo in your vertex shader? You never reference a_normal and are attempting to assign a mat4 to a vec3.

Code: Select all

v_normal = u_view * u_world;
Thinking about what you said, if you only draw the first two triangles it works. That leads me to think what you are seeing is from the other triangles being drawn infront. Are you using back face culling to prevent backwards facing triangles being rendered? Are you using a depth buffer to prevent further away fragments from overwriting nearer ones?
She who travels light — forgot something.

fscz
Posts: 6
Joined: Sat May 02, 2015 2:12 pm

Re: opengl es 2.0 varying interpolation

Sat May 02, 2015 9:31 pm

So is the colour comming from the back face ? It isn't obvious to me why that isn't being draw.


I have backface culling on. I have really checked, I am seeing, what I think I see. - various other texture renderings, f.e. depth texture confirm this.

fscz
Posts: 6
Joined: Sat May 02, 2015 2:12 pm

Re: opengl es 2.0 varying interpolation

Sat May 02, 2015 9:34 pm

Paeryn wrote:Is that a typo in your vertex shader? You never reference a_normal and are attempting to assign a mat4 to a vec3.

Code: Select all

v_normal = u_view * u_world;
yeah, there was a typo. corrected it.

Thinking about what you said, if you only draw the first two triangles it works. That leads me to think what you are seeing is from the other triangles being drawn infront. Are you using back face culling to prevent backwards facing triangles being rendered? Are you using a depth buffer to prevent further away fragments from overwriting nearer ones?
Good idea. I do. Here is the code that sets up the framebuffer object, that I am talking about here:

// FBO 0
glBindTexture(GL_TEXTURE_2D, sceneData->tbos[0]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, ctx->esContext->screenWidth, ctx->esContext->screenHeight, 0, GL_RGBA, GL_UNSIGNED_BYTE, NULL);
glBindTexture(GL_TEXTURE_2D, 0);

glBindRenderbuffer(GL_RENDERBUFFER, sceneData->rbos[0]);
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT32_OES, ctx->esContext->screenWidth, ctx->esContext->screenHeight);
glBindRenderbuffer(GL_RENDERBUFFER, 0);

glBindFramebuffer(GL_FRAMEBUFFER, sceneData->fbos[0]);
glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, sceneData->tbos[0], 0);
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, sceneData->rbos[0]);

status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if ( GL_FRAMEBUFFER_COMPLETE != status ) {
log_message ("error: could not set up gbuffer");
return -1;
}


And here is the code that is executed before rendering to this framebuffer:
glBindFramebuffer(GL_FRAMEBUFFER, sceneData->fbos[0]);
glDisable(GL_BLEND);
glEnable(GL_DEPTH_TEST);
glEnable(GL_CULL_FACE);
glDisable(GL_BLEND);
glFrontFace(GL_CCW);
glCullFace(GL_BACK);

fscz
Posts: 6
Joined: Sat May 02, 2015 2:12 pm

Re: opengl es 2.0 varying interpolation

Sat May 02, 2015 9:56 pm

If I render only the following faces:
-----------------
f 1//2 7//2 5//2
f 1//2 3//2 7//2

f 2//1 6//1 8//1
f 2//1 8//1 4//1
-----------------
which correspond to the back and front plane of the cube, I get a black texture.

I also get a black texture, if I render only the front plane, like so:
-----------------
f 1//2 7//2 5//2
f 1//2 3//2 7//2
-------------------

Or just the back plane, like so:
-------------------
f 2//1 6//1 8//1
f 2//1 8//1 4//1
-----------------


If I add in the right hand side plane, like so:
-------------------
f 1//2 7//2 5//2
f 1//2 3//2 7//2
f 5//5 7//5 8//5
f 5//5 8//5 6//5
f 2//1 6//1 8//1
f 2//1 8//1 4//1
-------------------
I get a red quad and that puzzles me quite a bit.

User avatar
Paeryn
Posts: 2140
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: opengl es 2.0 varying interpolation

Sun May 03, 2015 12:51 am

I can't check it right now but your normal calculation still looks wrong, you shouldn't be able to multiply a mat4 by a vec3, you need to set the w component to 0 before multiplying by the matrix. Maybe the generated shader is picking up the w component from whatever was last in the register. Something along the lines of

Code: Select all

v_normal = (u_view * u_world * vec4(a_normal, 0.0)).xyz;
It still looks wierd that the right hand face is producing a front facing square.
She who travels light — forgot something.

User avatar
PeterO
Posts: 4241
Joined: Sun Jul 22, 2012 4:14 pm

Re: opengl es 2.0 varying interpolation

Sun May 03, 2015 6:25 am

Can you put all your code somewhere (tar ball?) so we can all have a try at this ?

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

fscz
Posts: 6
Joined: Sat May 02, 2015 2:12 pm

Re: opengl es 2.0 varying interpolation

Sun May 03, 2015 2:40 pm

[quote="Paeryn"]I can't check it right now but your normal calculation still looks wrong, you shouldn't be able to multiply a mat4 by a vec3, you need to set the w component to 0 before multiplying by the matrix. Maybe the generated shader is picking up the w component from whatever was last in the register. Something along the lines of

Code: Select all

v_normal = (u_view * u_world * vec4(a_normal, 0.0)).xyz;
Yeah, this confused me aswell, but I have tried with and without the 4th component and it doesn't make a difference. Compiles, links and runs in both ways and performs just the same.

fscz
Posts: 6
Joined: Sat May 02, 2015 2:12 pm

Re: opengl es 2.0 varying interpolation

Sun May 03, 2015 2:42 pm

[quote="PeterO"]Can you put all your code somewhere (tar ball?) so we can all have a try at this ?

Ah, well. It's a full blown render engine with a python binding and all... bit hard to do.

User avatar
PeterO
Posts: 4241
Joined: Sun Jul 22, 2012 4:14 pm

Re: opengl es 2.0 varying interpolation

Sun May 03, 2015 5:21 pm

fscz wrote:
PeterO wrote:Can you put all your code somewhere (tar ball?) so we can all have a try at this ?
Ah, well. It's a full blown render engine with a python binding and all... bit hard to do.
In which case produce the minimum code that displays the problem. It looks like a simple fragment shader, a trivial vertex shader, and some glue should do it....

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

User avatar
Paeryn
Posts: 2140
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: opengl es 2.0 varying interpolation

Mon May 04, 2015 2:24 pm

I've just tried a basic run with your given shaders and cube data. Not knowing your matricies I set them up one to identity and the other rotating around the y-axis. It looked fine to me. The only time I got anywhere near what you showed was when I accidentally copied the vertex position data wrong (I copied 4 elements per vertex instead of 3) when making the triangle lists.
You'll have to give us a full sample where it goes wrong for us to help figure out what you're doing wrong.
She who travels light — forgot something.

User avatar
paddyg
Posts: 2178
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: opengl es 2.0 varying interpolation

Mon May 04, 2015 3:26 pm

normals.jpg
normals.jpg (28.98 KiB) Viewed 3258 times
If it's any use, in pi3d I have to have normals at each vertex for each side that meets there, otherwise I get smoothed (interpolated) sides as per your diagram. I don't know if you're doing that.
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

User avatar
Paeryn
Posts: 2140
Joined: Wed Nov 23, 2011 1:10 am
Location: Sheffield, England

Re: opengl es 2.0 varying interpolation

Mon May 04, 2015 5:06 pm

paddyg wrote:If it's any use, in pi3d I have to have normals at each vertex for each side that meets there, otherwise I get smoothed (interpolated) sides as per your diagram. I don't know if you're doing that.
I think fscz is - or at least is meaning to. His data lists 8 vertex positions, 6 normals and 12 faces. Each face is listed with 3 points in the format: vertex_number//normal_number. Each pair of faces defines a side of the cube and the normals are the same for all points in each pair, each pair uses a different normal.
It could well be that fscz is generating his triangle list arrays wrongly - I did accidentally when trying to copy what he did and got similarly shaded faces.
She who travels light — forgot something.

User avatar
paddyg
Posts: 2178
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: opengl es 2.0 varying interpolation

Mon May 04, 2015 7:21 pm

Yes the array passed to glBufferData(GL_ARRAY_BUFFER,.. is the critical thing (and seeing the code for that would confirm or disprove my suggestion). However the effect shown is what I would get if I passed an array of 8 x (vx,vy,vz,nx,ny,nz,u,v) say, when I actually needed to pass 24.
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

User avatar
PeterO
Posts: 4241
Joined: Sun Jul 22, 2012 4:14 pm

Re: opengl es 2.0 varying interpolation

Mon May 04, 2015 7:25 pm

This is why I asked to see the OP's code... It looks like some form of mis-sized arrays to me :-)

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),Aeromodelling,1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

Return to “OpenGLES”

Who is online

Users browsing this forum: No registered users and 2 guests