Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Does fragment shader only ouput normalized values?

  1. #11
    Junior Member Newbie
    Join Date
    Aug 2013
    Posts
    15
    Dear carsten neumann, I appreciate for your contribution. By making the following change,

    FragColor = vec4(FaceID.x/255.0f, FaceID.y/255.0f, FaceID.z/255.0f, 1.0);

    The default frame buffer shows me the CORRECT result, proving that the unsigned bytes are successfully passed from host program to vertex shader, then from vertex shader to fragment shader.

    However, I further tested that, uvec3 can not be used as the output type for a custom frame buffer .

    Here is the details of my testing process:
    1). Set GL_RGB8UI as the custom render buffer storage internal format:

    glRenderbufferStorage(GL_RENDERBUFFER, internalformat, width, height);

    2). Set uvec3 as the fragment output type in the fragment shader:
    #version 400

    flat in uvec3 FaceID;
    layout( location = 0 ) out uvec3 FragFaceID;
    void main() {

    FragFaceID = FaceID;
    }

    3). Read the pixels in the custom render buffer:

    framebuffer_.bind();
    glReadBuffer(GL_COLOR_ATTACHMENT0);
    glReadPixels(0, 0, glViewportWidth_, glViewportHeight_, GL_RGB, GL_UNSIGNED_BYTE, src_);

    Debugging the code, I found that the data I read back are all zeros.

    On contrary, use GL_RGB8 in step 1; normalize the data and and use vec3 in step 2,

    #version 400

    flat in uvec3 FaceID;
    layout( location = 0 ) out vec3 FragFaceID;

    void main() {

    FragFaceID = vec3(FaceID.x/255.0f, FaceID.y/255.0f, FaceID.z/255.0f);
    }

    we get the correct result in step 3.

    It seems that my assumption: "fragment shader only ouput normalized values" turns to be right. But I really hope that somebody could tell me it is not the truth, and give me instructions to show my assumption is wrong.

  2. #12
    Advanced Member Frequent Contributor arekkusu's Avatar
    Join Date
    Nov 2003
    Posts
    761
    You should read all of the documentation about integer processing.

    You'll need to use GL_RGB_INTEGER (not GL_RGB) when moving integer data around, like with glReadPixels.

  3. #13
    Junior Member Newbie
    Join Date
    Aug 2013
    Posts
    15
    BTW, according to Alfonse Reinheart's comments, I also tested 4-component format. I still got all-zero if GL_RGBA8UI is used in step 1 and uvec4 is used in step 2.

  4. #14
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Of course you get all zeros. You're passing a floating-point value between 0 and 1 to an integer. Zero or one is the only reasonable outcome of that.

    If you wanted the numbers 0 to 255, then you shouldn't be dividing by 255.

  5. #15
    Junior Member Newbie
    Join Date
    Aug 2013
    Posts
    15
    Quote Originally Posted by arekkusu View Post
    You should read all of the documentation about integer processing.

    You'll need to use GL_RGB_INTEGER (not GL_RGB) when moving integer data around, like with glReadPixels.
    Hi, arekkusu. Thanks for hitting the point. Using GL_RGB_INTEGER in step3, I got the CORRECT result. Yes, I actually read the latest version of Opengl programming guide. In that book, it says the format could be GL_RGB or GL_RGB_INTEGER. The word 'or' makes me believe that these two formats are equivalent.

    Now, the bulb of my assumption goes to be exploded. I am very happy with that.

    Finally, many many thanks to all of you. You teach me a lot.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •