Lighting of the case using glNormalPointer(GL_BYTE


I am using OGLES_WINDOWS_PCEMULATION_2.07.27.0484

Results of lighting were different in two of the following.
I hoped that it was the same result.

  // Correct Result
  GLfloat FLOAT_normal_array[] = {0, 0, 1, 0, 0, 1, 0, 0, 1, …};
  glNormalPointer(GL_FLOAT, 0, FLOAT_normal_array);

  // Incorrect Result
  GLbyte BYTE_normal_array[] = {0, 0, 127, 0, 0, 127, 0, 0, 127, …};
  glNormalPointer(GL_BYTE, 0, BYTE_normal_array);

When glEnable(GL_NORMALIZE) is used, both results become right.

[Note: this answer appears to be incorrect at time of writing - please see below]

Actually, it's been pointed out to me that the byte vector (0,0,127,0) will need to be normalized as GL will of course read this as a vector of length 127. Obviously, the float vector (0,0,1.0,0) is in the same direction, but is already normalized. This means that what you report is expected behaviour. Apologies for the misleading message.

[Thanks for the report. I've passed this to the engineer in charge of PVRVFrame and given it issue number BRN31867 in our system. He should get back to you when he's investigated this]
Gordon2010-11-23 12:31:14

Thank you for your reply.

Just for reference, here are specification of OpenGL ES 1.1.

OpenGL ES Common/Common-Lite Profile Specification Version 1.1.12
(Full Specification) April 24, 2008

2.8 Vertex Arrays

 Transferring Array Elements

  For the normal array, all three coordinates are always specified. Byte, short,
  or integer values are converted to floating-point values as indicated for the
  corresponding (signed) type in table 2.7.


 | GL Type | Conversion          |
 | ubyte   | c/(2^8 - 1)         |
 | byte    | (2c + 1)/(2^8 - 1)  |
 | ushort  | c/(2^16 - 1)        |
 | short   | (2c + 1)/(2^16 - 1) |
 | fixed   | c/2^16              |
 | float   | c                   |

 Table 2.7: Component conversions. Color and normal components (c) are converted
 to an internal floating-point representation (f), using the equations in this

My reading of the document also leads me to believe that GL_NORMALIZE should not be required as the input vectors are identical (which is also what I originally suspected). I've re-opened the issue in our tracking system and it should be looked at shortly.

Looking at the formula for byte, the 127 values do represent 1.0 ( (2*127+1)/(2^8-1) = 1). The 0 values however don't become 0.0 ((2*0+1)/(2^8-1) != 0). I think the issue still needs investigation, however.

I apologise for a(nother) misleading post - thanks for your patience. This is a classic example of where I should look at the spec myself and not go by what others say Embarrassed
Gordon2010-11-23 15:09:15