Lighting of the case using glNormalPointer(GL_BYTE

This topic contains 3 replies, has 2 voices, and was last updated by  Gordon 6 years, 11 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #30352

    PenCyot3
    Member

    Hi

    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.

    #34515

    Gordon
    Moderator

    [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

    #34516

    PenCyot3
    Member

    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
     table.

    #34517

    Gordon
    Moderator

    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

Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic.