QOpenGL -> glBegin/End x VBO
-
I would like to know why the Qt seems to support only development with OpenGL using VBO. I know the glBegin / end are falling into disuse. But I wonder why the Qt makes it so difficult to do things using these tools.
I am developing an application, and was five days to solve a problem. I now have 2 more problems to solve, but I only find Qt examples using VBO. I do not know VBO, barely I think tutorials to understand how. It is difficult to want to use this type of tool. Means that it has become a relief, but I did not think it would be so difficult to use Qt. Unfortunately I do not have enough time to rewrite my whole program. I'll try to make it work that way, but I think for the next version of my project, Qt will be left behind.
Att -
Hi,
You should take a look at the OpenGL in Qt 5.1 5 part blog posts on KDAB's website. It's an interesting read.
-
I think Qt's 5+ OpenGL support is now very influenced by mobile and therefore OpenGLES; around Qt5.1 I ported an "oldschool" OpenGL desktop app to iOS and did find QOpenGLFunctions absolutely invaluable for getting the thing working (despite knowing almost nothing about GLES). It did force me to give up my old glBegin habits though...and I can't imagine going back to them now. Also, some of the stuff I was doing with viewport-filling quads and shaders from the C++ side ended up much more concisely expressed with a fragment of GLSL in a QtQuick ShaderEffect in QML land.
-
I guess this is a question similar to "why does Qt have poor or no support for Windows 95?" - because it's old, discouraged and very little people care about it these days.
glBegin/glEnd style of OpenGL programming is obsolete in every possible sense. No new program should ever consider using these. It's not just a matter of preference but a performance problems going very deep. Issuing single commands was ok in 1998, when graphics accelerators like Voodoo were designed this way, but it's a straight performance killer for any GPU that was made in the last decade. These days it's all about batching, instancing and creating command lists, and that's what VBOs were invented for. GPUs and GPU drivers deeply and uterly hate single commands (like the glBegin/glVertex/glEnd) and they will make you pay dearly with heavy performance loss if you do insist on using them.
Yes, VBOs are harder to learn for a novice, but this is similar to comparing bubble sort to e.g. quick sort or a skateboard to a car - yes, it's harder to learn, but benefits are unquestionable. -
HoHo... the recent Khronos announcements at SIGGRAPH have got me looking at OpenGLSC (SC = safety critical); I didn't even know that was a thing until now. But I note one of the areas it differs from OpenGLES is:
Begin/End paradigm is supported (in addition to vertex arrays). A majority of 2D Safety Critical certifiable/qualifiable applications and tools rely on this mechanism. It enables a melding of program and data in such a way as to allow a certifying authority to more clearly understand an application.
:^)
-
@timday I'd suggest to provide more context as to avoid confusion. OpenGL SC is a whole different beast and all I said still stands - yes, begin/end paradigm is easier to learn and understand. As such it might be required in situations where this is an absolute priority over any kind of performance. A lot of features is removed from it and it's not something you reach to as your first choice, only when you are in some way required to - e.g. when programming a space probe with a low-power 3MHz chip without any kind of GPU in sight and a whole time in the world to compute while flying for years to the target, readability and correctness become a priority,
Also note that OpenGL SC 1.0 is defined in terms of OpenGL 1.3 (which is like ancient at this point) and there's a call for participation to create a 2.0 standard that I assume would be based either on something like OpenGL 4 (no begin/end in core profiles, note the "programmable shader pipeline subset" on the slides) or something else entirely - like Vulkan.
I don't think there's a support for OpenGL SC in Qt (or most consumer drivers for that matter) anyway.
-
All excellent and true points! I was just amused to see something where glBegin/glEnd was considered a feature for stronger reasons than the usual ones that it's easier to get started and/or that all the old OpenGL code lying around on the net still works. Pretty clear that OpenGLSC is for the niche-iest of niches though (I've worked in medical imaging SW for over a decade and hadn't heard of it; it was the volume rendered head in the press release caught my eye, but it turns out it's the specialized area of real time surgical systems is the medical "SC" use-case).
-
I guess it has it's place in solutions that really need strong quality assurance often tied with a requirement that the correctness is provable.
for example you can (even automatically) prove that this piece has (or doesn't have) error:glBegin(GL_TRIANGLES) glVertex3f(.0f, .0f, .0f); // too few ! glEnd();On the other hand this:
glDrawArrays(GL_TRIANGLES, 42, 666);although much much faster, driver friendly and hardware matching, depends on a whole bunch of other state that might not be so easily reasoned about statically or mechanically.
It's the same kinds of reasons that languages like Ada are still in use for mission-critical software like avionics, air-traffic or railway control. These are not the kind of applications you find on average Joe's laptop or iPhone.
