Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-04-12 Thread Konstantin Shegunov
On Thu, Apr 1, 2021 at 8:40 AM Paul Lemire  wrote:

> Hello Paul,
>
Hello,

> It sounds to me like Scene2D is what you want as it renders a QtQuick
> scene into an offscreen texture which can then be applied to a Qt 3D mesh.
> Unfortunately it can only be used from QML.
>
> That being said, nothing is stopping you from having 90% of the Qt3D code
> in C++ and just having a small part in QML that essentially only
> instantiates your 3D Scene and the Scene2D and povides the 3D scene with
> the Scene2D texture. I think that would be the easiest.
>
Yes, that's what I've been using to "guide me through". And I do
acknowledge I can use it from QML, but there's also this thing:
https://bugreports.qt.io/browse/QTBUG-90411

> If you want to do it purely in C++, another approach (but more complex to
> set up and that would have to be tested) is to use a QSharedGLTexture to
> tell Qt3D about an existing OpenGL texture by textureId. This means using
> the Qt shared OpenGL context, and manually rolling your own
> QQuickRenderControl to render QtQuick into a QOpenGLTexture, and then
> providing the QOpenGLTexture's id to the QSharedGLTexture. You'll also need
> to ensure proper synching using fences (QWaitFence/QSetFence) to ensure
> that Qt3D is not trying to render while the the shared texture is being
> updated. This would be more or less similar to one of the manual test we
> have in Qt3D
> https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2
>
> I hope that helps,
>
Indeed, thanks! Still, it doesn't seem there's a way I can hook into the
frame graph and just have anything drawn directly on the screen, is there?
The best I could do, as far as I can tell, is to have an ortographic camera
looking at a quad, which I can texture with whatever comes from the QtQuick
scene, it appears (i.e. what Florian Blume's code does here:
https://github.com/florianblume/Qt3D-BackgroundImage). Is this correct?

On Thu, Apr 1, 2021 at 11:15 AM Oleg Evseev  wrote:

> By the way in Qt 5.14 there comes an option to use Scene3D as underlay
> without FBO:
>
> https://doc.qt.io/qt-5/qml-qtquick-scene3d-scene3d.html#compositingMode-prop
>
> I did tried this, but encountered with a problem when using together with
> OnDemand:
> https://bugreports.qt.io/browse/QTBUG-82861
>

Indeed. It does seem bugs reports've accumulated for Qt3D over time. View3D
also segfaults (the example) for some reason.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-04-12 Thread Paul Lemire via Interest

Hello Konstantin,

On 4/3/21 3:09 AM, Konstantin Shegunov wrote:
On Thu, Apr 1, 2021 at 8:40 AM Paul Lemire > wrote:


Hello Paul,

Hello,

It sounds to me like Scene2D is what you want as it renders a
QtQuick scene into an offscreen texture which can then be applied
to a Qt 3D mesh. Unfortunately it can only be used from QML.

That being said, nothing is stopping you from having 90% of the
Qt3D code in C++ and just having a small part in QML that
essentially only instantiates your 3D Scene and the Scene2D and
povides the 3D scene with the Scene2D texture. I think that would
be the easiest.

Yes, that's what I've been using to "guide me through". And I do 
acknowledge I can use it from QML, but there's also this thing: 
https://bugreports.qt.io/browse/QTBUG-90411 

Ok we will need to take a look at that. Shouldn't be too hard to fix but 
not sure how we can fixes to 5.15 publicly. Qt 3D from dev branch (Qt 6) 
does build with 5.15 though but I'm not sure we had ported Scene2D to Qt 
6 due to other changes in QtQuick.


If you want to do it purely in C++, another approach (but more
complex to set up and that would have to be tested) is to use a
QSharedGLTexture to tell Qt3D about an existing OpenGL texture by
textureId. This means using the Qt shared OpenGL context, and
manually rolling your own QQuickRenderControl to render QtQuick
into a QOpenGLTexture, and then providing the QOpenGLTexture's id
to the QSharedGLTexture. You'll also need to ensure proper
synching using fences (QWaitFence/QSetFence) to ensure that Qt3D
is not trying to render while the the shared texture is being
updated. This would be more or less similar to one of the manual
test we have in Qt3D
https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2



I hope that helps,

Indeed, thanks! Still, it doesn't seem there's a way I can hook into 
the frame graph and just have anything drawn directly on the screen, 
is there? The best I could do, as far as I can tell, is to have an 
ortographic camera looking at a quad, which I can texture with 
whatever comes from the QtQuick scene, it appears (i.e. what Florian 
Blume's code does here: 
https://github.com/florianblume/Qt3D-BackgroundImage 
). Is this correct?


Yes you will need to have a fullscreen quad mesh to draw the texture + 
matching FrameGraph part to draw only the quad  after the content of 
your 3D scene.


Many ways of doing the same thing: using the QPlaneMesh with a rotation 
+ camera or providing a custom plane mesh already in NDC space (-1  to 
1) in which case you don't even need to worry about having a camera.




On Thu, Apr 1, 2021 at 11:15 AM Oleg Evseev > wrote:


By the way in Qt 5.14 there comes an option to use Scene3D as
underlay without FBO:
https://doc.qt.io/qt-5/qml-qtquick-scene3d-scene3d.html#compositingMode-prop



I did tried this, but encountered with a problem when using
together with OnDemand:
https://bugreports.qt.io/browse/QTBUG-82861



Indeed. It does seem bugs reports've accumulated for Qt3D over time. 
View3D also segfaults (the example) for some reason.


Kind regards,
Konstantin.



--
Paul Lemire | paul.lem...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-04-01 Thread Oleg Evseev
By the way in Qt 5.14 there comes an option to use Scene3D as underlay
without FBO:
https://doc.qt.io/qt-5/qml-qtquick-scene3d-scene3d.html#compositingMode-prop

I did tried this, but encountered with a problem when using together with
OnDemand:
https://bugreports.qt.io/browse/QTBUG-82861

чт, 1 апр. 2021 г. в 08:42, Paul Lemire via Interest <
interest@qt-project.org>:

> Hello,
>
> It sounds to me like Scene2D is what you want as it renders a QtQuick
> scene into an offscreen texture which can then be applied to a Qt 3D mesh.
> Unfortunately it can only be used from QML.
>
> https://code.qt.io/cgit/qt/qt3d.git/tree/examples/qt3d/scene2d
>
> That being said, nothing is stopping you from having 90% of the Qt3D code
> in C++ and just having a small part in QML that essentially only
> instantiates your 3D Scene and the Scene2D and provides the 3D scene with
> the Scene2D texture. I think that would be the easiest.
>
> If you want to do it purely in C++, another approach (but more complex to
> set up and that would have to be tested) is to use a QSharedGLTexture to
> tell Qt3D about an existing OpenGL texture by textureId. This means using
> the Qt shared OpenGL context, and manually rolling your own
> QQuickRenderControl to render QtQuick into a QOpenGLTexture, and then
> providing the QOpenGLTexture's id to the QSharedGLTexture. You'll also need
> to ensure proper synching using fences (QWaitFence/QSetFence) to ensure
> that Qt3D is not trying to render while the the shared texture is being
> updated. This would be more or less similar to one of the manual test we
> have in Qt3D
> https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2
>
> I hope that helps,
>
> Paul
>
> On 3/29/21 12:28 PM, Konstantin Shegunov wrote:
>
> 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 
> listInterest@qt-project.orghttps://lists.qt-project.org/listinfo/interest
>
> --
> Paul Lemire | paul.lem...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread Paul Lemire via Interest

Hello,

It sounds to me like Scene2D is what you want as it renders a QtQuick 
scene into an offscreen texture which can then be applied to a Qt 3D 
mesh. Unfortunately it can only be used from QML.


https://code.qt.io/cgit/qt/qt3d.git/tree/examples/qt3d/scene2d

That being said, nothing is stopping you from having 90% of the Qt3D 
code in C++ and just having a small part in QML that essentially only 
instantiates your 3D Scene and the Scene2D and provides the 3D scene 
with the Scene2D texture. I think that would be the easiest.


If you want to do it purely in C++, another approach (but more complex 
to set up and that would have to be tested) is to use a QSharedGLTexture 
to tell Qt3D about an existing OpenGL texture by textureId. This means 
using the Qt shared OpenGL context, and manually rolling your own 
QQuickRenderControl to render QtQuick into a QOpenGLTexture, and then 
providing the QOpenGLTexture's id to the QSharedGLTexture. You'll also 
need to ensure proper synching using fences (QWaitFence/QSetFence) to 
ensure that Qt3D is not trying to render while the the shared texture is 
being updated. This would be more or less similar to one of the manual 
test we have in Qt3D 
https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2


I hope that helps,

Paul


On 3/29/21 12:28 PM, Konstantin Shegunov wrote:

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@qt-project.org
https://lists.qt-project.org/listinfo/interest


--
Paul Lemire | paul.lem...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel: France +33 (0)4 90 84 08 53, http://www.kdab.fr
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread Konstantin Shegunov
On Wed, Mar 31, 2021 at 6:32 PM  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 

Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread joao morgado via Interest
X, depending on 
desired level of abstraction – all have working ImGUI overlay examples).

  

Cheers,

Eric

  

From: Interest  On Behalf Of Konstantin 
Shegunov
Sent: Monday, March 29, 2021 5:29 AM
To: Interests Qt 
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@qt-project.org
https://lists.qt-project.org/listinfo/interest
  ___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread Giuseppe D'Angelo via Interest

On 31/03/2021 17:31, eric.fedosej...@gmail.com wrote:
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. 


It's the Nth time that a certain company gets nominated without any 
reason whatsoever w.r.t. the thread in question, and in statements 
without any factual grounding (aka [citation needed]).


(In another instance, even stronger, derogatory wording has been used in 
another totally unrelated context.)


Not only all such mentions are therefore against netiquette and 
off-topic for this list (we don't discuss hearsay, we discuss how to use 
Qt), they're borderline libellous and may cause the Qt Project to having 
to protect itself and shut these lists down.



In not so many words: STOP IT NOW.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread Roland Hughes


On 3/31/2021 11:46 AM, Eric wrote:

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.

Thank you for an incredibly informative post!

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread Oleg Evseev
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, :

> 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  *On Behalf Of *Konstantin
> Shegunov
> *Sent:* Monday, March 29, 2021 5:29 AM
> *To:* Interests Qt 
> *Subject:* [Interest] QtQuick over Qt3D (Qt 5.15)
>
>
>

Re: [Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-31 Thread eric.fedosejevs
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  On Behalf Of Konstantin 
Shegunov
Sent: Monday, March 29, 2021 5:29 AM
To: Interests Qt 
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, a

[Interest] QtQuick over Qt3D (Qt 5.15)

2021-03-29 Thread Konstantin Shegunov
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@qt-project.org
https://lists.qt-project.org/listinfo/interest