Re: [Development] Removing Qt 3D from release configuration in dev branch
HiThere’s no relationship crisis!The topic is a legitimate thing to discuss and it was brought up here to get as much feedback as possible from the community.MikeOn 6 Apr 2024, at 13:04, Mathias Hasselmann wrote: I am really confused by this thread. If I read Jani's mail correctly, the plan is: Keep everything as it is, except for adding Qt3D to the installers? Or more exaggerated: Keep everything as it is, except for the official endorsement. Or even more exaggerated: Keep everything as it is, except for the Qt users' convencience? That's what it looks like to me from the very outside. How does this step help the users, the customers, the project, the product? Am I exaggerating? Am I confused? Or is this all really just Qt Company and KDAB living out a relationship crisis at the expense of users and customers? Regards, and sorry if I misunderstood things, Mathias Am 05.04.2024 um 07:11 schrieb Jani Heikkinen via Development: Some comments below -Original Message- From: Development On Behalf Of Mike Krus via Development Sent: torstai 4. huhtikuuta 2024 17.14 To: Tuukka Turunen Cc: Qt Project Development Subject: Re: [Development] Removing Qt 3D from release configuration in dev branch Hi everyone Disclaimer: I'm one of the contributors to Qt3D, and a KDAB employee. As mentioned, early discussions have taken place between KDAB and tQtC around this issue, although much needs to be clarified as to why, how and when this happens. As mentioned by Tuukka, Qt3D was introduced in Qt4 timeline, but didn't make it into Qt5. KDAB invested a lot of time in a complete rewrite of the module (don't think it shares anything with the original) and it was made available sometime in the Qt 5 timeline. Many contributions have been made since then, including in Qt6 with the introduction of an RHI based backend (although to this day this doesn't have feature parity with the GL backend due to limitations of RHI). But since then things have settled down in the Qt6 branch, no major features have been added. KDAB has continued to contribute bug fixes, and small features in support of our clients. So development has indeed been very slow. So hence came the discussions on retiring Qt3D. KDAB is ok on the principle and committed to keep maintaining Qt3D in the same manor. But there's a lot of implications. So what does "removing qt3d from release configuration" mean for contributors? - if CI remains, gerrit continue to check commits right? If so, the version of qt this is built against remains controlled by the dependencies.yaml file? Yes, that's possible and I think that's the idea behind Tuukka's proposal. - but I also presume qt5.dev integration will no longer affect qt3d? ie there will no automated checked that qt3d continues to build against the rest qt when that changes and the dependencies.yaml won't be updated automatically? Not necessarily, we can add qt3d in the dependency update round as extra module if we want to do so. That way qtd3 would be checked pretty much like it is done today. The difference is that it won't block the dependency update round, release etc and won't be part of qt release (binary packages, src packages, git tags etc) - no more automatic branching? If we want to keep automatic branching we can still enable it. - so how does versioning work? Would it be up to maintainer to decide when to do branches, tags, releases? If we remove qt3d from release configuration we don't add tags or include it in the release packages. If maintainer wants to "release" new version from qt3d I think it is possible but it shouldn't follow qt releasing schema etc. But what release means in this context? Git tag? src packages somewhere? From the releasing point of view I would not like to see that we remove qt3d from the official release configurations but then start releasing qt3d as its own release; it would just increase our workload... And what would be a good strategy for that? - module life cycle in general needs to be defined. And what does "removing qt3d from release configuration" mean for users/developers? - no longer in the installer, or tarballs? True - probably no longer in linux distributions? - do ABI/API compatibility rules still apply? - for new projects, no more C++ 3D scene graph API, and no more LGPL licensed module to do 3d. At least not bundled with Qt? - only way to get the code would be to check it out and build it? I think this is
Re: [Development] Removing Qt 3D from release configuration in dev branch
Hi everyone Disclaimer: I’m one of the contributors to Qt3D, and a KDAB employee. As mentioned, early discussions have taken place between KDAB and tQtC around this issue, although much needs to be clarified as to why, how and when this happens. As mentioned by Tuukka, Qt3D was introduced in Qt4 timeline, but didn’t make it into Qt5. KDAB invested a lot of time in a complete rewrite of the module (don’t think it shares anything with the original) and it was made available sometime in the Qt 5 timeline. Many contributions have been made since then, including in Qt6 with the introduction of an RHI based backend (although to this day this doesn’t have feature parity with the GL backend due to limitations of RHI). But since then things have settled down in the Qt6 branch, no major features have been added. KDAB has continued to contribute bug fixes, and small features in support of our clients. So development has indeed been very slow. So hence came the discussions on retiring Qt3D. KDAB is ok on the principle and committed to keep maintaining Qt3D in the same manor. But there’s a lot of implications. So what does “removing qt3d from release configuration” mean for contributors? - if CI remains, gerrit continue to check commits right? If so, the version of qt this is built against remains controlled by the dependencies.yaml file? - but I also presume qt5.dev integration will no longer affect qt3d? ie there will no automated checked that qt3d continues to build against the rest qt when that changes and the dependencies.yaml won’t be updated automatically? - no more automatic branching? - so how does versioning work? Would it be up to maintainer to decide when to do branches, tags, releases? And what would be a good strategy for that? - module life cycle in general needs to be defined. And what does “removing qt3d from release configuration” mean for users/developers? - no longer in the installer, or tarballs? - probably no longer in linux distributions? - do ABI/API compatibility rules still apply? - for new projects, no more C++ 3D scene graph API, and no more LGPL licensed module to do 3d. At least not bundled with Qt? - only way to get the code would be to check it out and build it? - given qt3d is a proper qt module (as opposed to a simple library), including qml (and it’s own) plugins, and that it was up to now installed along the rest of Qt, how much work will it be for existing users to change their build to continue getting new versions of Qt3D? - and finally, how do we warn users of the upcoming change? While I have no problems with the aim of this, we need to figure out the important details first before pulling the trigger. Mike > On 27 Mar 2024, at 08:39, Tuukka Turunen wrote: > > Hi, > We have been discussing with KDAB about the future maintenance of Qt 3D > module. It is a quite large and complex module, which has for most use cases > by now been superseded by Qt Quick 3D. Since Qt 3D has been available for a > long time, it should continue to be available for those who still need it. It > is also part of all currently supported releases, which would continue to > have it in upcoming patch level releases. > After discussing with KDAB (maintainer of Qt 3D) on how to proceed, we came > up with the following and also agreed that I’ll summarize it for the Qt > project development list: > • Qt 3D module is removed from official release configuration in the dev > branch, i.e. no longer part of the releases from Qt 6.8 onwards > • Qt 3D continues to be part of Qt project, it continues to be covered by > CI, and available in the repository for those who want to use it > • Even though not part of the release configuration, intention is to keep > Qt 3D working also with Qt 6.8 > • Qt 6.7 and older releases continue to have Qt 3D module in the upcoming > patch releases > Qt 3D module was initially developed for Qt 4 and then received a major > overhaul for Qt 5. It was also brought forward to Qt 6. Initially the idea > was to offer Qt 3D as a separate item in Qt 6.0 via package manage > (https://wiki.qt.io/Qt_6.0.0_Modules), but since we were not able to make > this modularity successful, it was included to the release configuration > along with the other add-on modules. Qt Quick 3D is a later addition to Qt, > originating from the contribution from NVIDIA > (https://www.qt.io/blog/2017/02/20/introducing-qt-3d-studio), initially as a > separate runtime, then refactored into Qt Quick 3D for Qt 5 to achieve better > alignment with Qt Quick 2D and after that completely reworked to be fully > aligned with Qt Quick in Qt 6. > Yours, > Tuukka — Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts -- Development mailing list Development@qt-project.or
Re: [Development] Qt3D RHI render plugin status?
Hi It was reinstated as a default in 6.4 I believe. It’s certainly installed in my 6.4.0 installation. Mike > On 30 Nov 2022, at 08:30, Mark De Wit wrote: > > Dear Qt devs, > > I have a Qt 3D application that relies on the RHI render plugin, and is stuck > on Qt 6.1.x due to the GPL licensing issue for Qt6ShaderTools.dll. > > Now that Qt6ShaderTools has been relicensed to LGPL in June of this year, > will the RHI render plugin be re-instated in the default binaries with Qt 6.5? > > All the relevant bugs have been closed over a year ago, and I don't see any > other discussion on this subject? > > Mark > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development — Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Default assignees in Jira (was: Jira tickets for Qt Print Support)
> On 2 Jun 2022, at 09:24, Edward Welbourne wrote: > > Sze Howe Koh (01 June 2022 16:03) wrote: >> Changing the default of Qt Print Support to "Unassigned" sounds >> reasonable in this case. How does this occur? > > I believe Jira admins do this on request. > I suggest Mike e-mail Alex Blasche about that. will do >> Also, Qt 3D tickets are auto-assigned to Sean Harmer who hasn't been >> active in ~1.5 years [1]. Mike Krus has been manually taking recent >> tickets [2] and has privately expressed willingness to take Sean's >> place -- I'd like to nominate Mike as default assignee for Qt 3D. As >> far as I'm aware, the formal procedure for this and the eligibility >> criteria are not specified in any QUIP -- does it make sense to add >> Jira default assignees to QUIP 2? > > I think the default assignee situation is mostly a case if "is anyone > willing ?" with perhaps a side-order of whether the Maintainer of > relevant code considers them suitable. So if Mike Krus is willing and > we have no objection from a the Maintainer of Qt 3D, it'd be better to > have the tickets assigned by default to someone willing and active. > > I see Sean is in fact listed [0] as one of the Maintainers of Qt 3D > (alongside Laszlo Agocs, Svenn-Arne Dragly and Paul Lemire); if he is no > longer active, it's perhaps time for someone to politely contact him and > ask if he'd like to step down and, if so, in favour of whom. I can see what Sean thinks of it. Someone should do the same with Svenn-Arne and Laszlo since they have not contributed to Qt3D for even longer. Think the idea at the time was for someone from the Qt Company to be involved but this has never happened. > The coming > virtual QtCS [1] has a session on the question of how we deal with Ghost > Maintainers, so this may be an example to take up there. I am unfortunately not available next week. Mike > [0] https://wiki.qt.io/Maintainers > [1] https://wiki.qt.io/Qt_Contributors_Summit_2022_-_Program > > Eddy. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development — Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QtDeclarative behaviour change affecting Qt3D
Hi I’ve been investigating QTBUG-103881 for 6.4 (dev) The test instantiates a qml scene using QQmlComponent. The scene has some items and sets some properties. For the record, this is the scene [1] The component is created properly (I think) and the scene is then created, but some of the setters are not called. In particular, QPickingSettings::setPickMethod(…) is not called [2] This causes the Qt3D test to fail. The whole thing worked fine in 6.3. There has been no change in Qt3D in that area recently. I believe the behaviour of QtDeclarative has changed. Anyone have any clues of what the issue might be? Mike [1] https://code.qt.io/cgit/qt/qt3d.git/tree/tests/auto/render/raycastingjob/testscene_worldraycasting.qml [2] https://code.qt.io/cgit/qt/qt3d.git/tree/src/render/frontend/qpickingsettings.h — Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Some configurations still seem to use qmake for some parts: https://testresults.qt.io/logs/qt/qt3d/5ef6de3b5deb13254200c1f385ce09008b287760/MacOSMacOS_10_14x86_64MacOSMacOS_10_14x86_64Clangqtci-macos-10.14-x86_64-f695c4DisableTests_Sccache/67c64555fe39a6412f13f7c4d92663fc0c175a7b/build_1607682919/log.txt.gz > On 11 Dec 2020, at 09:13, Alexandru Croitor wrote: > > Hi, > > qmake Qt builds have been disabled in the CI and in configure. > > Regards, > Alex. > >> On 8. Dec 2020, at 17:51, Alexandru Croitor wrote: >> >> Hi again, >> >> A short update on the build system switch. >> >> Sine my last email (half a year ago) a number of issues were raised that we >> had to tackle in order to consider switching Qt's main build system to CMake. >> >> Some of those issues were tracked in the following JIRA issues >> https://bugreports.qt.io/browse/QTBUG-86053 >> https://bugreports.qt.io/browse/QTBUG-88741 >> as well as some other ones. >> >> Since then: >> - most of the important issues have been fixed >> - multiple improvements have been done to the Qt build DeveloperXperience >> - qmake CI coverage has been mirrored >> - configure's default has been changed to build Qt with CMake >> - our CI and packaging pipelines have switched to using CMake for a while now >> - the Qt 6.0.0 that shipped today was built using CMake >> >> As such, we intend to remove support for building Qt with qmake in the 6.1 >> branch (aka dev) >> >> This means: >> - we will remove the qmake CI configurations in dev branch >> - we will change configure to refuse configuring Qt with the -qmake option >> - pro2cmake will not be used anymore, and the CMakeLists.txt files become >> the source of truth >> which means CMakeLists.txt files will now have to be modified directly >> - configurejson2cmake will not be used anymore, and the configure.cmake >> files will become the source of truth (not configure.json) >> which means configure.cmake files will now have to be modified directly >> - we will not remove the qmake .pro and configure.json files for now, it >> will be done sometime later in the future >> https://bugreports.qt.io/browse/QTBUG-88742 >> >> We intend to do it by the end of the week, if nothing critical comes up. >> >> Regards, >> Alex. >> >> >>> On 1. Jul 2020, at 13:31, Alexandru Croitor wrote: >>> >>> Hi everyone, >>> >>> An update on the build system switch. >>> >>> >>> On the 8th of June I mentioned that we wanted to make the "CMake build >>> system" the main one and remove the .pro files. >>> The tentative date was 1st of July (today). >>> >>> As a result of the discussion, we identified some items that had to be >>> tackled first. >>> Not all of those have been addressed yet. >>> >>> So we are postponing the switch until further notice. >>> >>> Regards, >>> Alexandru. >> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development — Mike Krus | mike.k...@kdab.com | Senior Software Engineer & Teamlead KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: Qt 6.0 Feature Freeze is getting closer
Hi > On 20 Aug 2020, at 08:28, Jani Heikkinen wrote: > > Hi, > > Kindly reminder: Qt 6.0 Feature Freeze will be in effect 31st August 2020, > see https://wiki.qt.io/Qt_6.0_Release . That page mentions “Structure and platform freeze” on June 30th. Can you elaborate what this covered and what the outcome was? > All new modules must be in qt5.git latest a week before FF (Mon 24th August > 2020). > > Remember to inform release team (qt.team.releases at qt.io) about any new > submodule; we need to create packaging configurations etc for those. > > Please start updating Qt 6.0 new features page here: > https://wiki.qt.io/New_Features_in_Qt_6.0 > > br, > Jani Heikkinen > Release Manager > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development Cheers Mike — Mike Krus | mike.k...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Circular dependencies for Q_PROPERTY
Hi Simon
yes that worked, didn’t know about Q_MOC_INCLUDE
Thanks!
PS: seems Creator’s syntax highlighter doesn’t know about it either :)
> On 27 Apr 2020, at 11:08, Simon Hausmann wrote:
>
> Hi,
>
> I think the solution may involve keeping forward-declarations but adding
> visibility to the "other" types in moc generated code by using Q_MOC_INCLUDE
> in A to include B and vice versa. Does that make sense?
>
>
> Simon
> From: Development on behalf of Mike Krus
> via Development
> Sent: Monday, April 27, 2020 11:52
> To: Qt Development Group
> Subject: [Development] Circular dependencies for Q_PROPERTY
>
> Hi
>
> I have 2 classes, A and B, derived from QObject, each have a property
> of type pointer-to-other-class. So
>
> class A : public QObject {
> Q_PROPERTY(B *foo …)
> …
> };
>
> And:
>
> class B : public QObject {
> Q_PROPERTY(A *foo …)
> …
> };
>
> Because of the circular dependency, I can’t #include the full class
> definition, just do forward declaration.
>
> Now this fails in Qt 6, seems the moc generated code needs the
> full class declaration.
>
> Looking at generated moc code, looks like creating the meta object
> requires a qt_metaTypeArray which checks that A derives
> from QObject by calling IsPointerToTypeDerivedFromQObject
> which uses sizeof() which requires the full type.
>
> Any way around this? Seems like a rather big regression compared
> to Qt 5…
>
>
> Mike
>
> —
> Mike Krus | mike.k...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company
> Tel: UK Office +44 1625 809908 Mobile +44 7833 491941
> KDAB - The Qt Experts, C++, OpenGL Experts
—
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908 Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Circular dependencies for Q_PROPERTY
Hi
I have 2 classes, A and B, derived from QObject, each have a property
of type pointer-to-other-class. So
class A : public QObject {
Q_PROPERTY(B *foo …)
…
};
And:
class B : public QObject {
Q_PROPERTY(A *foo …)
…
};
Because of the circular dependency, I can’t #include the full class
definition, just do forward declaration.
Now this fails in Qt 6, seems the moc generated code needs the
full class declaration.
Looking at generated moc code, looks like creating the meta object
requires a qt_metaTypeArray which checks that A derives
from QObject by calling IsPointerToTypeDerivedFromQObject
which uses sizeof() which requires the full type.
Any way around this? Seems like a rather big regression compared
to Qt 5…
Mike
—
Mike Krus | mike.k...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company
Tel: UK Office +44 1625 809908 Mobile +44 7833 491941
KDAB - The Qt Experts, C++, OpenGL Experts
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Qt 5.12.8 Critical Bug in Qt3D
Hi we just noticed that, as now reported inQTBUG-83486, a recent patch to Qt 3D [1] has broken all applications that use Scene3D and non-default aspects (in particular the often required animation aspect). This is now fixed in [2] Would it be possible to bring forward the release of 5.12.9 as this impacts many applications ? Mike [1] https://codereview.qt-project.org/c/qt/qt3d/+/293691 [2] https://codereview.qt-project.org/c/qt/qt3d/+/297123 — Mike Krus | mike.k...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving math3d classes from GUI to CORE
> On 23 Jan 2020, at 14:36, Konstantin Tokarev wrote: > > > > 23.01.2020, 15:56, "Laszlo Agocs" : >> 4. Longer term, let's rather focus the energy on improving performance (via >> SSE, NEON) in math3d, as that would probably bring more benefits to Qt Quick >> and Quick 3D than spending effort on trying to get QtCore compete with >> existing linear algebra solutions out there. > > FWIW, "existing linear algebra solutions" like Eigen already implement SIMD > support for many CPU architectures. as does Qt3D Mike > -- > Regards, > Konstantin > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development — Mike Krus | mike.k...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Dominik Holland for approver status
having worked with him on Qt Auto: +1 from me > On 2 Oct 2019, at 09:18, Simon Hausmann wrote: > > Hi, > > I would like to nominate Dominik for approver status. He started contributing > to Qt back in 2013 and has been working primarily on the Qt automotive and > embedded related bits. After such a long time of steady contributions and > code peer-review in the automotive "corner", I do trust him to be > project-wide approver. > > > Simon > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development — Mike Krus | mike.k...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt3D overhauls
Hi we’re busy doing the work but have a couple of blog posts in the pipeline. It’s unclear if we’ll have benchmarks we can share, we’ll see. Also, those specific changes make a difference in specific conditions so YMMV. Will keep everyone posted, Mike > On 26 Sep 2019, at 08:48, Massimo Callegari via Development > wrote: > > Hi devs, can someone at KDAB please spend a few words about these "Threading > archtecture" and "Frontend/Backend node sync" overhauls mentioned in the 5.14 > changelog? > > I'd just like to know if we might expect performance improvements and, if so, > is it possible to see benchmark results before/after the overhauls? > > Thanks in advance and regards, > Massimo > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development — Mike Krus | mike.k...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Shadertools repo request and some words about state of graphics
> On 4 Apr 2019, at 15:06, Tuukka Turunen wrote: > > > > On 04/04/2019, 10.54, "Development on behalf of Mike Krus via Development" > > wrote: > >> Since Qt 3D Studio now contains, for lack of a better word, a fork of much >> of Qt 3D, do you have ideas for that? And plans to integrate the work into >> main line Qt 3D? > > Qt 3D Studio 2.3.0 runtime depends on Qt 3D of Qt 5.12.2, it is not a fork or > Qt 3D. When developing Qt 3D Studio runtime 2.x we have actually already done > a lot of work also in Qt 3D and there are not a whole lot of items that would > be directly applicable to Qt 3D that are not already part of it. Some items > may exist that could be brought over to Qt 3D, for example KTX package > format. But in general there is not that much items that would be useful as > part of Qt 3D, without the Qt 3D Studio. maybe too strong a word. But https://blog.qt.io/blog/2019/04/01/qt-3d-studio-2-3-released/ mentions Dragon & Dragon Wings which unless I’m mistaken are more or less complete replacements for Qt 3D’s rendering and animation backend respectively. Mike > Yours, > > Tuukka > — Mike Krus | mike.k...@kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Shadertools repo request and some words about state of graphics
Hi Laszlo, thanks for all this updated information. > On 2 Apr 2019, at 14:14, Laszlo Agocs wrote: > First, a qt-labs repository request: > > Repo name: qtshadertools > Name: Qt Shader Tools > Responsible person: me > Purpose: will import https://git.qt.io/laagocs/qtshadertools here. This is an > experimental Qt module providing APIs and a host tool to perform graphics and > compute shader conditioning for the upcoming Qt graphics abstraction layer. > While it is expected to evolve into a proper Qt module in Qt 6, the intention > is to keep it as a qt-labs project for Qt 5.x, mainly in order to avoid > prematurely importing larger 3rd party dependencies. looks like there's interesting things in your own repository. It would be a good addition to Qt6 tool set. It would also be nice to think of it in relation to the shader generator that was contributed to QtBase. While they are very different technologies, they do have some overlapping goals so might make sense to move them closer in qt6. > Second, I believe the request above demands a few words about the current > status regarding the evolution of the accelerated graphics stack in Qt. > > Short version: > > - Graphics and shader stack evolution is on-going. > > - A very early preview of Qt Quick for Vulkan, Metal, and D3D11 may come > already in Qt 5.14, then evolve in 5.15 and beyond, with 6.0 as its final > destination. > > - Qt Quick is just one piece in the puzzle. More about the others at some > other time. While the effort being put in Qt Quick is important and strategic, do you have have an idea of how you want the rest qt’s rendering stacks to evolve? How does this impact QDeclarativeWidget for example? Or more importantly (although I may be partial), Qt 3D? All the integrations of the various rendering tool chains currently rely on capturing the output of one stack in a buffer and using that in the other stack. Surely Qt6 can do better than that? Since Qt 3D Studio now contains, for lack of a better word, a fork of much of Qt 3D, do you have ideas for that? And plans to integrate the work into main line Qt 3D? Thanks again so sharing your ongoing work, Mike > Long version: > > As discussed at https://wiki.qt.io/QtCS2018_Graphics_Vision_2020 Qt 6 will do > away with the hard OpenGL dependency in most, if not all, of its modules. > This is achieved via a small abstraction layer, currently called the Qt > Rendering Hardware Interface, with backends for Vulkan, Metal, Direct 3D 11, > and OpenGL (ES) 2.x(+ some 3.x extensions) at the moment. Shader code needs > additional solutions: graphics shaders in Qt itself, and eventually also in > applications (custom Qt Quick materials, ShaderEffect, etc.), are expected to > be written in a single language regardless of the platform and graphics API > the applications will run on. Hence the above mentioned Shader Tools module. > > In (a not fully up-to-date but conceptually correct) > picture:https://git.qt.io/laagocs/qtrhi/blob/1dd15d715399000707552b030357a74782d50f38/rhi2.png > > Qt Quick, the OpenGL paint engine of QPainter, and various other components > are expected to migrate to this stack in Qt 6, removing direct OpenGL usage. > (to be clear, applications should still be able to do > OpenGL/Vulkan/Metal/etc. rendering directly in the future as well, just like > they can resort to direct OpenGL usage today via QSGRenderNode or > QQuickFramebufferObject or the QQuickWindow under/overlay signals, but then > they get tied to running with a given rhi backend, and so graphics API; > therefore, this is not an option for Qt itself, at least when it comes to the > essential Qt modules) > > This is a long journey, possibly with numerous road bumps (or blocks, even) > on the way. Therefore, the intention is to provide some of the components of > the new stack as tech previews already in the Qt 5.x time frame, in order to > make it easier to iterate, discover problems, and get feedback. > > As a first step, it is likely that in Qt 5.14 we can already include the some > of the Qt Quick work as an early preview. In practice this would mean that > (suitable) Qt Quick applications could opt-in to the new RHI-based rendering > path (currently this is done by simply setting an environment variable), thus > switching from OpenGL to D3D11, Vulkan or Metal, transparently to the > application. > > This involves the following pieces: > > 1. Most the RHI is to be imported (mostly) as private APIs. This is what > https://codereview.qt-project.org/#/c/256713/ is. (basically a private-ized > version of https://git.qt.io/laagocs/qtrhi with a bunch of changes on top) > > It is not unlikely that QRhi & co. becomes a public API at some point in Qt > 6.x, but we cannot yet commit to having them as public yet. While we believe > this already provides sufficient foundations for Qt Quick, QPainter, and Qt > 3D Studio, it will evolve and change over time
