[Interest] QtQuick over Qt3D (Qt 5.15)

Oleg Evseev ev.mipt at gmail.com
Wed Mar 31 18:45:45 CEST 2021


Hi all,

I have exactly the same impression as Eric described.
We are still on qt 5.9 due to various issues with qt 3d in qt 5.10-5.14+.

Regarding your question Konstantin take a look at the test example attached
in https://bugreports.qt.io/browse/QTBUG-60612. That will show you how we
are doing QtQuick over Qt3D

In qml:
Scene3D {
    anchors.fill: parent
    World3D {}
}

and World3D is root QEntity that contains a whole 3d world writing in C++.

---
With regards, Oleg.

ср, 31 мар. 2021 г. в 18:33, <eric.fedosejevs at gmail.com>:

> Hi Konstantin,
>
>
>
> Welcome to the hell that is 3D in Qt.
>
>
>
> To understand the problems that you are facing, you need to know a little
> history. Other users can perhaps provide additional insight or correct any
> errors, since my recollection and understanding of these matters is
> probably not perfect.
>
>
>
> Qt3D was introduced in 2016 to much fanfare and was going to be the
> primary 3D solution for Qt. The idea was that Qt3D would provide a
> high-performance core capable of modern 3D graphics. Then, in 2017, Qt Co.
> had a philosophical shift and realized that rather than offering 3D
> functionality through LGPL/C++ (which could also be used by those darned
> open-source users), they could make more money in the short-term by locking
> in John Deere/others into subscription-based commercial licensing to
> display their little tractor animations. Because of the KDE agreement, they
> could not simply modify the license on Qt3D going forward, so they had to
> start from scratch with a new GPL/QML package: enter QtQuick3D.
>
>
>
> The result was that Qt3D was mostly abandoned in a half-finished and
> unpolished state and development efforts shifted to QtQuick3D. In doing so,
> Qt Co. shot themselves in the foot in the long-term, of course, since, as
> you have probably noticed, in the absence of a public C++ interface,
> QtQuick3D is not particularly useful for "complex use cases". As a result,
> "complex users" have either stuck with native OpenGL or have bashed their
> heads on the wall trying to adopt Qt3D, and the dream of modern 3D graphics
> in Qt applications has died.
>
>
>
> Because some customers had already switched to Qt3D, and moreover because
> Qt Co. needs to maintain the illusion that Qt3D is not dead (KDE agreement
> concerns), every few years, Qt Co. will claim that Qt3D is still alive and
> will be improved (just like widgets!). But the proof is in the pudding:
> Qt3D is no longer included in the Qt6 binary distribution, only in source
> form. This just so happens to be the absolute bare minimum that Qt Co. must
> do to avoid giving KDE the right to release all of Qt under a BSD license.
>
>
>
> This brings us to your use case. As you have noticed, the Qt3D examples
> are outdated and many are broken. This is by design to discourage use. In
> Qt6, you can’t even use Qt3D unless you build it from source (not sure
> about the state of the Qt3D examples, I’m sticking with Qt5). QtQuick3D
> (like QtQuick as a whole) has no public C++ interface, even though exposing
> the internal classes would be trivial. This is also by design to lock
> commercial users into QML.
>
>
>
> So what to do? The answer depends on whether your 3D needs fall into the
> category of "complex use", e.g. more than little tractor animations. If
> not, and if you're okay with GPL/commercial licensing, you're honestly
> probably better off switching to QtQuick3D.
>
>
>
> Otherwise, you have a few options. If you’re completely committed to Qt3D,
> but not completely committed to QtQuick for your overlay, you may want to
> use Dear ImGUI on top of Qt3D (Lazlo has a mostly working example on top of
> Qt3D: https://github.com/alpqr/imgui-qt3d). You can also use Dear ImGUI
> directly on top of RHI for Qt5.12+ (https://github.com/alpqr/qrhiimgui).
> I haven’t dug into the code, but you may be able to repurpose these samples
> to instead blit/render QtQuick over top of Qt3D/RHI, without the need to
> create a billboard.
>
>
>
> I would seriously ask yourself whether you want to be developing a new
> application with Qt3D, however. If you’re doing anything more than
> displaying a model or two, there are various open source 3D graphics
> engines/frameworks under active development with better performance and
> features that you can embed into a Qt widget (I’d suggest Magnum, Ogre, and
> BGFX, depending on desired level of abstraction – all have working ImGUI
> overlay examples).
>
>
>
> Cheers,
>
> Eric
>
>
>
> *From:* Interest <interest-bounces at qt-project.org> *On Behalf Of *Konstantin
> Shegunov
> *Sent:* Monday, March 29, 2021 5:29 AM
> *To:* Interests Qt <Interest at qt-project.org>
> *Subject:* [Interest] QtQuick over Qt3D (Qt 5.15)
>
>
>
> Hello,
> I want to overlay a QtQuick UI over a Qt3D scene I'm having, however (here
> comes the "but") I want to do it from C++. I don't want to get into
> instantiating Scene3D at all, I want to drive the Quick scene from Qt3D,
> not vice versa (i.e. I don't want to render the 3D content to an FBO, and I
> don't intend to depend on the QML engine to setup the Qt3D parts).
> Sound(ed) like a simple-enough task at first, but I'm having the worst time
> figuring it out.
>
> To start, I've set the Qt3D things up and I can show my mesh. For the
> second part, I read a lot of the sources around Scene3D, Scene2D and Qt3D
> examples but it doesn't appear this "obvious" thing to do is covered
> anywhere, notwithstanding half the Qt3D examples being broken (either
> segfaulting or not building at all).
>
> I was initially intending to get some ideas from Scene3D, but it appears
> it works directly with the private classes for one, and for two it forces
> synchronous rendering that's driven from the quick scene ... and as a
> typical QtQuick item it doesn't expose a public C++ class ...
> If I missed something there, please feel welcome to correct me.
>
> So after the next batch of sifting through Qt3D's own internals, the
> renderer plugin and such, I am relatively convinced the only reasonable way
> to do this is to render the UI offscreen to a texture and to just slap that
> texture on the screen on each Qt3D frame. Is this correct? If that's so,
> let's say I can render the quick scene to a texture, how do I go about
> putting it on the screen after the framegraph's been executed? I couldn't
> see a framegraph node that'd do that for me. Am I to write my own? Is it
> the case that I need to create a "fake" quad (i.e. a billboard) that I must
> reorient together with the camera? I saw in one of Florian Blume's
> repositories that he uses a second camera and another branch in the
> framegraph to put a background image in. Is this the way to do it, or is
> there some better way?
>
> Additional question(s):
> Do I spin my thread (which I sync manually) for rendering the quick scene?
>
> Thanks for any and all pointers.
>
> Kind regards,
> Konstantin.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210331/626e6993/attachment-0001.html>


More information about the Interest mailing list