Qt 5.12 D3D compiler module not found - c++

I've installed Qt 5.12 , When i want to compile my project show this
errors:
Errors :
QOpenGLShaderProgram::uniformLocation(qt_Matrix): shader program is not linked
ensureInitialized(141): D3D compiler module not found.
QOpenGLShader::link: D3D compiler module not found.
shader compilation failed:
"D3D compiler module not found.\n"

Welcome to SO!
First of all, let's clarify what the error means.
Qt uses ANGLE on Windows, which is a layer that allows to run OpenGL software on systems where OpenGL is not available, by traslanting the OpenGL calls into DirectX calls. Qt decides whether to go with pure OpenGL or ANGLE depending on the configuration of the machine (video card model, video drivers version, etc).
More details on that are available at https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL.
Even if you are not writing any OpenGL code yourself, the qml runtime surely has a lot of OpenGL calls that again, may go through ANGLE.
That is why the confusing error message (looking for the D3D shader compiler while dealing with OpenGL code!).
Now, the Qt project bugtracker reports the same issue you have https://bugreports.qt.io/browse/QTBUG-71510, although at the time of writing no solution has been provided. I would suggest to have a look at the bugtracker now and then to monitor the progress on this issue.
A couple of workarounds you may try:
Copy the d3dcompiler_xx.dll in the same directory where your exe is;
Force Qt to use OpenGL instead of DirectX, by setting the environment variable QT_OPENGL to desktop (more details on that are at http://doc.qt.io/qt-5/windows-requirements.html)

According to bugreports.qt this issue is now fixed from version QT 5.12.1.
https://bugreports.qt.io/browse/QTBUG-71510

I have the same issue on my older Del laptop. Placing d3dcompiler_43.dll in the exe folder does solve the issue. I found using one of the following commands also works, which I assume avoids ANGLE all together.
//To use pure OpenGL :
QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
//Or use software emulated OpenGL :
QCoreApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);
I just include the first pure OpenGL setting in the "int main(int argc, char *argv[])" bracket in main.cpp

Related

Qt 5.7 black screen on windows

I have just upgraded my project to use Qt 5.7, on Mac I am able to load the html pages using Qt Webengine but on Window 7, the pages are not displayed, instead a black screen is shown.
I have also compiled simple browser example and it too only shows a black screen.
I am using the visual studio 2013 build of Qt 5.7
Does anyone know why it is not displaying the pages.
Does Qt 5.7 need any third party libraries for it render correctly on Windows.
We had a similar problem, whenever we started an application with a QWebEngineView it would only show a black screen or even crash on another machine. The problems occured due to wrong versions of api-ms-*.dlls and d3dcompiler_47.dll we had packaged with our app.
We found the correct versions on our developer machine with installed Windows SDK under "C:\Program Files (x86)\Windows Kits\10\Redist".
On a side note: We found that deployement of QWebEngine under windows is quite a hassle.. you also need to include "qtwebengine_locales" from qtbase\translations and "resources" from qtbase as well as "QtWebEngineProcess.exe" from qtbase\bin.
A thing that helped tracking down the problem, was putting "CONFIG += console" in the pro-file. That way the console output with relevant error information is shown on deployement targets.
With help of this comment from peppe
One can use temporary workaround with graphic drivers not supporting DirectX11 but supporting DirectX9
As said here
https://doc.qt.io/qt-5/windows-requirements.html#dynamically-loading-graphics-drivers
Graphics Drivers
For Qt Quick 2 to work, a graphics driver that provides OpenGL 2.1 or higher is required. The default driver from Windows is OpenGL 1.1. Qt includes a version of the ANGLE project which is included from the Windows Qt installers. ANGLE implements the OpenGL ES 2.0 API on top of DirectX 11 or DirectX 9. ANGLE requires that the DirectX SDK is installed when building Qt.
ANGLE chooses the render backend depending on availability. DirectX 11 is usually preferable. However, some graphics cards may not fully support it. For these cases, the environment variable QT_ANGLE_PLATFORM (introduced in Qt 5.4) can be used to control the render backend. Possible values are d3d11, d3d9 and warp.
So this may help
set QT_ANGLE_PLATFORM=d3d9
Or use mesa with
https://www.mesa3d.org/llvmpipe.html
Qt::AA_UseSoftwareOpenGL is special in the sense that it will try to load an OpenGL implementation with a non-standard name. The default name is opengl32sw.dll. This allows shipping a software-only OpenGL implementation, for example a build of Mesa with llvmpipe, under this name. If necessary, the filename can be overridden by setting the QT_OPENGL_DLL environment variable.
Edit 1:
One can use fallback method for one-time login to Dropbox Windows client ( made with QT framework ) for example
Dynamically Loading Graphics Drivers
In addition to the build time configuration, Qt supports choosing and loading the OpenGL implementation at runtime. To use this mode, pass -opengl dynamic to the configure script.
Note: As of Qt 5.5 this is the configuration used by the official, pre-built binary packages of Qt. It is strongly recommended to use it also in custom builds, especially for Qt binaries that are deployed alongside applications.
...
This configuration is the most flexible because no dependencies or assumptions are hardcoded about the OpenGL implementation during build time. It allows robust application deployment. When a given environment fails to provide a proper OpenGL 2.0 implementation, it will fall back automatically to ANGLE. This fallback will be completely transparent to the application, and will allow Qt Quick or other OpenGL code to function by translating to Direct3D. Such a fallback could, for example, take place on a Windows 7 PC with no additional graphics drivers installed. On other machines, where there is sufficient OpenGL support, the normal desktop OpenGL drivers will be used. Additionally, pure software-based OpenGL implementations may be available as additional fallbacks in the future, allowing running Qt Quick applications without a GPU.
When configured with -opengl dynamic, neither Qt nor the applications built using qmake will link to the opengl32 (standard desktop OpenGL) or QtANGLE libraries. Instead, the appropriate library is chosen at runtime. By default, Qt will determine whether the system's opengl32.dll provides OpenGL 2 functions. If these are present, opengl32.dll is used, otherwise the ANGLE libraries (libEGL.dll and libGLESv2.dll) will be used. In case the ANGLE libraries are missing or initialization fails for some reason, an additional fallback is attempted by trying to load opengl32sw.dll. See below for details.
Such a fallback could, for example, take place on a Windows 7 PC with
no additional graphics drivers installed.
To emulate this conditions one can use RDP session with mandatory 8 bpp to Windows machine

Force Unreal Engine to use opengl on windows executable

I'm attempting to make a video game in Unreal Engine 4.9. I'm building it for Windows, but I'd like to have it use opengl instead of directx in the executable. However, I've found no options that let you do this. Unreal Engine uses OpenGL when it creates executables for Linux and Mac, but there seems to be no way to use OpenGL with Windows.
Am I missing something? Is there some way to force Unreal Engine to use OpenGL in Windows executables?
EDIT: The reason I want to use OpenGL is because I want this game to run without having to install anything on the end user's computer (DirectX has to be installed to work)
Microsoft doesn't really support OpenGL, they typically go out of their way to make it very difficult to use OpenGL on Windows and strongly encourage people to use DirectX instead.
The simplest way to get a working OpenGL context in windows is sometimes to use ANGLE which is a compatibility layer which translates OpenGL calls to DirectX calls. This is what Chrome and Firefox use to support WebGL on windows. I doubt that Unreal Engine is integrated with this, so you might have a hard time.
Edit:
EDIT: The reason I want to use OpenGL is because I want this game to run without having to install anything on the end user's computer (DirectX has to be installed to work)
One thing you could do is cross-compile the Mesa3D drivers, as described here: https://wiki.qt.io/Cross_compiling_Mesa_for_Windows
But then you won't get hardware acceleration.

Setting up a dev environment for OpenGL 4.2 on Linux (trouble sourcing gl.h)

I'm using GLFW and Netbeans to develop in C++. I'm able to render with immediate mode functions no problem. However, when I try to use core profile functions I get errors like this:
error: ‘glCreateShader’ was not declared in this scope
I get one of these errors for each core profile function I try. I did some research and found that GLFW doesn't provide any gl headers and just #includes the headers found on my system (at /usr/include/GL/).
Presumably this means that the gl.h and related files found here only contain the old style OpenGL API. I can't make sense of the hex code, but the gl.h file #defines GL_VERSION as 0x1F02.
If I perform this command in terminal: glxinfo | grep -i opengl it assures me that my OpenGL version string is "4.2.0 NVIDIA 304.88" -- Although I think that's reflected in the driver, unrelated to the gl.h file. Running this line in C++ code in my application yields the same string: printf("%s\n", glGetString(GL_VERSION)); For the same reason, no doubt.
Where can I source the appropriate OpenGL header files for OpenGL 3+ development on Ubuntu 13.04 x64?
I have installed these packages as suggested by most tutorials (to no avail): xorg-dev libglu1-mesa-dev
glCreateShader (...) is an OpenGL 2.0 function.
Short of OS X, I cannot think of any platforms that ship with OpenGL 2.0 without requiring runtime extension. On Microsoft Windows, you are guaranteed the full feature set of OpenGL 1.1 and anything beyond that requires calls to wglGetProcAddress (...) to load the function entry-points for the rest of the OpenGL API. The situation is the same on Linux, though it is more difficult to define what the "minimum" feature set is. In any case, to use glCreateShader (...) you are going to have to call glXGetProcAddress (...) in order to get the entry-point from the driver.
Libraries like GLEW will make your life easier by loading the entry-point for every function for each extension and core version of OpenGL your driver supports, on Ubuntu there should even be a package you can install that contains GLEW. Nevertheless, see the official project site for more details on actually using GLEW.

glBindFrameBuffer not working with SDL

Recently I migrated over to SDL from Glut to get more control over the main loop. I've had shadow maps in my application for a while now using calls like bind framebuffer and gen framebuffer. After migrating over to SDL, I get an error for undeclared Identifier for only these calls. I downloaded the SDL off the website today and imported SDL2/SDL.h and SDL2/SDL_opengl.h. When I open the declaration for one of these "missing calls" it gives it to me, in OpenGl/glext.h. I noticed that the SDL OpenGL imports the OpenGL/gl.h which imports glext.h. Is there a file I'm importing wrong? All the other OpenGl calls work in the rest of my program, so I have no idea what the problem is. Any help would be appreciated. Thanks.
EDIT: I was able to delve deeper into glut and was able to come up with this to get it to work:
#pragma comment (lib, "glu32.lib")
#include <OpenGL/glu.h>
Is this ok?
Everything that goes a certain version of OpenGL (Windows: 1.1, Linux 1.2) must be dynamically loaded through the so called extension mechanism. The OpenGL headers and including them are not enough. The typical recommendation is to use a loading library like GLEW or glload to do the tedious work.
It depends on the platform you're using, but glBindFramebuffer<ARB|EXT> (...) is an extension on many. It was integrated into the core of OpenGL 3.0, so if your platform does not guarantee support for OpenGL 3.0 you are probably going to have to use an extension loading library (e.g. GLEW). If your driver provides OpenGL 3.0, you may still have to use the run-time extension mechanism to load the core function glBindFramebuffer (...).
The fact that "glext.h" contains it does not say a whole lot. That header is where prototypes, enumerants / constants and typedefs for parts of OpenGL that are extended at run-time are defined. You still have to setup a function pointer in your software and ask the driver for the address before you can call them - this is what extension loading libraries do in a nutshell.
EDIT1:
No, that is not okay. glBindFramebuffer (...) is part of OpenGL 3.0. Microsoft Windows implements OpenGL 1.1, and GLU should not change this at all. If forcing MSVC to link against GLU fixes unresolved linker errors to an OpenGL 3.0 function something is seriously wrong.
EDIT2:
Judging by the discussion in the comments, you are not only moving from SDL to GLUT, but also from OS X to Win32. On Win32 you have to use wglGetProcAddress (...) or an extension loading library to use glBindFramebuffer (...). You have been spoiled by Mac OS X, which is more of the exception than the rule when it comes to API completeness out-of-the-box.

Setup VisualC++ to use OpenGL 4.1?

I'm trying to setup VC++ to compile code with OpenGL 4.1 functionality. I downloaded the 3 header files from from opengl.org; put them in the correct paths and include them - but keep getting errors like this:
error C3861: 'wglSwapIntervalEXT': identifier not found
I have the latest video drivers. OpenGL says the problem is MS includes only version 1.1 with their compiler when though the vendor/driver supports 4.1.
One of the big pains of using OpenGL on Windows is that the Windows SDK only ships with OpenGL 1.1. There's probably a really good technical (and non-political) reason for this, but the fact remains, if you want to do anything with OpenGL on Windows, you're on your own.
What you need then, is something to bring the Windows SDK up to current standards (OpenGL 4.1 as I write this.) When I was originally trying to solve this problem (around the time of OpenGL 3.0), I came across GLee http://elf-stone.com/glee.php which is a cool library which makes the full OpenGL spec available easily. I didn't like their license, so I decided to write my own extension loader.
I don't think anyone should ever have to do this again, so I've made mine public domain, do with it as you will. I'd like to hear if you use it in something, but that's not a requirement.
http://www.onemanmmo.com/index.php?cmd=newsitem&comment=news.1.28.0