Hello developers and designers!
We want to make learning Qt an easier and more rewarding experience, and we’re looking for your honest feedback on how to improve.
We’d be thankful if you could take three minutes to complete a short survey and share your experience in five short questions.
Results from this survey are treated anonymously and will be used to improve both the way you learn Qt and the quality of our our educational material.
So, now is the time to tell us about the good and the bad you’ve encountered on your Qt journey from the moment you landed on our downloads page (https://qt.io/download) until now.
Here is the link for the survey: survey is here
Commenting for this post has ended.
So QtQuick3d now becomes a full 3d engine. That is cool but can you guys tell me what of the multiple 3d engines should we use? We now have a very active QtQuick3d, a not very active Qt3d (at least according to the latest commits), Qt 3d Studio engine. Is this blog post still valid: https://www.qt.io/blog/the-future-of-qt-3d ? To me, it looks like the Qt company wants to establish QtQuick3d as the de facto standard for 3d, but it still looks strange from the outside having multiple 3d engines that have a different feature set, do the same in some regards and are completely different in others.
Thanks!
Qt Quick 3D along with Qt Design Studio does replace Qt 3D Studio in Qt 6. Qt Quick 3D and Qt3D is more of an apples to oranges comparison. Yes they both involve 3D, but Qt Quick 3D is a higher level solution, where as Qt3D is a more of a bespoke solution for creating 3D runtimes. The Qt Company has a large development team focused on Qt Quick 3D, and Qt3D is done by KDAB to serve different use cases. Both of these projects live under the Qt Project umbrella. Yes I see that is a bit messy from a product standpoint, but from the Qt Company perspective Qt Quick 3D is the solution for high level 3D content we will actively continue to develop going forward.
Since the two 3D modules don't share anything in common, it's a really costly decision for someone to adopt one and then want to switch to the other. For example, Qt Quick 3D seemed like a great choice a year ago, until we ran into it being absent from iOS. Or was missing support for loading models at runtime in an editor-type experience like 3D Studio itself. These issues have recently been solved, but can you imagine being a developer a year ago having to redo everything in Qt3D because of some missing capability, then being faced with the prospect of porting back to QQuick3D? What if some other missing piece of functionality is discovered? The problem, I think, is that the architecture of Qt3D was fundamentally broken, and at the time when QQuick3D started, the decision must have been made to have nothing in common. Qt3D seems better now, but this historical decision now splintered the two, making the cost of switching high. If the difference was merely one being powerful and flexible, and the other being high level, then the latter would be an abstraction built on top of the former, and they would at least have a common data representation. Do you think a common scene representation is a worthwhile goal, in order to reduce the risk for clients adopting one or the other?
Alright thanks for the info! Do you know if Qt Quick3d be available one day on the Qt Marketplace as a separate purchase?
The big problem i see with quick3d is it's not possible to use it in a widgets app?
It's possible to embedded Qt Quick content in Widget content via QQuickWidget. There isn't any direct widget support because Qt Quick 3D depends on the runtime components of Qt Quick (rendering, animation, etc) . If the issue is just the lack of C++ API's in Qt Quick then that is something that is being worked on as part of Qt Quick as a whole currently, but even then Qt Quick and Qt Widgets work in fundamentally different ways and that won't really change if we support doing more Qt Quick stuff from C++.
Can we integrate Unreal Engine in Qt Quick ? Or can we integrate Qt Quick in Unreal engine ?
Good question! Unreal Engine lacks good UI components like Qt Quick has.
@Malek: It is possible to use an external 3D engine with Qt. There are some drawbacks compared to using the built-in Qt Quick 3D engine (syncing, overhead, ...)
@Tuukka: Thank you for your reply. Can you please give me some guide how we integrate it ? I am not able to find in the internet any tuto to do that.
@Malek: Hooking up with an external 3D engine is not trivial. I do not think there is any tutorial available on that - and it is not something that users in general need to do as there are already 3D engine(s) available within Qt.
It would be nice to read a detailed article in this blog about the differences between Qt Quick 3D and Qt 3D. Qt3D has a strong learning curve. I think if you do not have good programming graphics background or a paid course with KDAB it is a dead end. Yes, Andy Nichols has good answers but I mean: 1. What are the main uses of each technology? 2. Consider the following use case: I want to represent a heavy point cloud (10 million to 20 million points), and do some operations in it (cut, crop, represent meshes, manipulate vertex dynamically ...), what should I use: Qt Quick 3D or Qt3D? 2. And please, it would be nice a proper Qt Quick 3D's doc, unlike Qt3D docs.
@Homero: Documentation is never perfect and more tutorials would certainly be valuable. You can check the basics of Qt Quick 3D from https://doc.qt.io/qt-6/qtquick3d-index.html.
@Tukka Turunen I think I expressed wrong. The current Qt Quick 3D doc is pretty good, with a lot of examples. Keep coming!
Good discussion and questions here, thanks!
Regarding the Qt Quick 3D and Qt 3D differences, Andy did a good summary already in the Quick 3D introduction post ( https://www.qt.io/blog/2019/08/14/introducing-qt-quick-3d-high-level-3d-api-qt-quick ) and KDAB has continued improving the Qt 3D on Qt 6 ( https://www.kdab.com/qt3d-renderer-qt6/ ). If you ask my personal opinion, I would refer the beloved 80-20 rule: Qt Quick 3D is a better first choice for 80% of common users. But being on a higher level may mean that its QML API (there isn't a public C++ API available at least yet) doesn't tick all the boxes. For those use-cases, lower level Qt 3D would be the next logical option. Having more choices isn't always a bad thing.. ;-)