Recently I tried to compile my Qt static libraries with both -no-angle and -no-opengl. I first thought that it would not compile. But unexpectedly, Qt (5.7) compiled just fine. I could also compile my application (using many QtWidgets).
To my surprise I could not see any difference with my Angle based Qt app. No lags, no glitches, my QtCharts were displaying as always.
I could not find any definitive answer on the web. but I have two guesses:
I was not really using any hardware acceleration after all.
There is a mysterious fallback mechanism.
What is going on here ?
What happens? In your case nothing. Qt widgets don't use OpenGL behind your back. You have to explicitly force its use in a given widget stack by using the QOpenGlWidget as the top level widget. By default, you're using the CPU-based raster rendering backend - as you noted, it performs quite well.
Compiling Qt without angle and OpenGL support is a good way to make your application smaller if you don't use OpenGL :)
Related
My situation
I want to build a cross platform application, with a gui, that displays a 3d view of some simple cubes, that the user can interact with. Qt seemed like a good tool for the job and I think I have the gui part sufficiently down for the most part. For the 3d part OpenGl or the qt/3d implementation seemed like the right tool, but it does not work. When I try to run the examples from Qt, that use a 3d view, they are unstable, they crash, show a black window and on the offchance, that I find one, that does work there is aggressive flickering and my entire system becomes unresponsive when I only try to resize it. I don't know what is wrong, I don't think I can do a better job, than the official examples and I don't think, that trying to debug the examples is the way to go. (If someone has an idea how to fix this tell me, but I don't even have an error message)
My question:
Is there a simple framework, that would allow me to display simple 3d shapes and include that in a Qt application. I don't need shadows, or reflections or transparency or anything more fancy, than ambient light. Just some solid coloured boxes I can rotate and click on. I think it would even be fine, if it ran on CPU rather than GPU. It would be nice, if I could keep using C++, but if it only exists in another language, what gives. I don't really want to build a framework from scratch. How could I include such a foreign framework in Qt?
I am using ubuntu 20.04 with intel graphics, but as I said, I want the resulting application to work on as many platforms as possible.
I am working on an application that uses Qt3D with then OpenGL renderer. Deploying the app to a handful of users, I found some severe issues with Intel Integrated Graphics, ranging from crash to rendering bugs like flickering. This unfortunately doesn't comes from Qt or OpenGL itself but more from how Intel implements their OpenGL drivers.
The crash bug seems to impact older intel chips, very few references of that apart some random minecraft FAQ on reddit: https://www.reddit.com/r/Minecraft/comments/48ktct/19_faqs/
But what is claimed there seem to align with what my users are experiencing.
The flickering bug has only been reported recently and I unfortunately don't have the right hardware to replicate it yet...
I know it's like random, not sourced information but I thought that personnal experience might help.
I used osgQt many years ago. It looks active still. I know the military likes them.
https://github.com/openscenegraph/osgQt
I am new to C++, OpenGL, and QT. In fact, I’ve never even touched QT. The reason for this is the following; I’ve made games in a few other languages in the past (mostly C# with Unity). Now I want to get into games with c++. However, I want to use pure C++, not even Unreal (maybe one day ), for games. To do this I know that for graphics I should almost definitely be using OpenGL (which I’m currently learning). I also am going to need to make GUIs. When I looked up what to use, it looked like the best option would probably be QT. This means I need QT to work with OpenGL. So again I looked it up. I found QT OpenGL on this post: How to work with OpenGL and QT?. When I looked up Qt OpenGL (https://doc.qt.io/qt-5/qtopengl-index.html) it said:
Warning: This module should not be used anymore for new code. Please use the corresponding OpenGL classes in Qt GUI.
So what is QT GUI?
And, how easy it to use QT with OpenGL?
As the new features of Qt 5.4 point out, the Qt Opengl module has been declared deprecated.
Deprecated features
Qt OpenGL:
The Qt OpenGL module (which contain classes that start with "QGL") is now deprecated in favor of the Qt GUI module (which contain
classes that start with "QOpenGL"). QGLWidget can now be replaced by
QOpenGLWidget.
That does not imply that:
the module has been removed but at any time Qt could remove it without notice.
You cannot use opengl in Qt, only you should not use the QGLX classes that belong to the Qt OpenGL package but you must use the QOpenGLX classes of the Qt Gui module, for example replace QGLWidget with QOpenGLWidget.
You can also find several examples here.
Qt is probably not the right tool for you. For one you want to use GLFW, which would cross into the turf of Qt and vice versa. A much better choice for game UI stuff is Dear ImGUI which is far better suited for the needs of game development.
Anyone who has experimented with Qt QML and 3D OpenGL, I am interested in 2 frameworks I've read about, but it is not clear to me if in fact they are the same framework. The most interesting of the two is outlined in this Qt Developer Days 2013 video presentation by Krzysztof Krzewniak:
http://www.youtube.com/watch?v=29wCpA0DBZI
While very interesting, unfortunately I cannot find anywhere else online some source code for this, or even the name of the framework discussed.
There is QtQuick3d:
http://doc.qt.digia.com/qt-quick3d-snapshot/
However, I cannot tell if in fact this is describing the same framework from Dev Days or if they are separate (and apparently somewhat similar) frameworks? My initial look at the API in comparison to the video suggests they are different, which seems rather redundant to have 2 significant projects in the Qt community attempting to do the same thing.
Can anyone with some knowledge in this area of QML provide some pointers here?
Right, so let us start with some history behind...
Qt was initially a 2D framework for rendering computer graphics UI for simple desktop applications.
Qt3D was developed earlier than qml became mature as an extension to the 2D world provided by the QtGui module, or even QtOpenGL.
It was a 3D Qt api for rendering 3D content on the screen. It had different aspects to deal with 3D objects, build them, put them on the screen, compute intersection, and so on.
The idea was to bring easy to create application concept into Qt rather than always going through QtOpenGL or lower-level API for creating games, simulators, cad applications, and so on.
Right, when QML came out and kept maturing, the Qt3D contributors in Brisbane thought that it would be nice to put a QML API on top of the existing Qt3D C++ API for easy use in QML application. That is how we come to QtQuick3D.
When Nokia decided to shut the Brisbane office done, the Qt3D module pretty much became unmaintained and abandoned only getting a few bugfixes from the community every now and then.
There is some work in progress by KDAB to re-architecture and re-design the module, but it is not mature yet, and it can be found in a separate branch.
The video you are referring to is not dealing with the unmaintained Qt3D module. Rather, it tries to build 3D based on the new scene graph introduced in Qt. Since, there is no Qt3D module working nicely with the new SG in Qt 5, people become pragmatic and move on. That is what you see in the video.
Now, as you can see this is not quite a duplication, but... In the future, the new Qt3D architecture might be acting better with the new scene graph. In fact, KDAB has put a lot of effort into bringing the OpenGL support into QtGui up to real world.
That was the foundation for the Qt3D module which will probably be used in the future (hopefully) by 3D applications written based on Qt, but in the meantime... the video shows how to build hardware accelerated 3D UI based on what we have today.
These two 3d libraries are not the same, you are correct.
There is plenty of reference information you've already linked to online regarding Qt3d 1.0 and QtQuick 3d which are similar and related.
The OpenGL work in the video presentation is something much newer. It is directly laid on top of the QSceneGraph and QQuickWindow functionality.
My recommendation is to not use the approach in this video or the Qt3d/QtQuick3d library. Instead, wait for the KDAB to finish Qt3d 2.0 (which may already be out, you should check). Qt3d 2.0 is a full library for QML that will let you do what is demonstrated in this video.
(http://qt-project.org/wiki/Qt3D-wip-newapi-Overview, http://prezi.com/u-ewejoqxqj2/qt3d-20/)
There are quite a lot of outdated info floating around wikis, and finding useful info and a non-obsolete repository was a pain. So here's what I learned a few months back:
The correct and, as far as I know, the only currently valid git repo is this:
git://gitorious.org/qt/qt3d.git
The "There is some work in progress by KDAB...not mature yet...found in a separate branch." paragraph of Laszlo Papp's answer seems to refer to wip/newapi branch, while master branch seems to be maintained in compilable state (meaning, I have been able to compile it the few times I've tried, YMMV). Master branch should be fine for playing around with Qt3D, but looks like API is going to change.
I played with it a few months ago on Windows 8.0, the MinGW toolchain that is installed with SDK, and using native full OpenGL drivers (which I had to fetch from ATI web site for my card, default Windows drivers are not enough). And looks like it has not broken to bit rot, an example still built and I have a moon rotating on this screen.
It has README file, which will tell you how to build it, starting with building Qt5. Here another good link for that, since the qt3d README is not very comprehensive. And if you're on Windows, just skip Webkit and its deps, unless you really need it, because those extra deps can be a bit of hassle.
I'm trying to develop a cross platform (or at least desktop + embedded hardware) application. I would like to use Qt Quick to create a touch friendly GUI. I have been implemented a classical application with a QGLWidget displaying data. It is important that only a part of the window is in OpenGL. Because of this there are problems with EGLFS and LinuxFB. Only X11 (or maybe Wayland) can display the application properly (others generates a couple of errors about missing setParent function and the whole screen is black). Now I'm trying to achieve the same thing in QML. I want to use this OpenGL renderer as part of my QML application and some Qt Quick widgets around it. I found a couple of people asking about the same thing and the answer is always to subclass QDeclarativeItem and call the painter's beginNativePainting() (the others says to export it through QDeclarativeItem, but I cannot figure out how to do this). The problem is that on desktop, Qt 5.11 the native painter is not OpenGL. And in QT5 there is no way to force OpenGL graphics system. So when I try to get the OpenGL context (QGLContext::currentContext()) I always get NULL. Another problem: If I export my widget with qmlRegisterType("Test", 1, 0, "Test"); it becomes only visible when I use QDeclarativeView, but then it doesn't sees Qt Quick. If I use QQuickView it says module "Test" is not installed. How can I implement this properly?
QDeclarativeItem is from Qt Quick 1 and Qt4. With Qt 5 and Qt Quick 2 you should use QQuickItem.
There is at least 1 example of this provided with qt docs, which you can find in Qt Creator in the Welcome tab in the Examples section.
Glut seems rather old, and SDL also as if it's not the youngest anymore - what is being used as (cross-platform) window manager for OpenGL nowadays?
Cross platform UI toolkit
1. wxwidgets
2. fltk
3. qt
4. glut(freeglut)
5. sdl
I have used glui. Sucks real bad(in terms of performance). There huge difference in performance penalty just by including glui(without actually using it) in your apps.
To be honest, i prefer platform specific UI toolkit. Faster. Reliable.
Depends on how you want to use it. Don't think there is a clear winner.
I like to use Qt because I'm familiar with it so it feels easy to me, and because I use it for other UI elements in my mostly windowed openGL apps.
Haven't tried it myself, yet, but want to in my next project. It seems to be very popular.
SFML . It`s the "successor" to SDL written in C++
I am using freeglut, but it is just a bit improved glut.
You can also use QT
I think GLFW is the best choice for small to medium applications/games. This type of libraries should be easy,small and fast with no extra services such as image helper functions and so on. GLFW is going to remove all helper functions to focus on the main goal.
QT is the best for graphics applications but not for games or small applications.