<div dir="ltr"><div dir="ltr"><div>Hi Julien</div><div><br></div><div>Thanks for your response.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 12, 2026 at 5:12 PM Julien Cabieces <<a href="mailto:julien.cabieces@oslandia.com">julien.cabieces@oslandia.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I'm no expert in 3D, so my concerns are mainly about<br>
software developement general matters.<br>
<br>
I'm a bit afraid about moving from a Qt deprecated module to another Qt semi-private module<br>
where the documentation clearly state that the API is unstable [0]<br>
<br>
"[...] the API is only guaranteed to work with the Qt version the application<br>
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)."<br>
<br>
That could lead to constant rework to adapt our code to their API<br>
modifications, and would require to support all different API versions<br>
because we don't control what Qt version is shipped in Linux distribution.<br>
<br>
We have no garantee that this API would become public one day, or that<br>
it would not be dropped/reworked completely.<br></blockquote><div><br></div><div>I do not see a problem with source incompatible changes in QRhi in minor Qt releases:</div><div>- direct QRhi interaction would be limited to a small area of code with low level abstraction</div><div>- incompatible changes can be dealt with a bunch of #ifdefs</div><div>- 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.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I read here [1] that Qt 3D "has for most use cases by now been<br>
superseded by Qt Quick 3D". Would it be possible to port our code to Qt<br>
Quick 3D? Or is it too limited for what we try to achieve?<br></blockquote><div><br></div><div>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 :-)</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Finally, I imagine that moving to a low level dependency would force us to develop<br>
state of the art 3D features like you point it out in your mail,<br>
leading to increased developement costs. If we choose<br>
to move away from Qt 3D, shall we not move to a high level API 3D engine<br>
?<br></blockquote><div><br></div><div>Bits like camera, material system, geometry primitives and a scene graph - that's standard 3D engine stuff really which has been done many times...</div><div><br></div><div>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!</div><br></div><div class="gmail_quote gmail_quote_container">Cheers</div><div class="gmail_quote gmail_quote_container">Martin</div><div class="gmail_quote gmail_quote_container"><br></div></div>