As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Since there are two ways to use OpenGL with Qt 5 (QOpenGL/QtOpenGL wrapper and regular OpenGL API), I wonder what are the limitations of each one. Could someone tell if there are limitations with QOpenGL wrapper that I should be aware of?
The reason I am asking this is because I don't want to start using QOpenGL wrapper and find out that I can't use the full capability of OpenGL API. Does anyone have experience with both and could provide some hints in terms of capability, performance and ease of use?
I don't want to start using QOpenGL wrapper and find out that I can't use the full capability of OpenGL API
Well, Qt 5.0's OpenGL wrappers are built on top of the OpenGL ES (Embedded Systems) 2.0 specification which is essentially a watered down version of the desktop OpenGL 3.0 specification. Qt chose this specification to facilitate portability as it is widely supported by mobile platforms in addition being supported on nearly all modern PCs. If you choose to use the Qt wrappers you have to work around the shortcomings of the OpenGL ES 2.0 specification which, for the most part, fall into the following categories:
No fixed-function pipeline capabilities. (no transformation stack, glBegin,glEnd,glLightf,etc..)
No support for advanced OpenGL 3+ capabilities or support only in extensions. (texture buffer objects, compute shaders, atomic load-store textures, tessellation shaders, uniform buffer objects etc..)
Lack of certain texture formats (integer textures, image textures, etc..)
Small differences in GLSL syntax & semantics. (lack of layout qualifiers, data precision requirements via highp, lowp declarations, etc..)
Lack of some convenience methods. (glBlitFramebuffer,glMultiDrawArrays, glDrawRangeElements, etc..)
For a full description of the OpenGL ES 2.0 specification look here.
However, This lack of features does not mean that the Qt wrappers can not accomplish what you need. Although OpenGL ES 2.0 is missing a lot of helpful functionality, you can still accomplish 99% of what the full desktop OpenGL specification would allow. If you decide to utilize a desktop OpenGL specification via custom wrappers, Qt can still manage the creation & windowing of desktop OpenGL contexts through the use of the QGLFormat class.
Keep in mind that if you decide to use desktop OpenGL wrappers, and utilize these within a Qt application, some classes provided by Qt may interfere with the operation of your custom wrappers. For example, QPainter operations on a QGLWidget may utilize functionality of the OpenGL ES specification and might interfere with the operation of your wrapper objects.
Personally, I prefer to use custom OpenGL wrappers as I greatly prefer the desktop OpenGL specifications as the feature sets are better defined and they provide more options to tackle a problem with. On the other hand, Qt 5 provides some absolutely fantastic architectures for making quick, powerful dynamic user interfaces using OpenGL ES. (Through by QtQuick 2 and QML)
Which API suits your needs best essentially comes down to whether or not you are targeting embedded or mobile platforms (in which case your forced to use OpenGL ES), and whether you are willing to sacrifice additional development time writing and maintaining custom OpenGL 3+ wrappers.
Related
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.
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am into learning some GUI API in C++, so I searched a lot to see which one was best. I ended up with either Qt or WinAPI. I read some people saying that Qt was easier to work with but with WinAPI you could control everything. The argument proceeded and someone said that it was a fair exchange, a small piece of control so it could become easier. Now I want to know, what exactly are you losing when you chose Qt? Is it the interaction with the system? What exactly can you do in WinAPI that you cannot do in Qt?
You are comparing apples and oranges here. Qt is a C++ class library designed to help you implement a GUI and is cross-platform, you can recompile your code to run on different operating systems. The winapi is the low-level C-based api to make operating system calls on Windows. You can create a GUI app using only the winapi, Charles Petzold shows you how, but it is quite a punishing approach to developing such an app. A "Hello world" app using only the winapi is an easy hundred lines of code.
Don't contemplate using only the winapi to implement a GUI, you'll deeply regret it after spending several months learning how to get it right. There are many tools to simplify that job, Qt is just one of them and it isn't limited to just the C++ language. Of course, the fact that Qt is cross-platform does mean that certain Windows' specific features are poorly or not at all directly supported in Qt. You do however have the option to fall back to the winapi if you need it. At the cost of giving up cross-platform support.
The most "heavy weight" things Qt looses are the Shell API, the DWM and the Ribbon UI. There are more, like the compression API.
However, it is fairly easy to write your own Qt style interfaces to those APIs.
Best regards
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm looking for a good 3D Mesh library
Should be able to read popular formats (OFF, OBJ...)
Should support both half-edge structure and a triangle soup
Should be tolerant to faults and illegal meshes.
Basic geometric operations - intersections, normal calculation, etc'
Most importantly - Should not be convoluted with endless template and inheritance hierarchies.
I've tried both CGAL and OpenMesh but both fail miserably in the last point.
Specifically CGAL which is impossible to follow even with the most advanced code analysis tools.
So far I'm seriously considering to pull my own.
My preference is C++ but I'm open to other options.
May I ask why the last point is a requirement?
Libraries written for public consumption are designed to be as generic as possible so that it is usable by the widest possible audience. In C++, this is often best done using templates. It would suck tremendously if found a good library, only to discover it was useless for your purposes because it used floats instead of doubles.
CGAL, for example, appears to have adopted the well-known and well-tested STL paradigm of writing generic and extensible C++ libraries. This does indeed make it difficult to follow with code analysis tools; I doubt they're much good at following STL headers either.
But are you trying to use the library or modify it? Either way, they seem to have some extremely high-quality documentation (e.g. Kernel Manual) that should make it relatively simple to figure out what you need to do, without having to resort to reading their code.
Disclaimer: I know this isn't what you're asking for. But I don't think what you're looking for exists. It is extraordinarily rare to find open source code with documentation as good as what I've seen scanning through CGAL. I would strongly suggest that you take another look at it.
First, some general comments about you requirements:
reading OBJ or OFF files is very easy. You could implement it yourself, on top of a library providing the more geometric features, in a few minutes. On the other hand, the geometric part of such libraries is so much more tricky that you should certainly focus on your requirements which really deal with the geometric algorithms, and try to find something which suits your needs. Then, of course, if there is a tie, start considering this interface issue.
in terms of geometric operations, you ask for intersection. Do you mean primitives intersection ? (for which good and simple algorithms can be found and implemented) or computation of the intersection of two meshes ? or collision detection ? (which are delicate questions, with no simple answer)
if you are more specific, from a higher level point of view, about the kind of tools you want to build, then people will be able to direct you to the right tool. Your requirements are too low-level.
As far as I understand your question, it seems to me that you do not clearly see the point of libraries like CGAL and OpenMesh. Such libraries may not provide all the higher level tools you need, but their aim is to provide you (especially in the CGAL case) all the geometric framework upon which you can build a geometric application. Such geometric frameworks are very delicate to design, especially because of the robustness issue, which is very specific to computational geometry. And without such a framework, building a robust application is an horrendous effort.
If you do not find a library which suits your need, you should seriously consider using a library such as CGAL as the underlying framework for your development. It will prevent the appearance of the robustness related problems, that you will typically only start noticing late in your development process, when changing the underlying framework will be painful. As an aside, CGAL has an extensive documentation, and a very active users' mailing-list.
If you do not know about robustness issues in geometry software, have a look at this page:
robustness issues
I don't know if it can be useful for you. There is also another library, which is called the Mangrove TDS Library, freely available at http://mangrovetds.sourceforge.net It supports any type of shapes (2d, 3d, any dimension), with any domains (manifold, non-manifold, pseudo-manifolds, iqm complexes, simplicial complexes, and so on). It possibly supports non-regular shapes, i.e., formed by pieces of different dimensionalities.
Its main property is that it is extensible, in the sense that any topological data structure is supported. It is a plugin, which can be changed and loaded at run-time.
Its implementation is based on the array-based indexing of entities, encoded in a data structure, supporting iterators. It also supports dynamic properties.
Finally, it supports an implicit representation of entities not directly encoded in a data structure (ghost entities), which improve efficiency of topological queries