Missing OpenGL class and functionality in Qt 5
-
Hi!
I would like to ask if anyone knows whether to what extent does Qt intend on supporting OpenGL with helper classes. I have seen that in Qt 5.1 many-many new classes were introduced, such as QOpenGLFrameBufferObject, which is great if one needs the Color Attachments. However if one would like to use other features of a FBO, for eg. obtain the Z-buffer inside it, it's practically impossible. The feature of getting one or more of the buffers as an image is a good feature, but I would imagine that QOpenGLTexture is a class that the the rest of the framework is in dire need of (if I'm not mistaken QPainter already has a simplified version implemented for internal use), and also QOpenGLFrameBufferObject to interface with it.
Ultimately I think it would make more sense if there were a QOpenGLRenderBuffer, a QOpenGLTexture class, these would interface with QOpenGLFrameBufferObject, and only the prior 2 could be obtained as a QImage, and not the FBO itself, which makes the enourmous assumption that I'm interested in the first colorbuffer.
As far as I looked at the dev snapshots, Qt5.2 does not yet have QOpenGLTexture (not to mention this more meaningful use of the FBO wrapper class). Is there any chance that any of these make it into Qt 5.2 perhaps? Or is this such a bad idea?
-
OpenGL is actively (and quite passionately) developed by KDAB and friends. You can ask "ZapB":http://qt-project.org/member/3246 he is the maintainer and as I understand he is very appreciative of any feedback/ suggestions.
-
Hi,
Aha! As chance would have it I am working on a QOpenGLTexture class right now. I will be posting it to gerrit for review shortly but I still need to make it compatible with OpenGL ES 2. It's already usable on desktop OpenGL and handles all texture formats, targets including texture arrays and multisample textures, immutable storage (where available), swizzling, setting of texture and sampler parameters etc. I'll try to get the texture stuff pushed to gerrit this week so you can take a look at it and try it out. I'll post back here with a link when it's up.
As a followup to this work I will also be touching QOpenGLFramebufferObject which as you hav enoted does not expose much of what it should do in an ideal world. QOpenGLFramebufferObject is a simple port of the old QGLFramebufferObject could do with some love and attention. The plan is to make it trivial to get access to any of the renderbuffer of texture attachments and to interoperate with QOpenGLTexture easily. This is next on my list.
If you need this quickly then you could always try making use of QOpenGLTexture and just handling the FBO parts that you need using raw OpenGL wrapped up in a simple class.
-
I am completely unfamiliar with gerrit and using it, but as far as I understand, I need not register in any way to clone commits from gerrit, as it is mirrored in gitorius which has anonymus read-only privilage. My only problem is, I could not figure out how to search for commits from a specific contributer, which makes it quite hard to catch your commit.
Sorry for the noobish questions, but I have never come across anything more sophisticated than git alone as a team development facilitation.
I certainly would be among the firsts to make use of these classes, and if I could clone a repo with QOpenGLTexture class inside, I could start testing with either raw FBO management, or via a thin custom-made wrapper.
Until you commit, I'll start making friends with QTcpSocket, as that is the next feature for me down the road.
-
Hi again, there is now an early WIP version of a patch to add QOpenGLTexture up for review/testing at https://codereview.qt-project.org/#change,56462
I've not yet had time to do the FBO aspects.
-
Hi!
This seems like nice work. I do not agree with not having to remap GL types, since they are only enum types, so if one does not wish to use them, they don't have to, but they are useful with return values where one does not get confused with the possible return values if they are packed together in an enum group (not to mention type correctness).
Keep up the good work!
Do you plan on making Textures renderable instead of (or beside) QFBO? Do you plan on making QRenderBuffers?
It might be that my OpenGL knowledge is too limited, but what is DepthDtencilMode used for if GL_DEPTH_STENCIL is missing? I see GL_DEPTH_COMPONENT and GL_STENCIL_INDEX, but not the third.
-
I see that QOpenGLTexture is under construction with active criticism on code review.
I wanted to ask: is there hope of the Texture and FBO classes to make it into mainline Qt 5.2? That could mean a Beta could be out to be tested sometime around September. (If the final is really expected around Christmas)
-
Hi Meteorhead,
You're more likely to have your question answered if you ask on the "Development mailing list":http://lists.qt-project.org/mailman/listinfo/development where Qt's engineers reside -- this forum is more for people who use Qt, and we don't always have the latest info on the plans for Qt
EDIT: Whoops, didn't notice ZapB up there!
-
I have commented the code on Gerrit, however there is one thing I hesitate writing there.
Is it by design that QOpenGLTexture(2d) do not have toImage() function(s)? They contain all the information neccessary to be rendered on a canvas, it has a well defined meaning, it would be damned useful... I see no reason why to leave this feature out.
It would greatly facilitate my job, since I wish to push Render Buffers through a network, and display them on a very thin client application. Since the QDataStream has << operator for Images, I need not implement anything, just transform the Texture into an Image with the built-in function, push it through the network and draw it with even OpenGL 2.0 (even if the source heavy render engine uses 4.3).
Ideas?
-
Hi!
I see that QOpenGLTexture has been commited into dev-branch marked as Patch #13. I have no knowledge of how the docs are generated, but 5.2 doc snapshot does not yet contain QOpenGLTexture. Is it waiting for manual attendance? The docs should give a clearer picture for outsiders to comment on the interface and the capabilities of the classes themselves.
Looking at the code, big congrats to Sean and Giuseppe for putting this together. This is just the thing missing to cleanly integrate my custom-made raycaster into my app's GUI.
