Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Switching from QOpenGLExtraFunctions to QOpenGLFunctions_4_4_Core broke rendering
Forum Updated to NodeBB v4.3 + New Features

Switching from QOpenGLExtraFunctions to QOpenGLFunctions_4_4_Core broke rendering

Scheduled Pinned Locked Moved Solved General and Desktop
15 Posts 3 Posters 1.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    mr.indieperson
    wrote on last edited by mr.indieperson
    #1

    I need a function from modern OpenGL, so QOpenGLExtraFunctions is no more enough.
    I've replaced all QOpenGLExtraFunctions entries with QOpenGLFunctions_4_4_Core .
    And I've changed

    f = context()->extraFunctions();
    f->initializeOpenGLFunctions();
    

    to

    f = context()->versionFunctions<QOpenGLFunctions_4_4_Core>();
    

    I can successfully use QOpenGLFunctions_4_4_Core to, for example, change the glClearColor to green, so the functions are initialized.

    But my rendering is broken. I was rendering a colored rectangle as a background, for example, but now I see nothing but the empty area of a QOpenGLWidget filled with the background color.

    Why did switching from QOpenGLExtraFunctions to QOpenGLFunctions_4_4_Core changed the state of OpenGL so rendering is broken? Or do I miss something?

    My OpenGL implementation version is 4.4, and I set 4.4 Core in a QSurfaceFormat before I pass it to QOpenGLWidget::setFormat.

    Answer

    I've found the source of the problem.

    I was drawing offscreen into my FBO and then doing post-processing drawing a frame quad into the default framebuffer. And I was calling glBindFrameBuffer(GL_DRAW_FRAMEBUFFER, 0) to set the default framebuffer. However the default framebuffer created by QOpenGLWidget has id 4, it is an offsreen FBO. But for some reason everything was working with QOpenGLExtraFunctions. But when I switched to QOpenGLFunctions_4_4_Core the issue revealed itself, and I was seeing nothing but the area filled with the clear color. Now I call glBindFrameBuffer(GL_DRAW_FRAMEBUFFER, defaultFboId), where defaultFboId is 4, and the issue was fixed.

    The only explanation I may suggest is that though QOpenGLFunctions_4_4_Core has the same functions as QOpenGLExtraFunctions plus some new, these two classes actually have different code for their functions (I have no time to look into the sources) OR they map their function calls to different OpenGL API functions (is it possible?), and so the executed by the driver code of glBindFrameBuffer is different for these two classes.

    Though I have no idea why my code was working when I was passing 0 instead of 4 specifying wrong framebuffer. May be QOpenGLExtraFunctions version of glBindFrameBuffer is less restricted and can handle some errors.

    1 Reply Last reply
    1
    • fcarneyF Offline
      fcarneyF Offline
      fcarney
      wrote on last edited by
      #2

      Core programming is very different than compatibility mode. You have to program opengl differently than most of the examples on the internet.

      This site should help. It covers the basics in depth:
      https://learnopengl.com/

      Also search on the differences between core programming and compatibility mode. If you don't have the patience for that then use a non core version of the functions.

      C++ is a perfectly valid school of magic.

      M 1 Reply Last reply
      0
      • fcarneyF fcarney

        Core programming is very different than compatibility mode. You have to program opengl differently than most of the examples on the internet.

        This site should help. It covers the basics in depth:
        https://learnopengl.com/

        Also search on the differences between core programming and compatibility mode. If you don't have the patience for that then use a non core version of the functions.

        M Offline
        M Offline
        mr.indieperson
        wrote on last edited by mr.indieperson
        #3

        @fcarney But I thought I was programming in core mode...
        I've set QSurfaceFormat::setProfile(QSurfaceFormat::OpenGLContextProfile::CoreProfile) and so created a context in core mode, but was I actually using compatibility version of functions with core profile?

        Because I actually already was following some of the rules to program in core mode. Like I have to bind VAO always when I call glDrawArrays

        1 Reply Last reply
        0
        • fcarneyF Offline
          fcarneyF Offline
          fcarney
          wrote on last edited by
          #4

          I guess I made a poor assumption. I was thinking you might be uninformed what core mode was. Not sure on that. I am not sure what QOpenGLExtraFunctions assumes as far as modes. Can you check to see if you were indeed in core mode? I wonder if using those functions makes the assumption you are not. Or if something really is broken.

          C++ is a perfectly valid school of magic.

          M 1 Reply Last reply
          0
          • fcarneyF fcarney

            I guess I made a poor assumption. I was thinking you might be uninformed what core mode was. Not sure on that. I am not sure what QOpenGLExtraFunctions assumes as far as modes. Can you check to see if you were indeed in core mode? I wonder if using those functions makes the assumption you are not. Or if something really is broken.

            M Offline
            M Offline
            mr.indieperson
            wrote on last edited by mr.indieperson
            #5

            @fcarney I've tried to switch to QOpenGLFunctions_4_4_Compatibility, but now QOpenGLContext::versionFunctions<QOpenGLFunctions_4_4_Compatibility>() returns NULL, what is expected, because I'm creating the context in core mode, because I've set that in QSurfaceFormat. I'm pretty sure I always was in Core mode... Don't know how to check that exactly, but that would be very surprising, If QT was initializing Compatibility profile.

            1 Reply Last reply
            0
            • fcarneyF Offline
              fcarneyF Offline
              fcarney
              wrote on last edited by fcarney
              #6

              Did 4.4 introduce any more shader programs that need to be defined for the pipeline? I seem to remember it adding 2 new shader types to the pipeline, but I was not sure they were required to be defined.

              Edit: Versus 3.3

              C++ is a perfectly valid school of magic.

              W M 2 Replies Last reply
              0
              • fcarneyF fcarney

                Did 4.4 introduce any more shader programs that need to be defined for the pipeline? I seem to remember it adding 2 new shader types to the pipeline, but I was not sure they were required to be defined.

                Edit: Versus 3.3

                W Offline
                W Offline
                wrosecrans
                wrote on last edited by
                #7

                @fcarney As far as I know, you aren't required to use any of the new shader types. Just opt-in if they are useful for you. Using 3.3 core profile code under 4.4 should normally Just Work.

                Try breaking out the debug logger class and see if it spits out anything useful: https://doc.qt.io/qt-5/qopengldebuglogger.html

                ?

                M 1 Reply Last reply
                1
                • W wrosecrans

                  @fcarney As far as I know, you aren't required to use any of the new shader types. Just opt-in if they are useful for you. Using 3.3 core profile code under 4.4 should normally Just Work.

                  Try breaking out the debug logger class and see if it spits out anything useful: https://doc.qt.io/qt-5/qopengldebuglogger.html

                  ?

                  M Offline
                  M Offline
                  mr.indieperson
                  wrote on last edited by mr.indieperson
                  #8

                  @wrosecrans Yes, I'm already monitoring OpenGL errors using glDebugMessageCallback, but It shows no error, as well as glGetError

                  1 Reply Last reply
                  0
                  • fcarneyF fcarney

                    Did 4.4 introduce any more shader programs that need to be defined for the pipeline? I seem to remember it adding 2 new shader types to the pipeline, but I was not sure they were required to be defined.

                    Edit: Versus 3.3

                    M Offline
                    M Offline
                    mr.indieperson
                    wrote on last edited by mr.indieperson
                    #9

                    @fcarney I think that the point is that I already was successfully rendering in 4.4 Core, and now I just have changed the class which provides the OpenGL functions, I didn't change the OpenGL profile, and so I don't use any new features. QOpenGLFunctions_4_4_Core just has to give me more functions, but instead it broke already successfully used, may be some function calls don't happen for some reason, and so OpenGL state is broken.

                    1 Reply Last reply
                    0
                    • fcarneyF Offline
                      fcarneyF Offline
                      fcarney
                      wrote on last edited by
                      #10

                      It says here that OpenGLExtraFunctions is for OpenGL ES:
                      https://doc.qt.io/qt-5/qopenglextrafunctions.html#details

                      Maybe that is the difference. I have not programmed ES so I am unsure if the calls would be compatible.

                      C++ is a perfectly valid school of magic.

                      M 2 Replies Last reply
                      0
                      • fcarneyF fcarney

                        It says here that OpenGLExtraFunctions is for OpenGL ES:
                        https://doc.qt.io/qt-5/qopenglextrafunctions.html#details

                        Maybe that is the difference. I have not programmed ES so I am unsure if the calls would be compatible.

                        M Offline
                        M Offline
                        mr.indieperson
                        wrote on last edited by
                        #11

                        @fcarney May be. I guess I have to make a separated project with minimal working code to determine the problem and where is the difference.

                        1 Reply Last reply
                        0
                        • fcarneyF fcarney

                          It says here that OpenGLExtraFunctions is for OpenGL ES:
                          https://doc.qt.io/qt-5/qopenglextrafunctions.html#details

                          Maybe that is the difference. I have not programmed ES so I am unsure if the calls would be compatible.

                          M Offline
                          M Offline
                          mr.indieperson
                          wrote on last edited by
                          #12

                          @fcarney Hi, I've solved the issue, I've appended explanation into the first post, that is a strange behavior for me, or I may miss something about how does QT work with framebuffers.

                          1 Reply Last reply
                          0
                          • fcarneyF Offline
                            fcarneyF Offline
                            fcarney
                            wrote on last edited by fcarney
                            #13

                            @mr.indieperson said in Switching from QOpenGLExtraFunctions to QOpenGLFunctions_4_4_Core broke rendering:

                            glBindFrameBuffer

                            Did you call glGenFramebuffers or where did you get the number for that framebuffer?
                            https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBindFramebuffer.xhtml

                            Apparently 0 breaks the binding to the GL_DRAW_FRAMEBUFFER

                            Edit: If its a "magic" number you tried it is likely to break later.

                            C++ is a perfectly valid school of magic.

                            M 2 Replies Last reply
                            0
                            • fcarneyF fcarney

                              @mr.indieperson said in Switching from QOpenGLExtraFunctions to QOpenGLFunctions_4_4_Core broke rendering:

                              glBindFrameBuffer

                              Did you call glGenFramebuffers or where did you get the number for that framebuffer?
                              https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBindFramebuffer.xhtml

                              Apparently 0 breaks the binding to the GL_DRAW_FRAMEBUFFER

                              Edit: If its a "magic" number you tried it is likely to break later.

                              M Offline
                              M Offline
                              mr.indieperson
                              wrote on last edited by mr.indieperson
                              #14

                              @fcarney No, that is not a magic number, I actually call
                              f->glGetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &defaultFboId) in QOpenGLWidget::paintGL, it just returns 4 always with current project code. Of course it may change.

                              1 Reply Last reply
                              1
                              • fcarneyF fcarney

                                @mr.indieperson said in Switching from QOpenGLExtraFunctions to QOpenGLFunctions_4_4_Core broke rendering:

                                glBindFrameBuffer

                                Did you call glGenFramebuffers or where did you get the number for that framebuffer?
                                https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glBindFramebuffer.xhtml

                                Apparently 0 breaks the binding to the GL_DRAW_FRAMEBUFFER

                                Edit: If its a "magic" number you tried it is likely to break later.

                                M Offline
                                M Offline
                                mr.indieperson
                                wrote on last edited by
                                #15

                                @fcarney And well, I've remembered about QOpenGLWidget::defaultFramebufferObject, it returns the same value as f->glGetIntegerv(GL_DRAW_FRAMEBUFFER_BINDING, &defaultFboId), which I had to use when I was binding the default QT's framebuffer to do final rendering, but I just passed 0 and it was working, so I was thinking about it no more.

                                1 Reply Last reply
                                1

                                • Login

                                • Login or register to search.
                                • First post
                                  Last post
                                0
                                • Categories
                                • Recent
                                • Tags
                                • Popular
                                • Users
                                • Groups
                                • Search
                                • Get Qt Extensions
                                • Unsolved