Hi Julien Thanks for your response.
On Thu, Feb 12, 2026 at 5:12 PM Julien Cabieces < [email protected]> wrote: > > 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 do not see a problem with source incompatible changes in QRhi in minor Qt releases: - direct QRhi interaction would be limited to a small area of code with low level abstraction - incompatible changes can be dealt with a bunch of #ifdefs - Qt promises such changes to be kept at minimum. At this point, QRhi and Qt Quick on top of it are quite stable, so I don't see why they would suddenly do some large changes. 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? > Qt Quick 3D is too limited. For a start, it has fixed rendering pipeline, more limited to what we already have in QGIS 3D. Then, there's only little support for C++ and most of APIs are simply QML-only. The claim about "most use cases" in the Qt mailing list was likely about use cases they had in mind, not _all_ use cases for a 3D engine :-) 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 > ? > Bits like camera, material system, geometry primitives and a scene graph - that's standard 3D engine stuff really which has been done many times... High level 3D engines are certainly something to consider as well, and I have evaluated a couple of them. Overall my impression was that those are generally massive pieces of software with lots of new dependencies, that are generally not built for being embedded in existing applications. (e.g. Godot, O3DE) I would be happy to hear any recommendations for higher level 3D engines that would be easy to embed! Cheers Martin
_______________________________________________ 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
