Byte color specification and gl_FrontFacing

OpenGL OpenGL: User Software
1

Hi folks,

Relative newbie here.

I’m working on the Android platform with GLES2.0.

I wrote my game using floating point colors specs and all was working great.

Then I decided to try to optimize speed and memory, and re-formatted my colors as bytes packed into in an integer.

My game mostly works the same, but one feature is now gone: my triangles do not respond to the gl_FrontFacing variable as before.

Here’s my fragmentShader code:

private final String mFragmentShader =
"precision mediump float;
" +
"varying vec4 vColorValue;
" +
“void main() {
" +
" if(gl_FrontFacing) {
" +
" gl_FragColor = 0.5*vColorValue;
" +
" }else {
" +
" gl_FragColor = vColorValue;
" +
" }
;”+
"}
";

Now that I have colors entering the system as bytes packed ABGR into an integer, the front facing triangles are no longer muted, as was working using floating point color specs.

But I know that gl_FrontFacing is still in effect: if I change 0.5 to 0.0, the front facing triangles disappear.

Is this just an expected result or have I done something stupid?

I’m having a devil of a time trying to unearth the answer from internet searches.

Should I use some special data type in my vertex attribute call?

		GLES20.glVertexAttribPointer(maColorValueHandle, 4, GLES20.GL_UNSIGNED_BYTE, false,
				TRIANGLE_VERTICES_DATA_STRIDE_BYTES, mTriangleVertices);

I’ve tried a few that I can see in the docs, but this is the only one that works at all.

Any advise would be appreciated. Thanks!

Thender

2

[QUOTE=thender;1237468]I’m working on the Android platform with GLES2.0. …

Now that I have colors entering the system as bytes packed ABGR into an integer, the front facing triangles are no longer muted…

GLES20.glVertexAttribPointer(maColorValueHandle, 4, GLES20.GL_UNSIGNED_BYTE, false,
                    TRIANGLE_VERTICES_DATA_STRIDE_BYTES, mTriangleVertices);

[/QUOTE]

I’m no GLES guru (or even newbie), but just from looking at your glVertexAttribPointer call, one thing that grabs my attention is that “false”. If you put colors into a normalized fixed-point format (e.g. 0…255 for UBYTE[4], rather than the 0…1 used with FLOAT[4]), then you must tell GL that by setting the normalized flag to “true”. This tells the GL implementation to take your normalized fixed-point values and map them to 0…1 behind-the-scenes before populating the float input values (e.g. vec4) in the shader.

BTW, please use [code]…[/code] blocks (without the backslashes) to mark your code in forum postings. Makes them easier to read.

3

Thanks for that suggestion and for taking the time to look. But apparently that did not do the trick.

My shaky and developing understanding was that color data is floating point by the time it reaches the fragmentShader in any case.

The real puzzle is that the colors (simple red, green and blue triangles) show up as expected (with either true or false ) but apparently are not multiplying like floating point values.

Could this be something peculiar to Android GLES20 or even something in my ASUS Transformer hardware?

Maybe I need to post on the Android forum?

Looks like you have enough experience to say that it should work when using “true” in the glVertexAttribPointer call.

Thender

[QUOTE=Dark Photon;1237470]I’m no GLES guru (or even newbie), but just from looking at your glVertexAttribPointer call, one thing that grabs my attention is that “false”. If you put colors into a normalized fixed-point format (e.g. 0…255 for UBYTE[4], rather than the 0…1 used with FLOAT[4]), then you must tell GL that by setting the normalized flag to “true”. This tells the GL implementation to take your normalized fixed-point values and map them to 0…1 behind-the-scenes before populating the float input values (e.g. vec4) in the shader.

BTW, please use [code]…[/code] blocks (without the backslashes) to mark your code in forum postings. Makes them easier to read.[/QUOTE]

4

No, Dark Photon was right!

I have no idea what I was looking at last night, but this morning it is working.

Now the text in the documentation has been focused in my mind. If you want to, for example, place a 1 (full color) using a byte value, put the argument to false.

If you want to do what I was trying to do, use byte 255 as the full color value, it must be converted to a floating point 1. (normalized), and the “true” argument accomplishes this.