Is Qt3D a part of Qt5? - qt

I have installed Qt5 libraries in windows but there is no document about Qt3D in Qt assistant.
Is Qt3D a part of Qt5 or it has been removed from release version 5?

Yes. Qt 3D became a standard Qt library in the Qt 5.7 release.
With Qt 5.7, we are bringing in the Qt 3D module. This module has been
available as a Technology Preview for two releases now, and I’m happy
to announce that it has now reached the state where it is becoming a
fully supported member of the Qt family!
This addition was a long time coming. Roughly 4.5 years ago, they announced they were dropping it from the Qt 5.0 release. Since then, it's undergone significant rework. Now, seven minor versions later, it's finally made it back in.

The other answer & comments were correct at the time, but the situation has now changed.
As of Qt5.5, Qt3D is now included as a "technology preview" (I interpret this phrase as an indication that it's not deployment-ready, so there could be some bugs and the API could change).
It's very important to note that the Qt3D that was available for previous versions of Qt has been Qt3D 1.0, while the version included with Qt5.5 is v2.0, which has been developed by a different software team and has a very different API.
More info from the new developers available here.
Note also that Qt3D v1.0 was never actually included 'properly' with Qt in any version, though was (apparently) reasonably easy to build along with Qt if checked out from git from v5.0 through 5.4.

Related

Current development support for CUDA for PCL

I am currently looking at using the CUDA supported codebase within PCL 1.9.1 , in an attempt to improve the performance of a 3D SLAM algorithm which I am testing, via CUDA.
I am facing issues compiling and noticed that the header files for the pcl_cuda namespace was not installed via "make install". Further search brought me to this issue opened two years back where the development of the CUDA implementations have been dropped (https://github.com/PointCloudLibrary/pcl/issues/2021)
Are anyone aware on the current status on the CUDA support for PCL?
Thanks
CUDA support in PCL was and is highly experimental and is currently under maintenance mode only i.e., no new features are expected to be added in the near future. As mentioned in the issue you linked, the original developers are no longer active in the project.
That being said, you can still compile and install both cuda and gpu modules. So the fact that they are not being installed is a whole different topic. Did you enable
cmake .. -DBUILD_CUDA=ON
when invoking cmake the first time? These modules are not enabled by default, so you need to compile pcl from source to enable them.

Differences in OpenGL on Qt 5.2 and on 5.10

I’m working now on some project built on Qt 5.2.1. The project makes some basic rendering (using QPixmap, GraphicsScene, etc). The goal is to switch this mechanism to OpenGL as quickly as possible. In addition we plan to move the whole project to Qt 5.10.
Is there some benefit first moving to Qt 5.10 and only then switch to OpenGL over first switching to OpenGL and afterwards move to Qt 5.10?
Is there possibility of some unexpected difficulties if we first switch to OpenGL (on Qt 5.2.1) and only then upgrading to Qt 5.10 (some features got deprecated or some new nice-to-use features appear)?
My experience with OpenGL on Qt is it being full of both old and new bugs, poor integration capabilities, poor platform support (Intel=NOPE) and no error handling of Qt-internals (e.g. context creation). At least of you use the built-in OpenGL-widgets.
That said there is much development going on right now of the Qt-OpenGL support, judging from which Qt-version certain OpenGL related features I have found in he manual. If you must use Qt-OpenGL, I would assume you get most features and few(er) bugs jumping onto latest and greatest.

Render Qml using Vulkan

I have a Qt application that draws using Open GL. At some point I'm using a QQuickWindow associated to a QQuickRenderControl to draw a QML scene into a texture to later compose it in the final image.
Now, I'm considering porting OpenGL to Vulkan and I'm not sure if it is possible to do the same with this QML layer.
Reading Qt docs I found that
QQuickWindow uses a scene graph on top of OpenGL to render.
Do you think it is possible to port it to Vulkan? Perhaps overriding QQuickWindow and QQuickRenderControl? I'm not a Qt expert so perhaps someone can give me a better insight of the problem.
As of June 2019 and Qt 5.13, Qt Quick 2 supports the following backends:
OpenGL 2.0
OpenGL ES 2.0
Direct3D 12 (support is still experimental)
OpenVG
Software rendering
However, only OpenGL and OpenGL ES are fully functional. For instance some effects (like particles) do not work with the other banckends.
For more information about how to select a backend and what are the limitations of each backend I suggest to read the documentation: https://doc.qt.io/qt-5/qtquick-visualcanvas-adaptations.html
Regarding Vulkan specifically, Qt has added support to it since Qt 5.10.
However, the support is still very limited and does not cover Qt Quick.
Change will come in the future; quoting an email from Qt development mailing list:
A very early preview of Qt Quick for Vulkan, Metal, and D3D11 may come already in Qt 5.14, then evolve in 5.15 and beyond, with 6.0 as its final destination.
So rendering Qt Quick with Vulkan should be possible when Qt 6 will be out. The planned release date for Qt 6 is currently November 2020. In the mean time technical previews might be available starting with Qt 5.14.
I would not be too optimistic for anything before Qt 6 as (1) it will just be technical previews and (2) as far as I know, current official Qt binaries are not linked with Vulkan at all and you need to build Qt from source if you want to use Vulkan.

Qt Mobility or Qt Location available for desktop use?

I have been trying to implement a mapviewer application in Qt as a desktop applicaation to work with multi-touch. I'd been having some trouble when I came across mention of Qt Mobility. Qt Mobility seems to be an old module that was used on mobile devices but doesn't appear to be supported by Nokia anymore. Although there is a active repository.
From what I can gather from various more recent forum posts such as this is if we want to use Qt Mobility's Location features we need to wait for it to be released in newer versions of Qt.
If the Qt Mobility api is still available through the repository is it possible to use this for desktop applications or is it strictly for mobile devices? I am interested in making use of the Qt Location classes to help create a map viewer client.
The QtMobility API while deprecated is still being updated and is still available and according to a thread on the Qt Developers it should work with Qt 4.8 (it was only officially supported up until Qt 4.7). According to the documentation it can be used for desktop applications, but they are mostly tier 2 platforms.
While Qt Location won't be ready until Qt 5.2 (expected at the end of November), I wouldn't expect it to drop support for platforms that are already supported in QtMobility.

Symbian C++ and QT libs tohether under Series 3 SDK (Nokia N8)? is it possible?

before posting this quesiton i did extensive research on Forum nokia, Stackoverflow and developer.symbian.org but still unable to find solution to the problem
I am building an application that uses Symbian C++ (to get advanced network data which QT cant provide) and QT libs (for user interface and xml saving and so many other things). Now here is the problem, i cannot build and run Symbian Series 3 sdk (0.9 and o.8) with QT Designer nor Carbide C++. if i use the same approach with Series 60 5th edition, it works like a charm but combining both Symbian C++ and QT (tried 4.6 and 4.7) targeting N8, i am unable to do so.
1:Can someone advise about how to setup the environment in which we can blend Symbian and QT together.
2:Can someone help me in writing down the instuctions from point 1 (i,e pre requisites) and then running a sample code.
This thing is going on my nerves, i will really appreciate your help Stackoverflow!!
Is there any reason you need to build on the Symbian^3 SDK? A build for S60 5th will work on the N8, so unless you need APIs specific to Symbian^3, why not stick with the S60 5th SDK?
(I've had similar problems with the S^3 SDK, but now work with 5th without a hitch)

Resources