QML as per my knowledge does the same thing as OpenGL, right? So can I completely replace OpenGLwith QML ?
Whats the basic difference between QML and OpenGL?
When does people prefer QML over OpenGL and vice versa?
Your knowledge is incorrect, QML and OpenGL are two completely different things, the first is a declarative language the second is a graphics API.
QtQuick which uses QML usually uses OpenGL for its graphics, but that's a back-end you don't have any access to (it actually got a little more accessible in the recent releases but I expect not many people will go into tweaking that, and even if they did, it would be in C++, not QML).
There is Qt3D, which has a QML API, but it is just some basic stuff and it is high level - by no means a substitute to OpenGL which is very low level. That means it will be much easier to put some 3D models, cameras, materials and such with Qt3D, things you'd normally not do in OpenGL directly, but with an API built on top of OpenGL.
Related
I'm developing applications to display very large lidar/sonar datasets (millions of points). QML/Qt seems an attractive platform, since in theory one can quickly define the UI with QML, and implement the "back-end" with high-performance C++. The QtDataVisualization package also seems very useful, especially the Surface3D and Surface3DSeries components for my application. But the provided examples either demonstrate a pure QML approach - which is impractical for my application, with millions of points - or a pure C++ ("widget") approach - which loses the benefit of quickly designing the UI with QML and is locked to a desktop computing platform.
Can someone point to a working example showing how to set QML Surface3DSeries data from C++? This seems theoretically possible from the documentation, but I have been unable to do it, and none of the provided examples demonstrate it. Is this even possible, or is Qml/Qt "broken" in this regard?
Thanks,
Tom
It is possible, but not officially supported and not documented.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Since Qt can handle in normal way OpenGL, it is cross-platform, can handle mouse, keyboard, gamepad etc. What are the disadvantages of using Qt with OpenGL instead using OpenGL with extensions?
What are the disadvantages of using Qt with OpenGL instead using OpenGL with extensions?
Your question is malformed. Nothing stops you from using Qt with OpenGL and with OpenGL extensions.
You can use Qt to manage the OpenGL window, while using direct OpenGL commands with extension to render. You are not required to use Qt's OpenGL interface to render in an OpenGL window.
Qt does not provide "additional opengl functionality." It cannot provide "additional opengl functionality." It isn't part of OpenGL, so it can't make OpenGL features magically appear.
There are no OpenGL extensions for mouse, keyboard, gamepad, or any of the other things Qt handles. Qt's windowing functionality and OpenGL extensions are two completely different things. And they are completely orthogonal; nothing stops you from using Qt+OpenGL and OpenGL extensions at the same time.
Well, unless you stop yourself. See, Qt has this OpenGL abstraction layer. This is a set of wrapper classes around OpenGL: QtOpenGLShaderProgram, QtOpenGLVertexArrayObject, and the like. If you use that, you don't directly make OpenGL calls; you make Qt calls that make OpenGL calls for you.
If your question is whether to use Qt+OpenGL directly vs. using Qt's OpenGL abstraction layer, that's a different matter.
The first problem is that Qt's abstraction layer is bound to OpenGL ES 2.0. While it occasionally offers features that ES 2.0 can't do, it is primarily intended as a class-ified implementation of ES 2.0. So by using ES 2.0, you're effectively giving up using lots of desktop OpenGL features.
Not "extensions"; core features.
For example, you cannot use integers for vertex attributes with Qt's abstraction. The QtOpenGLShaderProgram class doesn't allow it. All of its setAttributeBuffer calls assume that you're calling glVertexAttribPointer. It has no mechanism for calling glVertexAttribIPointer. And that has been core desktop OpenGL for nearly a decade.
Note that this is just one feature. Other things Qt doesn't have wrapper class support that are part of core desktop OpenGL (this is not a comprehensive list):
Separate programs
Sampler objects
Separate attribute formats
These are not bleeding-edge hardware features; most of them have been around for half a decade.
QtOpenGLFunctions is similarly limited to OpenGL ES versions. That leaves plenty of non-extension desktop GL stuff on the table that cannot be used through their abstraction.
Also, because Qt's abstraction is around ES 2.0, it doesn't care about core OpenGL contexts. For example, it still has non-buffered vertex attributes (setAttributeArray). That's not legal in core OpenGL, and again hasn't been legal for nearly a decade.
So if you want to actually use core desktop OpenGL functionality, the Qt abstraction layer is out.
Then, there are places where Qt's abstraction just doesn't match how OpenGL works.
For example (and this is a personal pet-peeve of mine), QtOpenGLBufferObject is typed. That is, the binding type is part of the object. This is not how buffer objects work!
OpenGL buffer objects aren't typed. It is perfectly legal to perform an asynchronous glReadPixels into a buffer, then bind the same buffer for use as vertex data. That's not possible with Qt's class abstraction. And it's not like this is something specific to desktop GL; OpenGL ES works the same way.
Similarly, for reasons best known to themselves, they put the vertex attribute specification functions (the equivalent to glVertexAttribPointer) in QtOpenGLShaderProgram. Why are they there? While vertex attributes do have an indirect connection to a program, they're not a direct part of the conceptual program interface. OpenGL doesn't work like that.
So those are the biggest problems with Qt's abstraction layer. If you can live within those restrictions, feel free to use it. For people making desktop OpenGL applications, they may be too restrictive.
You (OP) wrote in a comment to a different answer:
Extensions provide functionality that the core of OpenGL doesn't provide when Qt itself won't be created for providing additional opengl functionality. It was like a addon for users.
I think you completely misunderstood what OpenGL extensions are and how they work. OpenGL extensions allow to add new features to OpenGL (which might actually be included into a later core version) and/or to expose vendor specific functionality like access to special GPU functions present only for a very specific narrow range of GPUs.
Qt on the other hand offers a framework for applications that deals with operating system specifics in a portable way. Qt and OpenGL are completely orthogonal to each other and nothing, that OpenGL extensions do in any way resembles what Qt does. Qt has a OpenGL integration module, that – among other things – will also load OpenGL extensions if you ask it to; but that doesn't make it a "Qt" thing.
I think you are missing the point. OpenGL (including its extensions that provide some perks that the plain OpenGL does not) is "just" a graphics library intended for rendering 2D and 3D. Qt on the other hand is much more. OpenGL in itself doesn't provide anything but rendering. You can't even create a window (as what you are used to in Windows/Linux) with it. In order to add any sort of handling of the user's input you need an extra layer which Qt (and many other similar frameworks) provides - integration into the window manager of the OS, handling of mouse and keyboard events etc. Qt does also support the OpenGL extensions so you don't have to throw these away if you want to use them.
Whether you need Qt for your OpenGL (with or without the extensions your system supports) tasks or not is something you need to decide for yourself. Qt does offer many nice features that will help you make your OpenGL interaction great however it is a huge overhead and depending on your target system you may have to use a smaller framework with a smaller memory (incl. persistent storage for all the library files) footprint and CPU usage. Other popular choices are GLFW, freeglut and SDL/SDL2 all of which provide at least the basics (window creation and mouse/keyboard handling) to get your application up and running.
I want to use Qt 5.4 to create a window and render with normal OpenGL functions some stuff in that window. In the last few days, I read a lot about the Qt classes and how to initialize OpenGL and so on. I think, the main classes I have to deal with are QOpenGLWindow or QOpenGLWidget, but there are the QSurface and some other classes too. Now I am very unsure about what doing next and which class I should use to use the plain OpenGL functions, later. Can someone explain more clearly to me what I have to do to set up a Qt GUI in which I can use plain OpenGL?
Some other questions from me are:
At which point does Qt create a plain OpenGL context? Do I have to use the QOpenGLContext?
What is exactly the difference between a QSurface and a QOpenGLWindow? In the QOpenGLWindow example both classes are used.
Is it possible to use glew besides this qt stuff? Here are some question on, which deal with setting up glew with qt, but I think that I did not get the real point of why glew is needed.
Edit: I discussed this question with a colleague and our only conclusion was to use Offscreen-Rendering. Does anyone know another solution?
At which point does Qt create a plain OpenGL context? Do I have to use the QOpenGLContext?
Either where it's documented (for instance, creating a QOpenGLWidget or a QOpenGLWindow will automatically create a context), or you can create a context manually at any time by creating a QOpenGLContext object.
What is exactly the difference between a QSurface and a QOpenGLWindow? In the QOpenGLWindow example both classes are used.
A QSurface is a base class representing a "drawable surface" (onscreen or offscreen). QWindow is its onscreen implementation (representing a top level window), so it inherits from QSurface. You can draw over a QWindow by using OpenGL or by using a CPU-based rasterizer.
Finally, QOpenGLWindow is a QWindow subclass which offers some extra functionality and convenience, by automatically creating and managing an OpenGL context (via QOpenGLContext), having an optional partial-update strategy (through the usage of a FBO), etc.
Is it possible to use glew besides this qt stuff? Here are some question on, which deal with setting up glew with qt, but I think that I did not get the real point of why glew is needed.
Qt is not in your way. And it doesn't change your usage of OpenGL in any way. Just use Qt to create a window and a context (in a totally cross platform way), then you're free to use GLEW (to resolve OpenGL function pointers, extensions, etc.) or any 3rd party OpenGL abstraction.
I skimmed through new features of Qt5 and Qt Quick and don't really understand how it differs from the Graphics View Framework (QGraphicsScene) feature wise. It uses QML but beside that:
Can Qt Quick do something that QGraphicsScene can't? For example particle effects.
Is Qt Quick faster than QGraphicsScene? "Faster" meaning more FPS while displaying 1000 moving elements?
I am making a tower defense game and have been using QGraphicsScene and now I wonder whether I should switch to Qt Quick.
Qt5 and Qt Quick 2 should give a nice performance boost, thanks to "scene graph", which is the underlying engine and basically written from scratch for Qt Quick of Qt5, to take full advantage of OpenGL, and have high frame rate as a design goal from the start.
In addition to performance, I think it count's as a big feature, that you can describe the GUI, transitions, animations and all that, in a much nicer way with QML. There's some learning curve, writing declarative GUI code is quite different from writing more direct C++ code to do similar things, but it's totally worth it.
In Qt4, I don't think QML is going to give any peformance advantage, as I think (did not verify now) there it is written on top QGraphicsView stuff.
So, to summarize: Go for Qt5 and Qt Quick2, and Learn QML for desiging the GUI. Have game logic done in C++ for performance (tower defence games can have quite a bit of stuff happening at the extreme case).
Edit: Blog (old so may be slightly out of date in details) about why then scene graph implementation was created:
http://blog.qt.io/blog/2011/05/31/qml-scene-graph-in-master/
I am required to do some 3-D application and planning to chose some library for the same. I have previous experience with Qt-qml.
I read about OpenGl and found that it must be used basically when you one has very low level drawing requirements.
I also found that there is something called QtOpenGl.
Q1. Is QtOpenGl any less powerfull that OpenGl because it just just provide a wrapper over some OpenGl functionality? or it as good as using OpenGl with an advantage of working at higher level of abstraction ?
Q2. I also found there is something called Qt-3D and Qt-Quick3D. I ran some sample examples and found it easy to use because of my previous experience with qml.
Can someone share experience how powerful it is compared to OpenGl itself?
My basic question is how low the drawing requirements should be that I should use OpenGl rather than some higher abstraction like QtOpenGl ?
Q1: The Qt OpenGL module is not exactly a wrapper aroung OpenGL. It is a wrapper around GLX, WGL, or AGL. You can anyway render with QPainter using the Qt OpenGL engine. Look to the documentation to see if it is sufficiently low for you. Only 2D anyway.
Q2: Qt3D will be part of Qt5 as far as I know. It depends on what you want to do. If you want to implement 3D games it is probably quite risky. Only you know if it is sufficient for your needs.