Hi Martin,
Thank you for raising this important topic. I'm no expert in 3D, so my concerns are mainly about software developement general matters. I'm a bit afraid about moving from a Qt deprecated module to another Qt semi-private module where the documentation clearly state that the API is unstable [0] "[...] the API is only guaranteed to work with the Qt version the application was developed against. Source incompatible changes are however aimed to be kept at a minimum and will only be made in minor releases (6.7, 6.8, and so on)." That could lead to constant rework to adapt our code to their API modifications, and would require to support all different API versions because we don't control what Qt version is shipped in Linux distribution. We have no garantee that this API would become public one day, or that it would not be dropped/reworked completely. I read here [1] that Qt 3D "has for most use cases by now been superseded by Qt Quick 3D". Would it be possible to port our code to Qt Quick 3D? Or is it too limited for what we try to achieve? Finally, I imagine that moving to a low level dependency would force us to develop state of the art 3D features like you point it out in your mail, leading to increased developement costs. If we choose to move away from Qt 3D, shall we not move to a high level API 3D engine ? Kind regards, Julien [0] https://doc.qt.io/qt-6/qrhi.html#details [1] https://lists.qt-project.org/pipermail/development/2024-March/045127.html > Hi all > > As you know, 3D map views in QGIS are based on the Qt 3D module. Since Qt 6.8 > (released in Oct 2024) the Qt 3D module is marked as > deprecated [1]. This does not mean that it will be removed anytime soon, but > there's no development planned by the Qt company. There has > been very little development in Qt 3D in recent years and little adoption > within wider Qt community. > > A question naturally comes up - what should we do within the QGIS project? > Stay with Qt 3D or start moving towards something else? > > At Lutra, we have started some internal discussions about this. Qt 3D does > its job, but we find it often over-complicated (e.g. framegraph, > entity-component-system scene representation) and under-documented. And with > the lack of direct access to graphics APIs we have > accumulated various workarounds and bugs that are difficult to fix. > > If we wanted to switch to something else, there are lots of options: from the > very low-level wrappers around graphics APIs all the way to full > blown 3D rendering engines for games. > > At this point, QRhi [2] looks like an interesting option. QRhi is a part of > Qt GUI module and it is a relatively low-level abstraction on top of > modern graphics APIs (Metal, Vulkan, Direct3D). It is already being used > under the hood by Qt Quick and Qt Quick 3D (and optionally also by Qt > 3D). It is kind of semi-private API of Qt GUI module, but it is well > documented and the API has been quite stable despite the lack of > source/binary compatibility guarantees. > > With a low-level approach like QRhi we would get a lot of control, at the > expense of having to roll out our own abstractions that Qt 3D provides > (e.g. camera, geometry, material, scene graph). > > I would love to hear some thoughts from other QGIS devs about the possible > migration away from Qt 3D. If there will be consensus, we can > then start working on a QEP and prepare a more detailed plan. > > Regards > Martin > > [1] https://doc.qt.io/qt-6/whatsnew68.html > [2] https://doc.qt.io/qt-6/qrhi.html > > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia [email protected] _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
