Qt Quick 3D survey - November 2024

make it lgpl

I've been using Qt3D for sometime and now that it's deprecated, I looked into Qt Quick 3D. I really like how Qt Quick 3D has way better documentation. It seems really dumbed down and great for simple things, but it seems pretty hard to manage or create custom rendering pipelines. It also lacks the ability to control things through c++. I've decide to just use QRhi directly for 3D since it reduces the rendering overhead and likely improves performance. I'm in the process of porting my OpenGL code and Qt3D code to QRhi because it seems easier, and likely will be supported long term. There was Qt3D 1.0 in Qt4, didn't go anywhere, and drop, Qt3D 2.0 (KDAB, Qt5 to Qt6.7) never fully developed especially from documentation standpoint, lots of bugs that require workarounds. I feel like Qt Quick 3D could be dropped because of lack of use. I expect that QRhi is here to stay, and it's a good technology, even though it's a documented private API.

QtQuick3D Physics Joints constraints pls to Qt6.9

QtQuick3D Physics Joints constraints pls to Qt6.9

I am a looong time Qt developer. Once in a while I try find a itch to scratch with a 3D project but rarely (as in never) have I needed 3D for a project. If you were to take inventory of all the screens in your life -computer,phone,car, toaster, etc. I am hard pressed to find one 3D display. Nor have I ever said to myself that such a screen would be great.

Of course I am not that big of a simpleton to not know that 3D is needed for apps such as cad, imaging, and game. It's just that none of these are a part of my reality as a Qt developer.

From my selfish Qt developer perspective, I would rather see more advanced QML features , especially for desktop applications.

I like QtQuick3D a lot, for my purposes it is in a good state. There are still some limiting things for me though. Once you start having a lot of Nodes in your scene you can start to see performance tank, but only due to CPU cost. Also when I use a model with multiple materials exported from a program like blender. Even though many materials are identical, they still don't get batched and produce a draw call for each whilst this could be batched together, I think. So in essence reducing CPU cost when scaling with many Nodes/Materials in the scene would help me.

On the commercial side of things it's important for QtQuick3D to get a foothold in some spaces. This is hard because companies will first look for free options or things others have made. Having it not licensed LGPL will make all the open source projects not choose it and then you purely rely on direct purchases from vendors starting new projects. If the latter is the case, you really have to improve the example projects to showcase to companies what they can do and then they can just copy the code for their project to get results faster. The coffee machine example for example was a great way to drive sales in that area I can imagine.

I also like QtQuick3D a lot. It's easy to use compared to raw OpenGL, it saves a lot of work, also we can still use shaders to do more low level stuff. I think it could be improved in Android, were the performance is bad compared with iOS for example, skyboxes do not work properly, and textures have bad porformance. I just took the survey, there was a questions asking how disapoint I would be if I would not be able to use QtQuick3D anymore. I sure hope Qt company does not even think of dropping it :(