[Interest] QtQuick over Qt3D (Qt 5.15)

[Konstantin Shegunov]

On Wed, Mar 31, 2021 at 6:32 PM <eric.fedosejevs at gmail.com> wrote:

> Hi Konstantin,
>

Hello Eric,


> 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.
>

I know a little bit about the history. I've been hanging around Qt from the
4.5 days, or thereabouts.

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.
>

While I share some or more of the sentiments expressed, I really don't want
to get into this. The Roland thread(s)™ are epic enough and I've been
keeping quiet on purpose. (Note: Qt3D is a project of KDAB's, not of QtC's
making)


> 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.
>

Even if this were true, which is what I assume Peppe's reacting to, it's
really beside the point. I asked a very specific _technical_ question, I
don't intend to get into the politics of it at this time.

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.
>

Yes to the first, no to the second. Or to phrase it another way, it's a pet
project for which I'm evaluating Qt3D and QtQuick. That's why I was so
specific about my requirements. I don't make money of it, so the commercial
offering is out of the question. I'm poor, so to say. As for GPL I
generally dislike the philosophy of it, it's basically like the commercial
licenses, but from the other side. What I write to be used as open source
(which isn't that much, but still ...) I license under weak copyleft
licenses. That's how I do it, that's what I like, that's what I want to use
(i.e. the LGPL).

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.
>

This is useful, thanks! I'm not committed to any of it, but I'm going to go
through the code to see if I can indeed get some idea of how to do what I
want to do. I took a peak at ImGUI, but honestly, I'm not really convinced.
Still I'm going to consider the suggestion, so thank you for that too!

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).
>

Yes, I've used OGRE into a Qt widget before. Actually it was before Qt had
QWindow and QWidget::createWindowContainer, so hacking into QWidget::create
was required at that time. But anyway, OGRE is an option, if or after I
give up on my current struggles. As a note, I'm also aware of the perceived
subpar performance of Qt3D. My own tests showed a rather poor framerate for
a couple of thousand geometries with a phong material (few vertices per
polygon) on my RX580. I can (probably) live with it ... maybe.

On Wed, Mar 31, 2021 at 7:49 PM Oleg Evseev <ev.mipt at gmail.com> wrote:

> Hi all,
>

Hi Oleg,

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++.
>

Thanks, but this is sort of where I'm coming from. There are a few things
that this does, that I explicitly want to avoid - it renders to an FBO, not
to the actual GL surface; it sets up the aspects and the Qt3D internals for
me, which I do from C++ already; it builds the scene from the QML component
instantiation point, which I don't want to do (I have it in C++ already);
and finally the Qt3D rendering is driven (synchronously) by the QtQuick
scene frame graph, which I want in reverse.

On Thu, Apr 1, 2021 at 1:09 AM joao morgado <joaodeusmorgado at yahoo.com>
wrote:

> Unlike what was stated above, AFAIK the development of QtQuick3D has
> nothing to do with Qt3D licensing and kde agreements and what so ever.
> The following blog shows a good picture of QtQuick3D and why it was
> created, purely based on technicall reasons.
>

Maybe, but it's not perceived that way by many. Things can appear
differently than they are, depending on how you present them. If you
couldn't tell (from the top part of this email) I'm one of the 'sceptics'
or 'dissenters' if you wish, I actually agree with some of the points made
in the long-winded thread(s) about the politics and behaviour of the QtC;
this thread, however, is not about that. And while repeating myself in the
same email here I go: I don't want to get into it.
Let's solve my problem and discuss the other stuff elsewhere. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210401/9a3794cf/attachment.html>